TDD, 클린 코드 with Java 18기: 실시간 강의 정리(5)

전면 재개발의 악순환

• 처음부터 다시 시작하는 개발(빅뱅 전략)
  • 차세대, 고도화 등등
  • 하지만 이 전략은 서비스를 멈추는 등 문제가 많다.
    • 재설계 팀과 유지 보수팀의 경주
      • 새롭게 만드는 기간 동안 새로운 요구를 제한적으로 수용해야 하기 때문에 비즈니스 위험 요소가 발생한다.
    • 유지보수 역량 떨어짐으로 인해 또 다시 문제 발생
      • 개발자들이 기존 기능을 리팩토링하는 역량을 쌓지 못한다.
      • 부채를 갚아 나가기 위해 시작했으나 새로운 시스템으로 오픈하는 시점과 비슷한 수준의 부채를 떠안고 시작하게 된다.

점진적 리팩토링

• 위와 같은 문제점들 때문에 전면 재개발 보다는 점진적인 리팩토링을 해야한다.
• 새로운 요구를 수용하며 점진적으로 리팩토링할 수 있다.
• 개발자들이 리팩토링 역략을 쌓을 수 있으며, 부채를 만들 가능성이 낮다.

코드 리팩토링

• AS-IS와 TO-BE가 공존하는 시점을 만들어야 한다.
• AS IS → AS IS & TO BE → TO BE

정적 팩토리 메서드 기준

• 생성자의 의도를 이름을 통해 들어내는 경우
• 캐싱과 같은 새로운 기능을 추가하는 경우
• 이외의 경우 생성자로 충분히 해결 가능할 것으로 보인다.

서비스 레이어에서 비즈니스 로직 존재

• TDD가 힘들다.
• 물론 모킹툴의 등장으로 이전 보다는 쉽게 TDD를 할 수 있게 되긴하였다.
  • 하지만 여전히 테스트 코드 구현량이 너무 많아 유지보수가 힘들어진다.
  • TDD를 잘하는 사람들
    • Mock 프레임워크를 최대한 늦게 사용한다.
    • 테스트 하기 쉬운 코드와 테스트 하기 어려운 코드를 분리한다.
      • 테스트 하기 쉬운 코드는 마지막 노드(말단, 의존성이 가장 적은 코드)로 이동한다.
      • 테스트 하기 어려운 코드는 사우이 노드로 이동한다.
    • 테스트 하기 쉬운 코드를 중심으로 테스트를 진행한다.
• 서비스 레이어
  • Repository Layer를 통해 도메인 객체 생성한다.
  • 도메인 객체에 메시지를 보낸다.
  • 상태가 변경된 도메인 객체를 Repository Layer를 통해 영구 저장한다.
  • 다른 서비스 레이어 객체를 호출한다.
  • Transaction, 권한 처리와 같이 infra 성격의 로직 구현한다.
  • 서비스 레이어에서는 비즈니스 로직이 존재해서는 안된다.
• 서비스 레이어의 로직을 도메인으로 이동
  • 우선 기존 로직에 대한 테스트 코드를 작성한다.
    • 보다 안정적으로 로직을 이동(리팩토링)하기 위함이다.
  • 대략적인 설계를 진행한다.
    • 각 로직이 어디로 가면 좋을지 가장 작은 노드(의존성이 가장 적은 부분)은 어디인지 찾는다.
  • 이러한 과정을 거친 후 로직을 이동시켜야 한다.

기타...

• 하나의 메서드는 하나의 역할만 하도록 한다.
• 메서드 호출이 선후가 있는 경우 개발자의 학습 비용이 높아지므로 지양하자.
• 도메인과 테이블이 무조건 1:1로 매핑되지는 않는다.
• 나중에 분리를 위해서라도 패키지는 무조건 단방향 의존관계를 가져야 한다.
• 변경되는 부분들을 인터페이스화 시킨다.