[우아한 테크코스] 레벨 1 - 자동차 경주 회고

우테코에서의 첫 번째 미션이다.

우선 미션을 진행한 repository와 PR 목록들!!

 

자동차 경주 repository

GitHub - Ohjintaek/java-racingcar: 자동차 경주 게임 미션 저장소

1단계 PR

[1단계 - 자동차 경주 구현] 썬샷(오진택) 미션 제출합니다. by Ohjintaek · Pull Request #470 · woowacourse/j

2단계 PR

[2단계 - 자동차 경주 리팩토링] 썬샷(오진택) 미션 제출합니다 by Ohjintaek · Pull Request #628 · woowacou

---

 

🤪 무엇을 했지?

페어프로그래밍

1. 페어프로그래밍을 처음 경험해본 상황이라 기대 반, 설렘 반의 마음가짐으로 임했다. 프리코스 전체에서 유일하게 3인 페어(루카, 헤나) 였지만 다들 페어프로그래밍은 처음 해보는 상황이라 간단한 규칙을 정하고 시작했다.
2. Driver일 때는 자신이 코드를 작성하는 의도를 설명하면서 작성하고 Navigator일 때는 이해가 되지 않는 부분이 있거나 더 낫다고 생각하는 방법이 있다고 생각될 때 바로바로 말해주기로 했다.
3. Driver의 교대는 20분마다 (기능별로 하는 방법도 있지만 이번에 시간으로 선택했던 것은 좋은 선택이었던 것 같다)
4. 세 명의 페어가 모두 생각을 합의하기. 이를 위해 코드 작성에 시작하기에 앞서 기술 요구 사항을 읽고 모두 동의하는 구현할 기능 목록을 작성하기 위해 정말 오랜 시간을 썼다.

처음 접한 기술적 새로움들

• 개발 환경으로 인텔리제이(intelliJ)를 사용하는데 페어프로그래밍을 진행하기로 한 컴퓨터의 인텔리제이 인터페이스가 뭔가 나와 많이 달랐다. 코드들을 알아보기 쉽게 다양한 플러그인들을 적용한 거 같은데 나중에 공부해서 직접 내 개발환경에도 적용해 봐야겠다. (근데 아직 하진 않음)
• 페어들이 코드를 작성할 때 다양한 단축키들을 사용하는데 인텔리제이에 단축키가 그렇게 많은 줄은 처음 알았다. 단축키를 쓰면 생산성이 훨씬 빨라진다고 하니 반드시 익혀야겠다는 생각을 했지만 사소한 문제가 있었다. 나는 윈도우를 쓰고 다른 페어분들은 맥을 사용해서 페어프로그래밍할 때는 매번 단축키를 물어보면서 진행했다.
• DTO. 정말로 처음 들어보는 단어였는데 Data Transfer Object (DTO) 의 약자로 웹 프로그래밍할 때 데이터를 전달하고 싶을 때 사용하는 객체다. 자동차와 자동차 게임의 결과 등을 View에 넘겨줘야 하는데 직접 객체를 넘겨줄 수 없으니 DTO로 데이터만 포장해서 넘겨주는 역할을 한다. 페어 프로그래밍이 없었다면 우테코의 어느 시기쯤 되서야 저 단어를 접하게 되었을 지 가늠이 되지 않는다. 여러 사람들이 모여 함께 대화를 나누면서 많은 정보의 교류가 이뤄지는 점이 페어프로그래밍의 장점 중 하나이다.

코드리뷰

• 우테코에서는 미션마다 리뷰어에게 코드리뷰를 받는다. 남이 내가 쓴 코드를 하나하나 읽어보는 경험도 처음이거니와 피드백까지 받는다니…😡  부끄러울 수 있지만 사실 본인의 실력을 늘리고 지금까지 당연하다고 생각한 것들을 의심해 볼 수 있는 흔치 않은 기회다. 무엇보다 나는 지금까지 개발자로서의 프로그래밍 경험은 부족하기 때문에 마치 바싹 마른 스펀지처럼 쏟아지는 여러 정보들을 받아들인 뒤 내 생각대로 의심해서 다시 쭉 짜버리는 과정을 반복하게 되지 않을까 싶다.

git rebase, git cherry-pick

• 2단계 미션을 다 작성하고 PR을 날리려 하니 Merge가 불가능한 PR이라는 경고가 뜨더니 리뷰 요청이 안 된다!!!😵😵 1단계 미션을 진행한후 우테코 repository와 내 repository의 내 branch를 fetch를 통해 동기화를 시켜줬어야 했는데 그 과정을 생략하고 먼저 2단계 미션을 진행했더니 생긴 문제였다. 나중에야 부랴부랴 내 repository의 main branch를 rebase 해주는 과정에서 자꾸 conflict가 발생했다. 해당 issue에 관한 글을 보고 해결하기는 했지만 git push --force를 사용하였기에 다음에도 이런 상황이 발생한다면 conflict를 하나하나 풀어서 rebase --continue를 사용해볼 생각이다. rebase해 준 뒤 추가로 작성했던 commit들은 git cherry-pick을 사용하여 한 번에 편하게 옮겨올 수 있었다.😁 (git cherry-pick 참고한 글)

 

 

 

👍 좋았던 점

상수의 위치에 관한 고찰

• 일반적으로 상수는 클래스의 가장 위에 적지만 여기서 얘기하는 상수의 위치는 그런 것은 아니다. 미션에서 자동차의 움직임을 관리하는 CarMovement 클래스에서만 사용되는 상수들임에도 따로 빼내 CarMovementConfig 라는 클래스에 따로 관리해두었다. 이 부분에 대해 리뷰어님(에단)의 질문을 하셨고 그에 대해 몇 번 문답이 오가서 간단히 요약해서 아래에 정리해보았다.

에단 : 이 상수들은 CarMovement에서만 쓰이는 값들인데 분리하는 것이 어떤 장점이 있을까요?

썬샷 : 현재 미션에서 자동차가 움직이는 값을 결정하는 상수들은 CarMovement에서만 사용하고 알면 되지만 페어프로그래밍할 때 자동차 경주 게임을 프로그래밍한다면 자동차와 관련된 또다른 설정들을 추가해야 될 상황이 있지 않을까라는 얘기를 나누게 되었고 그런 부분들을 config 패키지에 묶어놓으면 편리할 것 같다라는 의견으로 모아졌습니다. 그래서 자동차 움직임을 결정하는 상수들을 따로 빼서 정리해놓았습니다. 여러 에러 메시지를 관리하기 위해 따로 ErrorMessage에 작성했던 것을 비슷한 맥락으로 볼 수 있을 것 같습니다.
  이 내용과 관련해 의문이 드는 점은 만약 정말로 여러 상수들이 한 클래스(ex. Car)에서만 사용된다면 Car 클래스의 상단에 정리하는 편을 추천하시는지 따로 CarConstants와 같은 클래스를 두어 따로 관리하는 것이 추천하시는지 궁금합니다. 개인적으로는 정말 그 클래스에서만 사용되는 상수들이라면 해당 클래스를 읽을 때 상수까지 한 번에 보는 편이 더 편할 것이라는 생각이 듭니다.

에단 : 에러 메시지는 경우에 따라 사용자에게 직접 노출되기도 하는, 즉, view 영역의 관심사가 반영되는 경우도 있습니다. 메시지를 모아놓는 것은 이 메시지가 view의 요구사항에 따라 일괄적으로 바뀌어야 하는 경우(e.g., 예외 메시지가 영어, 중국어와 같이 다른 언어로 노출돼야 하는 경우)에 유용할 수 있어요. 그렇다면 도메인에서 쓰이는 상수들도 이와 같은 이점을 누릴 수 있는지 질문해볼 수 있겠네요. 서로 다른 도메인 클래스에서 사용하는 상수들도 일괄적으로 바뀌어야 하는 경우가 있을까요? 혹은 상수를 한 클래스에 모아두는 것이 그 외에 다른 이점을 줄 수 있을까요?

썬샷 : 서로 다른 클래스에서 사용하는 상수지만 일괄적으로 바뀌어야 하는 경우도 마찬가지로 있을 것이라는 생각이 듭니다. 떠오르는 건 도량형이 바뀌는(ex. 미터 <-> 인치) 경우를 예로 들 수 있을 것 같습니다. 해당 부분에 대해서 계속 고민을 하다가 사실 한 방법이 더 낫다는 결론을 내릴 수 없다는 생각이 들었어요. 다만 프로그램의 크기가 커질수록 상수들은 따로 빼서 관리하는 것이 좋을 것이라고 생각되는데 여러 곳에 흩어진 상수를 찾기 어렵고 프로그램의 크기가 점점 커질수록 설계 초기에는 예상하지 못했더라도 서로 관련이 생기는 경우가 있을 것 같습니다.

 

• 이 문제에 대한 현재 나의 생각은 마지막 대답에서와 마찬가지로 작성해야 하는 프로그램의 크기에 따라 달라질 것이라는 것이다. 다만 프로그래밍을 할 때는 추후에 변경이 쉽도록 작성해야 하기 때문에 확장될 가능성이 있는 프로젝트라면 관련있는 상수들을 따로 클래스를 만들어 보관해두는 것이 좀 더 좋을 것 같다는 생각이 든다.

 

유익한 페어프로그래밍

• 페어였던 루카, 헤나가 코드를 작성하는 것과 의견을 말하는 것을 보고 많은 것들을 배웠다. 특히 테스트 코드를 작성하는 것에 대해서 좀 자신감이 생겼다. 프리코스 때에는 테스트 코드를 작성하는 것에 익숙하지도 않았고 그 필요성을 실감하지도 못해서 학습이 지지부진했는데 어떻게 작성하는지 보고 배우면서 매우 익숙해졌다.

 

 

 

🤔 아쉬웠던 점

부족한 실력 (아마 한동안)

• 최종 테스트 후 우테코에 들어오기 전까지 프로그래밍을 거의 하지 않았기 때문에 페어프로그래밍 때는 참 많은 실력의 격차를 느꼈다. 각자 20분씩 돌아가면서 키보드를 잡았는데 확인해보진 않았지만 코드의 양을 따져보면 현저히 떨어질 것 같아 부끄러웠다.
• DTO에 대해 잘 모르면서도 웹 프로그래밍에서 데이터를 전달할 때 쓴다는 객체라길래 정확히 어떤 역할을 하는 것인지 심도 깊게 물어보지 못 한 채 개발을 계속했다. 코드 리뷰 때 리뷰어님이 내가 DTO에 대해서 제대로 이해하지 못하고 있는 것이 코드를 통해 보였는지 테코블의 DTO에 관한 글을 주셨고 그때서야 어떤 객체인지 알 수 있었다. 공부를 한 뒤 설계에 대해 고민을 하니 DTO를 사용하는 건 과하다는 생각이 들어 2단계 미션을 진행할 때 DTO를 사용해서 정보를 전달하는 것이 아닌 정보를 넘겨주는 객체에서 필요한 정보만 전달해 주는 것으로 수정해주었다.

 

 

 

😎 기술적 발전

• @Test, @DisplayName, @ParameterizedTest, @Valuesource, @MethodSource 등의 어노테이션들의 의미와 사용법
• git cherry-pick 사용 및 원리
• DTO 객체의 의미와 형태

 

 

 

🏃‍♂️ 소감 / 앞으로의 계획

• 구현해야 할 기능들을 어떻게든 만드는 것, 즉 돌아가는 쓰레기 를 만드는 건 그렇게 어렵지가 않다. (아직 규모가 큰 프로그램을 짜본 적 없기 때문일 가능성이 크다ㅋㅋㅋㅋ) 하지만 개발자라면 그것을 넘어 읽었을 때 이해하기 쉬운 코드, 유지 보수가 쉬운 코드를 짤 필요가 있고 그를 위해서는 정말로 많은 생각을 해야 한다는 것을 느꼈다.
• 2단계 진행하면서 코드를 작성하는 시간보다 개념을 찾아보면서 공부하고 어떤 네이밍을 지을지, 어떤 구조로 설계해야 하는지 고민하는 시간이 더 많았고 앞으로도 그럴 거 같은 예감이다. 고민하는 시간들을 줄이기 위해 우테코 레벨 1동안은 객체지향에 대해 공부하고 내 주관을 찾아나갈 예정이다.
• 프로그래밍 미션에 대한 회고인데 코드가 하나도 없다. 다음 미션 회고를 쓸 때는 반드시 코드와 함께하는 회고를 써 보자.