[우테코] 2주차 소감문

 

 

2주차 과제 목표

1주 차에는 제가 부족한 내용을 공부하여 성장하는 것을 목표로 하였습니다. 그래서 디스코드나 오픈채팅방에서 사람들이 말하는 객체지향과 테스트를 공부하는 데에 시간을 쏟았습니다. 그러다 보니 오히려 코드를 보는 시간이 줄어들었고, 기능구현과 예외 처리에 시간을 많이 쏟지 못했던 것 같아 아쉽습니다. 생각해 보면 다른 사람들이 이런 식으로 구현했다는 말에 조급해져서 방향을 잘못 잡은 게 아닌가 싶습니다. 그래서 2주 차에는 조금 더 기능구현에 집중하여 코드를 더 들여다보는 것을 목표로 하였습니다.

(+ 오픈채팅방도 나갔습니다)

 

 

이전 과제 돌아보기, 깃허브 공부

2주 차 과제 이메일을 받자마자 구현이 너무 하고 싶었지만, 피드백을 정독하고 이전 과제를 돌아본 후 다음 과제를 하는 게 맞다고 생각하였습니다. 그래서 피드백 강의를 들으며 새롭게 배운 내용들을 정리하였고, 공통피드백에 올라온 깃허브관련 테코톡 영상을 보며 내용을 정리하였습니다.

https://fladi.tistory.com/376

[GitHub] 테코톡 보면서 깃허브 공부하기

 

 

공통 피드백, 요구사항 분석

정리가 끝난 후에는 공통 피드백과 2주차 요구사항을 3번 정도 정독하고 정리하였습니다. 1주차에 요구사항을 제대로 읽지 않아 리포지토리를 전체 삭제하고 다시 만든 적이 있었기 때문에 다시는 같은 실수를 하고 싶지 않았습니다. 우테코를 같이 하는 친구가 체크리스트에 요구사항을 정리하면 효율적이라고 조언해 주어 체크리스트에 요구사항을 정리하기도 하였습니다.

 

친구야 고마워🐶🐶🐶

 

 

기능리스트와 도메인 작성

어느 정도 공부가 끝난 후에는 기능 리스트를 작성했습니다. 1주차 피드백강의에서 기능 리스트를 작성하며 클래스와 메서드명을 미리 적어두는 걸 보고 저도 비슷하게 해보려고 했지만, 바로 적으려니 생각보다 잘 떠오르지 않았습니다. 그래서 기능구현에 사용할 도메인부터 그렸습니다.

 

 

자동차 경주게임에서 사용될 역할들을 떠올리며 각자가 주고받을 메시지에 대해 생각하였습니다. 그다음에 기능 리스트를 작성하니 어떤 도메인에서 어떤 기능을 해야 하는지 잘 떠올랐고, 메서드명도 생각하기 쉬웠습니다.

 

 

 

구현 시작!

구현할 때는 자바컨벤션에 조금 익숙해진 상태라 이전보다 긴장하지 않고 자바 코드를 작성할 수 있었습니다. 기능 자체도 1주차보다 그렇게 어렵지 않았던 것 같습니다. 하나 까다로웠던 점은 인덴트를 2 이하로 만드는 것과 함수를 하나의 기능만 하도록 쪼개는 것이었습니다. 이전에 자바로 알고리즘을 공부할 때는 4중 for문도 자주 사용하며 코딩하였는데, 인덴트를 2 이하로 만들려고 하니 하나하나 메서드로 추출해 줘야 해서 조금 번거로웠습니다. 동시에 함수가 한 가지 기능만 하도록 만들려고 노력했지만, 처음부터 쉽게 나눠지지 않아서 나중에 리팩토링을 하면서 게속 함수를 분리해 줬습니다. 작성할 때는 어려웠는데 나중에 돌아보니 훨씬 가독성이 좋아진 코드가 만들어진 걸 보고 뿌듯했습니다.

 

하나의 기능을 개발할 때마다 그에 대한 테스트 코드를 작성하는 게 좋다는 걸 알고 있었지만, 아직 단위테스트에 대해 잘 몰라서 망설여졌습니다. 또한 기능개발을 하다 테스트 공부로 빠지면 흐름이 끊길 것도 우려되었습니다. 그래서 테스트는 기능개발과 리팩토링, 예외 처리를 모두 끝낸 후에 하려고 미뤄두었습니다. 구현을 하는 당시에는 기능 자체의 구현과 기능단위로 커밋하는 것에 집중하였고, 개발하다 예외사항이 생각이 나면 바로바로 반영하였습니다. 그렇게 커밋메시지의 타입은 feat와 fix, refactor로 채워졌습니다. 구현하는 중간에 궁금한 내용이 생기면 찾아본 후 작게 메모를 해두고, 남는 시간에 조금씩 블로그에 정리하였습니다.

 

https://fladi.tistory.com/366

[JAVA] split vs StringTokenizer

• 쉼표를 기준으로 문자열을 분리하는 2가지 도구의 사용법을 알아보고 비교하였습니다

 

https://fladi.tistory.com/367

[JAVA] StringBuilder 비우기(초기화하기)

• String끼리 합치기위해 StringBuilder를 사용하였는데, 초기화하는 메서드가 없어 찾아보다 작성한 글입니다

 

https://fladi.tistory.com/368

[JAVA] public private 메소드 정렬 순서 결정하는법

• 클래스 내부의 공용인터페이스를 어디에 위치시킬지 고민하다 구글링을 해보고 정리한 글입니다

 

https://fladi.tistory.com/371

[JAVA] 문자열 양쪽 공백을 제거하는 trim과 strip 비교

• 문자열 양쪽 공백을 제거하는 자바의 두 가지 도구에 대한 사용법을 보고, 비교해본 글입니다

 

 

어느 정도 기능을 완성한 후에도 게속 리팩토링을 하며 예외 처리와 좋은 구조로 만들고자 하였습니다. 제가 생각할 수 있는 예외를 모두 처리하였고, 리팩토링도 어느 정도 끝난 후에 테스트 공부를 시작하였습니다.

 

 

테스트 코드 공부하기

저는 이전에 단위테스트를 해본 적이 거의 없었고, 항상 통합테스트만 작성했었습니다. 단위테스트를 하려면 mock을 무조건 사용해야 한다는 이상한 부담감도 있어서 쉽게 시작하기 어려웠던 것 같습니다. 그래서 저는 단위테스트 공부를 위해 가장 먼저 mock의 사용법을 정리하였습니다.

 

mockito 공식 홈페이지 등을 보면서 간단한 사용법을 정리하였고, mock동작을 설정하는 여러 예시를 보며 어느 정도 익숙해졌습니다. mock외에도 단위테스트 자체를 어떤 식으로 해야 할지 궁금하여 관련 테코톡 2개를 보며 공부하였습니다. 그리고 예제코드인 StringTest도 보면서 assert 사용법을 정리하였습니다.

 

https://fladi.tistory.com/369

[JAVA] 단위테스트 공부1: Mock 알아보기

 

https://fladi.tistory.com/370

[JAVA] 단위테스트 공부2: 테코톡 보고 정리

 

 

테스트코드 작성

 이후 자신감을 얻어 바로 테스트코드 작성을 시작하였습니다. 이전에 공부한 내용들을 활용하니 어렵지 않게 단위 테스트를 작성할 수 있었습니다. @ParameterizedTest나 @Nested 와 같은 어노테이션이 공부할 때는 와닿지 않았지만, 직접 활용해 보니 정말 유용한 도구라는 걸 알게 되었습니다. 적어도 이런 기능이 있다는 걸 알기만 해도 중복이 많이 줄어들고, 보기 쉬운 테스트를 작성할 수 있을 것 같았습니다. 테스트를 작성하기 전에 공부하길 잘했다는 생각이 들었습니다.

 

 또한 1주차에 ApplicationTest의 코드가 궁금하여 뜯어본 기억이 있는데, 여기서 입출력과 관련된 테스트와 Randoms에 static mock을 넣어 테스트하는 걸 봤습니다. 이 기억을 떠올리며 Randoms를 사용할 때 비슷한 방법으로 mock을 주입하였고 랜덤값에 대한 테스트를 어렵지 않게 수행할 수 있었습니다. 또한 입출력과 관련된 테스트도 똑같은 방법을 사용하여 작성하였습니다. 이때 헛된 공부는 없다는 걸 알게 되었고, 2주차 테스트에 작성되어있던 ApplicationTest도 다시 분석하여 정리하였습니다.

 

https://fladi.tistory.com/373

[우테코] 2주차 Test코드 분석 - NsTest, assertj, JUnit

 

테스트를 하다보니 계속 코드에 잘못된 부분이 보였고, 테스트를 하는 중간중간 코드를 수정했습니다. 테스트 작성 전에 예외 처리를 거의 다 끝냈다고 생각했는데, 단위테스트를 해보니 작은 부분을 많이 놓쳤다는 걸 알게 되었습니다. 이를 통해 기능개발을 하면서 테스트를 작성하는 게 중요하다는 것을 알았고, 3주차에는 기능을 만드는 동시에 테스트 코드도 같이 작성해야겠다고 다짐했습니다.

 

https://fladi.tistory.com/375

[JAVA] 단위테스트 공부3: 활용하기

• 이 포스팅은 단위테스트를 작성한 후에 작성한 글입니다

 

https://fladi.tistory.com/374

[JAVA] 클래스 내부 속성으로 가지고 있는 객체를 mock으로 설정하는 방법: @InjectMock이 동작하지 않

• 단위테스트를 수행하다가 mock주입방법에 대해 찾아보고 작성한 글입니다

 

 

깃허브 커밋메시지 바꾸기

 

개발을 하면서 깃허브와 관련한 어려움도 있었습니다. 저는 인텔리제이에서 commit메시지를 작성하고 push를 하였는데, 인텔리제이는 이전 커밋메시지를 그대로 저장해 두는 기능이 있었습니다. feat, test와 같은 타입의 경우 계속 중복해서 적어야 하는 경우가 있었기 때문에 저는 이전 커밋메시지를 자주 재활용을 했습니다. 하지만 테스트 코드를 작성하고 오류를 고치면서 test와 fix를 계속 번갈아 사용하다 보니 중간에 실수를 몇 개 해버렸습니다.

 

 

 

깃 로그를 보니 저 멀리 있는 커밋 3개가 이름이 잘못된 걸 발견하였고, 구글링을 하여 커밋메시지를 변경하는 방법을 알아내 커밋메시지를 바꿨습니다. 하지만 이미 잘못된 커밋메시지는 푸쉬된 상태었고, 변경된 커밋을 push하니 에러메시지가 나왔습니다.

 

pull 해도 안되는데 !!!

 

저는 지금까지 한 커밋이 모두 날아갈까 봐 당황하였고, 해결 방법을 구글링하여 force push라는 것을 알아내 적용하였습니다. 지금 돌아보면 생각보다 큰일은 아니었지만, 당시에 굉장히 당황했던 기억이 납니다. 이때 깃허브를 미리 공부하여 다양한 상황에 대비하는 연습을 하는 게 좋은 것 같다고 생각했습니다.

 

이 당시 테스트 코드를 거의 다 작성한 상태였고, 리팩토링도 마친 상태여서 부족한 깃허브를 좀 더 공부하고자 하였습니다. 제가 커밋메시지를 바꾸기 위해 사용했던 방법인 force push는 팀원들과 협업할 때 등의 상황에서는 쓰면 안 된다는 말을 들은 적이 있었습니다. 그래서 저는 force push가 아닌 다른 방법을 찾아봤고, 공부한 후 해당 내용을 블로그에 정리하였습니다. 이때도 이전에 rebase, cherrypick내용을 공부했기에 어렵지 않게 이해할 수 있었던 것 같습니다.

 

https://fladi.tistory.com/377

[GitHub] 커밋 메시지 바꾸기: amend, rebase, cherrypick

 

 

 

돌아보며

2주 차에는 프리코스에 조금 익숙해진 건 지 1주차보다 더 몰입할 수 있었고, 배운 내용도 더 많았던 것 같습니다. 전공자인 저에게 기능개발 자체는 어려움이 없었던 것 같지만, 좋은 구조를 생각하면서 프로그래밍하는 건 쉽지 않았던 것 같습니다. 앞으로도 더 좋은 코드 구조로 프로그래밍하는 것에 대해 고민해보려고 합니다. 그리고 이번 기회에 단위테스트에 대해 알게 되어 너무 기쁩니다! 이 지식은 프리코스가 끝난 후에도 유용하게 사용할 수 있을 것 같습니다. 너무 재밌었고 많은 걸 배울 수 있었던 일주일이었습니다. 3주 차에도 더 많은 걸 배우고 몰입하여 2주 차보다 더 성장하고 싶습니다.