2주차에는 TDD라는 개발 방법론에 대해 공부하고 직접 적용하는 실습을 진행했다.
TDD라는 새로운 방식으로 프로그래밍을 하는 것이 익숙치않고 적응하기 힘들었다.
하지만 그 만큼 장점이 있는 방법론이기 때문에 힘들어도 익숙해지려고 노력하는 중이다.
TDD에 대해 정리를 해서 글로 작성하기도 했다!
2주 차 미션은 TDD로 진행하는 자동차 경주 게임이었다. 프리코스때 한 번 해본 미션이라서 쉽고 빠르게 진행될 줄 알았는데 생각보다 오래걸렸다.
낯선 TDD로 진행하려다 보니 오래 걸린 것 같다. 익숙치 않고 어색했던 TDD지만, 앞으로 TDD로 개발하며 TDD의 장점을 흡수하기위해 부단히 노력했던 한 주였다.
무엇보다 좋았던 점은 미션 도중에 자세히 몰랐던 부분들을 발견하고 그것들에 대해 학습하고 알게 되었다는 점이다.
기쁜 마음으로 학습하고 블로그에 정리하면서 완전히 내것으로 만들었다.
- hashCode와 equals
- Iterator 인터페이스와 Iterable 인터페이스
TDD를 리뷰 받을 수는 없기에 2주 차에도 역시 클린 코드를 위한, 객체 지향적인 코드를 위한 리뷰가 계속 됐다.
나는 main 메소드에서 게임이 진행 되는 과정이 충분히 보여지고,
그것을 누군가보고 이해하는 게 좋은 코드이고, main 메소드의 역할이라고 생각했다.
하지만 이런 리뷰를 받았고, 충분히 이해되지 않아서 리뷰어 분에게 나의 생각을 전달하고 답변을 요청했다.
곰곰히 생각해보니 내가 구현한 main 메소드는 게임 진행 과정을 보여준다는 이유로 프로그램 내부의 게임 관련 로직들을 너무 많이 보여준 것이었다.
게임 진행 과정은 힌트 코드에서 보여지듯이 내부 로직을 최대한 숨기고 최소한의 정보로도 충분히 보여줄 수 있었다.
"View 로직과 비즈니스 로직을 분리한다." 프리코스때 부터 받은 MVC패턴 관련 피드백이지만 감을 못잡았던 피드백이란 것을 알아차렸다.
GameManager 라는 객체에서 OutputView 라는 View 관련 클래스의 메소드를 호출한다면 View 로직과 비즈니스 로직을 분리한 것이라고 생각했던 착각을 바로 잡을 수 있었다.
자동차 경주를 진행하는 로직에서 View 클래스 메소드를 호출하여 출력하던 것을 힌트코드에서 처럼 경주를 진행 했을 시 결과를 리턴하는 구조로 바꾸고 View 로직과 비즈니스 로직을 분리할 수 있었다.
출력하는 로직에서 toString을 활용해서 구현하면 어떻겠냐는 리뷰였다.
하지만 프리코스때 toString 메소드는 객체의 상태를 찍어보는 로그 메시지의 성격이 강할 때 사용하고 View 에서는 getter 메소드를 통해 데이터를 전달하라는 피드백을 받았었고 리뷰어 분에게 이러한 피드백을 받았었는데 toString을 사용하는게 괜찮은거냐고 여쭤봤다.
피드백의 내용은 맞지만 리뷰어 분께서는 View에서 toString도 하나의 방법일 순 있다고 말씀해주셨다. 정답을 딱 정하려했던 내 자신을 반성했다. 코드에는 정답이 없다는 것을 더 빨리 깊게새기자.
리뷰어 분에게 상수가 많아졌을 때 해법에 대해 다음과 같은 질문을 하기도 했다.
상수를 왜 사용하는지, enum을 어떤 경우에 사용하는지 생각해보라는 답변을 받을 수 있었고 내가 얼마나 멍청한 질문을 했는지 알 수 있었다.
우선 상수는 하드코딩에서 오는 단점, 즉 코드가 변경됐을 때 자동으로 반영되지 않아서 버그 유발 가능성이 올라가는 것 등을 피하기 위해 사용하고 값이 의미하는 바가 명확해지고 이해하기 쉬워지기 때문에 사용한다.
그래서 공통으로 사용하는 상수의 경우엔 다른 클래스에 상수들을 모아놓고 사용해도 문제가 없다.
하지만 enum의 경우에는 값이 변경되지 않는 다는 점에서 상수와 비슷하지만 연관된 값들을 열거하기 위해서 사용되며 객체 내부에 값을 가지기 위해서는 int, String 등 특정 필드를 정의해야 한다.
하지만 이번 미션 코드에서 상수로 변환되는 값들은 int, String, char 등 다양한 값들을 가지고 있고 enum에서 사용하기엔 알맞지 않은 것이었다. 아직 enum을 완벽하게 알지 못한단 생각에 enum을 더 공부하는 계기가 되었다.
나와 똑같은 코드를 제출한 페어의 코드 리뷰를 통해서도 객체 지향적인 코드에 대해서 많이 배울 수 있었다.
cars는 List<Car>를 저장하고 있는 일급 컬렉션이고 일급 컬렉션의 장점 중 하나는 값을 마음대로 사용할 수 없다는 점인데 get으로 일급 컬렉션의 객체를 꺼내온다면 일급 컬렉션을 쓸 이유가 없었다.
이번 자동차 미션을 통해 getter의 사용을 자제하고 객체끼리 메세지를 통해 소통해야 훨씬 더 객체지향적으로 코딩할 수 있다는 점을 깨달았다.
페어의 리뷰에 달린 명쾌한 리뷰이다. getter의 사용을 자제하고 객체끼리 메시지를 주고받으면서 객체의 응집도를 높여야 한다는 점을 깨달았다.
그리고 도메인 객체는 View를 모르는 독립적인 객체로 만들어야 한다.
꼭 기억해야겠다.
2주 차 역시 몰랐었던 많은 내용을 배울 수 있었다.
다음 미션에서는 또 어떤 리뷰를 받고 또 어떤 모르는 내용을 알게될지 기대된다.
다음부터는 DTO 객체에 View로 전달할 내용을 넣고 getter로 View에서 출력하는 식으로 진행해봐야겠다.