1주차가 끝나고...
1주차가 완전히 종료된 오늘, 00시를 기점으로 1주차 과제에 대한 제한들이 풀렸다.
그래서 모아놨던 1주차 회고들을 싹 오픈하고, 코드 리뷰할 사람을 모집했었다.
코드 리뷰
나는 총 열 아홉분과 코드 리뷰를 진행했다. 프리코스 커뮤니티에 서로 코드리뷰 할 사람을 모집하는 글을 올렸는데, 감사하게도 많은 분들이 코드 리뷰 요청을 해주셨다. 
| 끊임없이 날라오는 리뷰 관련 메일들...
약속이기에, 열 아홉분 모두의 코드를 가능한 꼼꼼히 보며 리뷰해드렸다. 나는 1주차 과제 때 SRP를 지키는 것을 많이 집착했는데, 그래서인지 리뷰 요청하신 분들의 코드 중 의도치 않게 한 객체가 여러 역할을 가지고 있는 것이 눈에 잘 보여서 그것 위주로 리뷰를 해 드렸다.
잘 읽히는 코드도 있었고, 그렇지 않은 코드도 있었다. 코드를 읽으며 협업에서 클린 코드의 중요성을 다시 한번 깨달았고, 가독성이 좋지 않은 코드라도 배울점이 많았기에 리뷰도 학습의 기회로 이용하고자 했다.
제 코드를 리뷰해주신 분들은 특히 Enum과 DTO 사용, 그리고 DTO를 관리하는 DtoManager 사용을 칭찬해주셨다.
| 감사합니다... 정말 감사합니다...
또 지적해주신 것들을 보며 개선할 점이 아직 많다는 생각을 했다. 특히 이해가 부족했던 게, DTO는 데이터를 전송만 해주지 데이터를 저장하지 않는다는 것이었다. 나는 DTO를 일종의 '공통 데이터 저장소' 라고 생각하고 사용했었다. 그럼에도 불구하고 DTO 사용을 칭찬해주시니 좀 부끄러웠다 😅
다른 분들 코드리뷰를 해 드린다고 아직 제게 달아주신 모든 리뷰에 대한 답을 드리지 못했다. 내일 오전에 조금 짬을 내서 할 생각이다.
리뷰 남겨주신 모든 분들 감사합니다!
2주차 시작
2주차 미션이 시작됐다. 메일은 오후 3시부터 받았는데, 코드 리뷰를 해드린다고 실제로는 5시쯤 시작했던 것 같다.
미션 - 자동차 경주
2주차 미션은 자동차 경주였다. 상대적 난이도는 1주차랑 비슷하지 않을까? 더 많은 것을 알게 됐지만, 그만큼 더 어려워졌으니 상대적인 난이도는 비슷할 것 같았다. 우테코에서 제시한 기능 요구 사항, 입출력 요구 사항, 추가 요구 사항은 다음과 같다.
추가 요구 사항의 1, 2, 3번 항목은 1주차 과제때도 지킬려고 노력했던 것들이어서 부담이 되지는 않았다. 마지막 테스트 부분이 마음에 좀 걸렸는데, 내가 단위 테스트라고 했던 것은 사실 TDD였고, 단위 테스트와 TDD는 별개의 개념이었다. 이럴수가... TDD 안에 단위 테스트를 포함하는 줄 알았는데!
저 요구 사항은 단위 테스트를 요구하는 것 같았다. 정확한 단위 테스트는 해본적 없기에 저 요구 사항이 신경 쓰였다. 
| TDD와 단위테스트의 관계를 찾다가 발견한 모 포스팅. 나와 같은 상황을 겪으신 분이 계셨다.
설계부터
일단은 설계부터 시작했다. 오늘은 시간도 많이 남지 않았으니 딱 설계만 어느정도 진행하고자 했다.
| 러프하게 작성한 기능 명시
우선 필요하다고 생각되는 기능들을 적고, 그 기능이 어떤 목적을 하고 그 목적을 수행하기 위해 필요한 것이 뭔지, 분배해야 할 역할은 무엇인지 생각나는대로 적었다.
정해진 규칙이나 템플릿이 있지는 않고, 어차피 이 기능은 구현하다가 추가되는게 많기에 일단은 러프하게만 적었다. 시간 분배의 중요성을 깨달았기에...
그리고 기능이 명시가 됐으니, 사용자 관점에서의 '기능 흐름도' 를 만들었다.
사실 이런게 존재하는지는 모른다. 그냥 내가 머릿속을 정리하고, 나름대로 요구 사항에 대한 이해를 더 하기 위해 작성했다. 사용자 관점에서의 흐름도라 '입력 받기' 부터 시작하는게 특징이다.
| 사용자 관점 기능 흐름도
그리고 기능들이 어떤 계층에 분배되어야 하는지를 1차적으로 결정했다. 아직 코드를 작성하고 객체에 책임을 부여하는 과정은 아니기에, 기능을 계층에 분배하는 방식으로 적었다.
이거 하나 작성하는데 몇 시간이 걸렸다. 왜냐하면, Model, Domain, Service를 구분하기가 너무 어려웠기 때문이다. 특히 Domain과 Model의 차이점이 뭔지 정확히 파악하기가 어려웠다. 그리고 비즈니스 로직과 서비스 로직도 헷갈렸었다.
내가 학습한 바를 간단히 설명하자면, Domain은 Model의 한 부분으로 볼 수 있으나, 별도의 Domain 계층으로 분리하기도 한다. Model은 데이터를 표현하고, Domain은 데이터와 비즈니스 로직을 포함한다. Service는 중요한 비즈니스 로직을 담는다.
그래서 나는 비즈니스 로직(현실 세계의 의사결정 문제)은 Service에, 서비스 로직은 Model에, 그리고 주인공인 자동차의 상태를 담고 자동차의 상태를 변경하는(예를 들어 전진 정도를 +1 하는) 객체(아마도 Car)는 도메인 계층에 담기로 했다.
그리고 DTO는 이번엔 정말로 데이터의 전송만 담당하게 설계할 예정이다.
마무리
오늘은 이걸로 끝이다. 하루동안 남은 시간도 많이 없고, 무엇보다 머리가 너무 아프다. 최근 1주일동안 빠르면 12시에 자서 오전 5시 반에 일어나는 생활을 했더니, 피로가 많이 쌓인 것 같았다. 오늘도 코드 리뷰 한다고 쉬지 못했으니... 지속 가능한 개발을 위해서 오늘은 11시에는 잠에 들려 한다.....
새로 알게된 점
1. domain, model, service 계층의 차이
사실 아직도 완벽하게 구분지을 수 있는건 아니지만, 이게 참 말로 설명하기 어렵게 감을 잡았다. Car, Account, Coffee 이런거 있잖나. 이게 domain 이다.
2. controller의 모니터링
이건 잘 몰랐는데, mvc 패턴에서는 model은 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야만 하고, controller는 모델이나 뷰의 변경을 모니터링 해야 한다고 한다. 나는 지난 과제에서 이걸 전혀 구현하지 않았던 것 같다.
그럼 이걸 어떻게 구현하나, 알아보니 옵저버 패턴을 사용하는 방법이 있다고 한다. 옵저버 패턴을 한번 공부 해봐야겠다!
2. 비즈니스 로직과 서비스 로직
현실 세계의 의사결정과 관련된 로직은 비즈니스 로직이고, 그 외는 서비스 로직이다. 자동차 경주를 예로 들면, 자동차는 실제로 전진하고, 자동차가 이동했는 지 아닌지 판단할 수 있고, 우승자를 결정한다. 반면에 자동차 객체를 생성하고, 입력 숫자를 검증하고, 랜덤 숫자를 생성하는 로직은 현실 세계와 관계가 없다. 애플리케이션 안에서만 일어나는 일이니까.
3. 단위 테스트 != TDD
충격이었다. TDD 안에 단위 테스트가 포함된게 아니었다니... 새로 알게 되서 다행이다.
4. DTO 는 데이터의 전송만을 담당한다.
데이터를 저장하는 목적이 아니다. 결과와 상관없이 그 사실을 알고 있어야 한다.
5. Pn 룰
코드 리뷰에 Pn 룰이라는게 있다고 한다. 리뷰 받는 상대에게 리뷰의 레벨을 적어주는 것. 확실히 리뷰 받는 사람의 결정에 큰 도움이 될 것 같다.
좋았던 점
1. 그래도 설계를 적은 시간에 끝낸 것
1주차에 비하면 장족의 발전이다.
2. 점점 독해지는 것
머리가 너무 아파도 그냥 진통제 한알 먹고 코드 리뷰 다는 내 모습을 보면서 참 독해졌다고 생각했다. 좋은 일 아닐까? 물론 건강은 챙기자...
3. 중요한 것들을 새로 알게된 것
특히 비즈니스 로직과 서비스 로직. 이건 1주차 과제할 때도 찾아봤는데, 그 때는 이해를 못했었다. 오늘 공부하니 이해가 돼서 매우 좋다!
아쉬웠던 점
1. 코드 리뷰 받은 것을 토대로 1주차 과제를 수정하지 못한 것
시간이 저얼대 없다... 4주차까지 다 끝내고 1주차 과제를 다시 한번 만들어 봐야겠다. 결과물이 꽤 많이 달라지는 것을 기대하고 있다.
2. DTO를 제대로 이해하지 못하고 사용했던 것
결과는 나쁘지 않아서 다행이었지만, 그래도 아쉬웠다. 학습에 할애할 시간이 더더더 필요하다!
도움이 된 자료들
| 코드 리뷰
| MVC(Model, View, Controller) Pattern
