[프리코스 2주차 미션 링크] https://github.com/woowacourse-precourse/java-racingcar-6
[제출 코드 링크] https://github.com/woowacourse-precourse/java-racingcar-6/pull/369
프리코스 2주차
2주차 문제는 자동차 경주 문제입니다.
경주에 참가할 사람들의 이름을 입력받고, 시도 횟수를 입력 받습니다.
이 시도 횟수는 자동차의 전진 시도 횟수입니다. 자동차의 전진은 내부적으로 생성하는 랜덤 값에 따라 그 값이 일정 조건을 만족하면 전진을 하는 방식으로 진행합니다.
최종적으로 이렇게 경주를 마친 뒤 결과를 출력하는 문제입니다.
2주차 미션의 목표는 함수를 분리하고 각 함수별로 테스트를 작성하는 것 입니다.
1주차 미션에 대한 공통 피드백이 있었습니다.
- 요구사항을 정확히 준수한다.
- 커밋 메시지를 의미있게 작성한다.
- 이 외 PR 관련 Git 관련 내용.
- 네이밍을 통해 의도를 드러내라.
- 축약하지 않는다.
- 의도를 드러낼 수 있다면 이름이 길어져도 괜찮다는 의미.
- Space, Tab을 혼용하지 않는다, 공백 라인을 의미있게 사용한다.
- 자바 API를 적극 활용한다.
- String.join 사용, 배열 대신 Java Collection을 사용한다.
주로 코딩 컨벤션에 관한 내용이었습니다. 남들이 보기 편한 코드를 작성하는 것도 중요합니다.
저는 여기서 1주차에 네이밍을 통해 의도를 드러내는 부분을 크게 지키지 못한 것 같다고 생각했습니다. 나만 알아볼 수 있는 네이밍을 사용한 것 같았고 축약도 마찬가지였습니다.
그리고 커밋 메시지를 세분화하여 작성하는 것에 익숙치 않아 이번 주차는 이 부분들에 집중하며 구현을 시작합니다.
1주차에 상호 코드 리뷰를 진행하면서 다른 사람의 코드를 읽고, 내 코드를 다른 사람이 보는 과정에서 발견한 메서드명에 대한 고민, 그리고 어떤 메서드가 꼭 그 객체에 있어야 하는 지 등등에 대해 고민을 많이 하게 되었던 것 같습니다. 객체지향에 대해 다시 한번 생각해보게 된 경험이었습니다.
구현
2주차 미션도 구현 자체는 크게 어렵지 않았습니다.
그러나 객체 지향에 대해 공부하면서 indent를 줄여야 하는 것을 알고 구현했음에도 막상 미션 요구 사항의 조건을 지키려고 노력하다보니 메서드로 더 분리할 수 있는 부분이 있었습니다. 이러한 부분에서 까다로움을 느꼈습니다.
분리를 할수록 이 메서드 이름을 고민하게 되고 이렇게 분리된 메서드가 꼭 이 객체에 있어야 되는가에 대한 질문을 스스로에게 하게 되는 경험을 했습니다. validator가 view에 있어도 되나, validator 대신 일급 컬렉션 Cars에 Car에 대한 검증 로직이 필요한가 등등 각 객체의 책임에 대해 깊은 고민을 하게 되었습니다.
2주차는 구현에서는 이러한 부분에 집중했고 새롭게 추가된 목표인 테스트 코드 작성의 경험이 없어 어려움을 겪었기 때문에 이 부분에 많은 시간을 투자하게 됐습니다.
새롭게 학습한 부분
가장 깊이 있게 학습했던 주제들에 대해 기록해보고자 합니다.
우선 테스트 작성에도 객체지향 생활 체조 원칙처럼 작성 요령이 있었습니다. 예를 들면 한 가지 테스트 메서드에서 2가지 이상의 검증을 하면 안된다. 등등 몰랐던 부분들을 알게 되었습니다. 그리고 테스트 코드의 기초적인 작성 방법에 대해 알게 되었던 주차였습니다.
2주차에 어떻게 보면 가장 핵심적인 부분이었던 랜덤값에 의한 메서드를 테스트하는 부분입니다. 테스트를 하는데 랜덤값에 의존한 테스트를 하게 된다면 테스트의 결과는 예측할 수 없고 매번 바뀌게 되는 문제가 생깁니다.
이 부분들을 학습하면서 테스트 코드 작성에 대해 익숙해지고, 테스트 코드의 중요성을 어느정도는 알게 된 것 같습니다.
그리고 getter의 문제점에 대해 알게 됩니다. 이전에는 그냥 getter사용 지양해라, setter는 웬만하면 사용하지 마라. 이 정도로만 알고 있었는데, 학습을 하며 getter 사용에 대해 깊게 고민해볼 수 있는 기회가 되었습니다.
아쉽거나 적용시켜 볼만한 부분
- 테스트 코드도 코드다. 리팩토링이 가능하다.
- 여러 값을 넣거나, 반복되는 부분은 리팩토링을 할 수 있었다.
- 불변 컬렉션을 반환하더라도 컬렉션 내부의 객체에 접근이 가능하다면 내부 객체는 수정이 가능하다는 문제가 있었다.
- 학습을 했음에도 놓쳤었다. 이 부분이 어렵다.
- 메서드의 네이밍이 여전히 아쉽다.
- 예외 테스트 시 어디서 어떤 예외가 발생했는 지 명확히 나타내지 못했다.
- 상수화 할 수 있는 부분들을 놓쳤다.
- View에서 출력이나 입력 이상의 역할을 하도록 만들었다.
- private 메서드를 테스트하고 싶다는 생각이 들었다.
- 객체나 메서드 분리가 필요하다는 신호가 될 수 있다.
소감
지식이 쌓여감에 따라 코드는 더 나아지는 것을 느낄 수 있었습니다. 다만 아는게 많아지는 만큼 신경쓰이는 부분이 많아지다보니 놓치는 부분이 생기고, 그런 부분이 아쉬웠습니다.
그래도 이전보다는 객체 분리를 하는 것이 수월해지고, 훨씬 보기 좋은 코드가 만들어지고 있는 것 같아 좋았습니다.