본문 바로가기

[우아한테크코스 ] 1주차 미션 리뷰 후기

코드 : https://github.com/dpudpu/java-racingcar
리뷰 : https://github.com/woowacourse/java-racingcar/pull/19

우아한테크코스가 드디어 시작했고 첫 번째 미션은 프리코스 미션 중 하나인 자동차 경주였습니다.

이미 했고 요구사항까지 똑같은데 굳이 할 필요가 있을까? 의문이 들었지만, 이번에 큰 변화가 있었습니다. 3일 동안 페어 프로그래밍으로 진행하는 것이었는데요. 페어프로그래밍 경험이 두 번째여서 많이 낯설고 이견을 조율하는데 처음에 고생했지만, 다행히 좋은 페어를 만나서 좋은 결과를 얻을 수 있었습니다.

이번 미션에서 저의 리뷰어는 제이슨 코치님이셨는데요. 일단 너무 꼼꼼하게 (커밋 로그까지) 확인해 주셔서 감동하였습니다. 귀중한 시간 내서 리뷰해주신 만큼 최선을 다해서 고치고 물음에 답하려고 노력했고, 이렇게 그냥 넘어가면 나중에 까먹고 또 같은 실수를 할 수 있어서 리마인드도 할 겸 후기를 작성하게 되었습니다.

  • 제이슨 코치님은 잘한 부분은 잘했다.
  • 잘못 구현 혹은 더 나은 방법이 있는 부분을 알려 주시고
  • 제가 잘 알고 사용 했는지, 안다면 좀 더 깊이 있게 공부 하라고 질문을 해주시고
  • 마지막으로 어려운 단시간에 해결은 힘든, 앞으로 계속 생각해봐야 할 주제를 주셨습니다.

1. 잘한 부분

원시 값을 포장하라는 말에 따라서 사용한 건데 이런 클래스의 이름이 value object고 불변이야 한다는 것까진 몰랐는데 알려 주시는 센스!

이렇게 좋았던 부분은 좋았다고 코멘트를 남겨 주셨는데요.

코딩하면서도 내가 맞게 한 건지 의문이 들 때가 있는데, 이렇게 말씀해 주시니 내가 제대로 했구나! 생각이 들면서 앞으로도 계속 써도 된다는 확신과 자신감을 얻을 수 있어서 정말 좋았습니다.


2. 잘못 구현 혹은 더 나은 방법

2.1 Model과 View의 기능 분리

포비님 강의에서 'getter 사용을 자제하고 객체에 직접 메시지를 보내라!' 를 잘 못 이해해 getter 사용을 안 하려고 도메인에 view 기능을 직접 구현했습니다.

그리고 결과는? 지적 받았습니다. 단순히 지적만 해주신 게 아니라 '앞으로 이러한 변경이 생기면 어떤 상황이 발생 될 것인가?' 라는 예시를 주셔서 '아! 이래서 사용하면 안되는구나'. 그리고 언제 getter 를 쓰지 말고 써야 할지 명확하게 구분할 수 있게 되었습니다.

getter 를 쓰지 말라는 이유는 여러 이유가 있겠지만 제가 생각하는 가장 큰 이유는 유지보수와 확장 때문입니다. 예를 들면, B 클래스가 A 클래스의 속성들을 getter 로 가져와서 비즈니스 로직을 구현했습니다.
나중에 A가 변경되면 B에게도 영향을 끼쳐서 수정해야 할 수도 있는데요. 이런 코드가 하나면 괜찮지만 만약에 여러 개라면? 정말 끔찍합니다.
그래서 캡슐화를 통해 기능을 사용하는 코드에 영향을 주지 않고 (또는 최소화) 내부 구현을 변경할 수 있는 유연함을 위해서 객체에 직접 메시지를 보내라는 말씀이였던 거 같습니다.

  • 그 외에도 참조형 값을 리턴 해주면 외부에서 수정이 가능하다. 정도??

2.2 참조 값 문제

저는 인자로 받은 List cars를 그대로 this.cars = cars; 로 초기화 해줬는데요.
이렇게 했을 경우에 발생하는 문제가 있습니다. 문제는 피드백에 적혀 있으니 생략하고 코드로 보여드리겠습니다.

코드를 봐도 이해가 안 된다면 Java는 Call by Value? Call by Reference? 를 한번 읽어 보시는 것을 추천 드립니다.

2.3 InputView 의 두가지 책임 문제 (SRP 위반)

SRP에 대해서 공부한 적이 있었는데 어려워서 제대로 사용하지 못했는데 이렇게 말씀해 주시니 조금은 더 알 수 있게 되었습니다.

2.3 테스트 메소드들 마지막에 중복되는 부분 @After로 빼기

2.4 코드 컨벤션

2.5 또 다른, 나은 방법

이 클래스는 사실 전에 커밋 했다가 새로운 버전으로 업그레이드 하면서 지운 부분인데요.

커밋 로그까지 확인하시면서 이 부분에 대해서도 피드백을 남겨 주셨습니다. 제 생각으로는 Enum에서 제공해주는 values를 사용해서 enum 자체에서 비교하라는 의도가 아니었을까 싶어서 피드백을 남겼더니 또 피드백을 주셨습니다.

다른 사람이 제 코드를 보고 피드백을 해주면서 단순히 답만 알려주는 게 아니라 더 나은 방법을 생각할 수 있게끔 제시해 주니 해결하기 위해서 시간은 오래 걸렸지만, 확실히 제 것으로 만들기가 쉬워서 좋았습니다.


3. 잘 알고 사용했나? 생각 해 볼 수 있는 물음

또 특별했던 점은 '왜 이렇게 사용했나?', '이렇게 하면서 어떤 것을 느꼈나?' 물어봐 주셨는데요.

대답을 적다 보니 리마인드도 되고 답하기 위해서 자료를 찾다 보니 몰랐던 부분들도 알 수 있었습니다.


4. 계속 생각해봐야 할 어려운 문제들

어려운 주제를 생각해 보라고 참고할 레퍼런스를 주셨는데요. 알 거 같으면서도 모르겠는? 앞으로 계속 더 공부하면서 알아봐야 할 어려운 숙제를 주셨습니다..

학생 때 문제를 풀어서 틀려서 답을 보면 이해가 됐지만, 다음에 또 같은 실수를 많이 했는데요. 그때 생각이 나서 복습하자는 의미로 한번 후기를 작성했습니다. 작성하면서 잊어버렸던 부분도 다시 기억나고 이미 답했지만 좀 더 나은 방법도 생각나고 좋았습니다. 다른 분들도 피드백 받으시고 그대로 끝내지 마시고 중요한 몇 가지는 정리해 두시고 한 번씩 보시면 좋지 않을까 싶네요.

마지막으로 귀한 시간 내서 완벽한 리뷰를 해주신 제이슨 코치님 감사합니다.