[우아한테크코스 6기 백엔드] 사다리 타기 회고

⭐️ 들어가기 전

우아한테크코스 레벨1의 두번째 미션은 사다리 타기 미션이다.

 

이 미션의 목표는 TDD이다.
켄트백의 책에 따르면 TDD란 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술이라고 한다.
TDD는 테스트 기술이 아니라 분석 기술이며, 설계 기술이다.

 

TDD를 잠깐 설명하고 넘어가겠다.

TDD는 디버깅 시간을 줄여주고, 동작하는 문서 역할을 하고, 변화에 대한 두려움을 줄여준다고 한다.

나는 모르겠다...

TDD는 RED(Fail) GREEN(Pass) BLUE(Refactor) 사이클을 가진다.
실패 테스트를 먼저 작성하고 프로덕션 코드를 작성한다. 테스트를 통과할 정도의 최소한의 코드만 작성한다.
아무래도 이렇게 하면 점진적으로 설계하고 개선할 수 있고, 과도한 설계를 줄일 수 있을 것이다.

 

나는 TDD를 좋아하지 않는다.
나는 자동완성을 굉장히 사랑하는 편인데 테스트 코드를 먼저 작성할 때 자동완성이 안돼서 너무 불편하다.
그리고 리팩토링하는 과정이 너무 번거롭다. 처음부터 설계를 잘하고 시작하면 좋지 않을까??

안되니까 TDD를 하겠지...

이번 미션은 자동차 경주 미션과 난이도 차이가 비슷했다.
그래서 그런가 생각보다 미션 완성이 빨리 끝났다.
솔직히 말해서 리팩토링할거리는 많았지만 번아웃이 와서 귀찮았었다.

 

이번 미션에 대해서는 이것들에 대해서 되짚고 넘어가겠다.

1. 코드 간소화
2. 일급 컬렉션
3. 원시 값 포장
4. 정적 팩토리 메서드

⭐️ 코드 간소화

step1은 뽀로로와 페어로 프로그래밍했다.
개인적인 생각이지만 생각이 동기화가 잘돼서 코드 작성 속도가 빨랐다.
그리고 뽀로로가 Stream을 굉장히 잘 알아서 많은 것들을 배울 수 있었다.

이 자극으로 모던자바인액션을 열심히 읽고 있다.

문제는 페어와 헤어지고 나서이다.
다시 또 정신병이 도져서 왕창 추상화하고, 확장성을 높였다.
PR를 날리고 첫 피드백을 받은 새벽에 갑자기 눈이 떠졌다.
잠이 안와서 데일리 조인 아톰의 코드를 봤다.
코드가 간결하고, 잘 읽어졌다.

 

문득 이런 생각이 들었다.

다른 사람들은 내 코드가 잘 이해가 됐을까??

자동차 경주를 페어로 했던 산초에게도 미안함이 들었다.

 

이후 리뷰어에게 양해를 구하고 프로젝트 전체를 리팩토링했다.
view 추상화, request dto, 예외 처리, config 등등 당장 필요없는 모든 것들을 지웠다.

 

프로젝트 규모에 맞게 코드를 작성하니 코드 수가 확실하게 줄어들고, 쉽게 이해할 수 있었다.

⭐️ 일급 컬렉션

사다리 타기 미션의 요구사항에 일급 컬렉션을 사용하라는 것이 있었다.
나는 일급 컬렉션을 우아한테크코스 프리코스에서 처음 알았었다. 향로님이 작성하신 일급 컬렉션 글을 감명깊게 봐서 동아리에서 그 주제로 세미나도 참여했었다.

 

사다리 타기 미션에는 Ladder, Floor, Rungs 등등 다양한 일급컬렉션이 만들어졌다.
일급 컬렉션에 관한 글을 나도 작성했으니 찾아보길 바란다.
일급 컬렉션을 쓰면 확실히 비즈니스 로직이 컬렉션 내부에 들어가서 편하다.

⭐️ 정적 팩토리 메서드

일급 컬렉션을 사용하면서 객체들을 생성하는 로직들이 생성자에 많이 추가됐었다.
생성자에서의 생성 로직을 분리하고, 필드와 파라미터를 일치시키기 위해서 정적 팩토리 메서드를 자주 사용했다.
객체 생성 로직이 복잡해지면 사용할만하다.
해당 내용을 블로그로 작성했으니 찾아보길 바란다.

⭐️ 원시 값 포장

원시 값 포장도 미션 요구사항에 있었다.
처음에는 포장할 수 있었던 모든 것들을 포장했었다.
하지만 위에서 말했던 전체적인 리팩토링에서 필요한 부분에만 포장했다.
높이 같은 경우 height를 받아서 사다리 생성의 파라미터에 한 번 들어가고 사용되지 않는다. 이런 경우는 원시 값 포장이 불필요하다고 여겨서 빼줬다.

⭐️ 끝내며

코드를 간소화했다고 위에서 엄청 말했지만 아직도 response dto를 포기하지 못했다. view에서 domain에 접근하지 못하도록 dto를 사용했다.
나같은 경우 mvc는 의존을 분리하고, 권한을 분리하는 것이라고 생각한다. view는 도메인을 몰라야한다.
하지만 이 정도 규모에서 view에서 domain의 비즈니스 로직을 사용하지 않고, getter같은 것들만 사용하면 문제 없다는 의견도 많다.
다음 미션을 그런 시도를 하고 피드백을 받아볼까 한다.

 

다음 미션은 블랙잭이다. 대충 읽어보니 다음 기술들을 사용할 것 같다.

1. 캐싱
2. 상태 패턴
3. 추상 클래스
4. 클래스 상속, 인터페이스 구현

상당히 복잡해 보여서 현재 꺼졌던 열정이 다시 불타오를 것 같다. (아마도)

 

사다리 타기 미션을 하면서 코드를 간소화하는 이점들을 다시 생각해볼 수 있었고, 정적 팩토리와 방어적 복사, 일급 컬렉션의 개념들에 대해서 다시 한 번 정리할 수 있었다.

 

내가 작성한 코드는 링크에서 확인할 수 있다.
사다리 타기 코드