Yunseok's Dev Blog

배운 것을 적는 블로그입니다.

달랩 GOOSGBT 스터디 13번째 회고

13장 스나이퍼가 입찰하다

처음에는 동작하는 것이 거의 없지만 큰 덩어리들에 관해 생각하느라 진행이 처지지 않도록 빈 구현으로 당면한 과제에 집중했다. 단순히 기능들을 계속 추가하는 것이 아니라 코드를 작성하고 정리하는 과정을 반복했다. 이 정리하는 과정을 리팩토링이라고 부른다. 리팩토링을 하는 이유는 설계를 개선하기 위해서다. 클래스가 단위 테스트로 보호받고 있으므로 안전하게 리팩토링할 수 있었다. 정리할 때는 관심사의 분리를 통해 의존성을 관리했다. 단일 책임 원칙을 지키면서 했다. 결과적으로는 핵심 구현의 주위를 감싸는 계층을 만들었다. 이 해당 계층은 외부 의존성으로부터 핵심 구현을 보호한다. 231페이지의 그림이 우리의 최종 목표인데 이 그림을 자세히 살펴보면 클린 코드의 그 원형 모양이랑 같다.

설계에 지나치게 많은 노력을 들이는 팀도 있지만, 경험상 대다수 팀은 코드를 더 명확히 만드는 데 너무 적은 시간을 들어서 유지 보수 부담으로 그 대가를 치른다.

도메인을 이해하지 못하면 더 어렵게 느껴진다.

좋았던 점

  • 실습을 통해 코드에 대한 고민을 하고 책에 있는 코드를 봐서 잘 읽혔다.

아쉬운 점

  • 번역이 아쉬웠다. 클래스 고유의 이름을 한글로 번역했다. 그래서 그림이 나타내는 것이 클래스임을 알아채지 못했다.

Sources