스프링 스터디 시작 전 Lotto Project. 그리고 인생 첫 코드리뷰

이번에 GDG on Campus Konkuk의 24-25 온보딩 이후 다양한 스터디들이 열렸고, 난 스프링 스터디에 참여하기로했다.

그리고 이 스터디를 하기전, 가벼운 Lotto Project와 함께 코드리뷰를 해주신다고 해서 설레는 마음으로 빠르게 코딩을 완료하고 PR을 날렸다.

Lotto Project는 우아한테크코스에서 프리코스 미션으로 사용하는 것으로 알고있어 꽤 유명한 리포지토리로 알고있다.

첫 번째 코드리뷰

PR을 올리고 코드리뷰가 시작됐는데, 엄청 많은 댓글들이 달려서 조금 놀랐지만 하나씩 읽어봤다.

이런 좋은 말들도 있었지만 어쨌든 코드리뷰는 비평을 들어야 성장한다고 생각해서 잠깐 기분만 좋았다가 접어뒀다..

나의 코드에서 가장 큰 문제는 다음과 같았다.
1. 코드에서 관심사의 분리 (SoC, Seperation of Concerns) 가 잘 이루어지지 않았다.
2. 객체는 추상화된 모델인데, 최초에 의도한 것처럼 추상화된 역할이 구분되지 않았다. (= 역할이 모호하다)
3. 특히 Application.java 에서, UI역할을 의도한 클래스 치고는 너무 모호하다.

댓글이 많았지만 커밋에서 부분부분에 이런 점들이 많았고, 멋진 스터디장님은 한줄한줄 리뷰해주셨다.

결국 계속 소통하면서 이렇게 4개의 커밋을 추가로했고,

추가적으로 스터디장님이 각 클래스별 의도된 역할과 어떻게 상호작용하고 있는지를 주석으로 작성해달라고 하셔서 이 부분에 대해 적용을 한 뒤 두 번째 Pull Request를 열었다.

두 번째 코드리뷰

첫 번째 PR에서 받은 사항들을 리팩토링하여 다시 코드리뷰를 요청했다.

몇가지 저번 리뷰때 수정 권유 받은 사항들과 함께 스터디장님의 개인적인 코멘트를 남겨주셨다.

I/O를 담당하고 있는 로직들을 Application.java 클래스에서 분리하기를 권유하신건데 스프링을 공부해봤기때문에 이 말이 무슨말인지 알았다.

사실 Spring Framework를 사용한 프로그램이었으면 당연히 이렇게 안했다. Controller-Service-Repository 같이 Layered Architecture에 대해 습관처럼 적용을 하고있었기 때문이다. 이런 상황에서도 Application.java에는 스프링을 호출하고 config하는 코드가 포함되는 것처럼 일반 java 코드에서도 UI를 담당하는(Spring에선 Controller) 클래스를 IO.java에 적용했다.

그리고 몇가지 추가적인 디테일 리뷰를 받고 아래의 요약문을 받았다.