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

유효성 체크는 어디서 해야 하나

• 유효성 체크는 생성자에서 하는게 좋다.

immutable(불변 객체) VS mutable(가변 객체)

• 메서드를 통해서 인스턴스 상태값을 바꿀 수 있으면 이는 가변 객체이다.
  • 가변 객체는 오류 발생의 가능성이 너무 크다. 특히 멀티 스레드 환경에서 가변 객체는 오류를 일으킬 가능성이 크다.
  • 가변 객체는 값이 어디서 바뀌었는지 알 수 없어 디버깅이 매우 힘들다.
• 불변 객체는 유지 보수성을 높여준다.
  • 따라서 모든 객체를 불변 객체로 만들어보도록 합시다.
• 불변 객체는 상태값 변경할 때 마다 새로운 인스턴스를 만들어야 하는데 메모리 이슈를 발생시키지 않을까?

  • 원시값의 경우 constant pool에 캐싱을 하기 때문에 메모리 이슈가 발생하지 않는다.

  • 그러니 불변객체를 위한 캐싱을 구현하면 걱정되는 메모리 이슈를 해결할 수 있다.

  • 로또 미션 예시
    요구사항

    • 1만명의 사용자가 동시에 당첨 여부를 확인할 수 있어야하며 1명의 사용자는 평균 5장의 로또를 구매한 상태이다.

    이슈사항

    • 30만개의 LottoNumber를 만들어야 한다.

    해결방법

    • 초기화 블록과 Map을 이용하여 캐싱을 구현한다.
      

유지보수 역량

• 기존 코드에 영향을 최소한으로 미치면서 리팩토링하는 연습을 해야 한다.
• 점진적인 리팩토링을 할 수 있어야 한다.

점진적인 리팩토링

• 점진적으로 리팩토링할 수 있는 능력은 중요하다.
• 리팩토링 방식
  • 조금씩 천천히 진행해야 한다.
  • 중복 코드를 만들면서 리팩토링 해야 한다.
    • 컴파일 오류 없이 안전하게 리팩토링 할 수 있는 방식이다.
    • 리팩토링이 끝나지 않은 상태에서 바로 버그를 픽스하여 배포할 수 있다.(기존 코드가 존재하고 있기 때문)
• 점진적인 리팩토링 전략
  AS-IS: 기존 코드
  TO-BE: 개선 코드
  • 1단계: AS-IS와 TO-BE 코드 추가
  • 2단계: AS-IS를 의존하는 코드들이 TO-BE 코드를 사용하도록 점진적으로 리팩토링
  • 3단계: AS-IS를 의존하는 코드들이 TO-BE 코드를 사용하면 AS-IS 코드를 삭제

객체 설계(인터페이스)

• 자주 변경되는 부분을 인테페이스로 만들어야한다.
• 단 인터페이스를 남용하여 개발하면 오버 엔지니어링이 될 수 있으니 주의해야한다.
  • 인터페이스를 남용하는 개발은 복잡성을 높여 유지보수를 어렵게 만들 수 있다.
  • 실제로 요구 사항이 엄청 자주 바뀌지는 않는다.
  • 그러니 인터페이스와 디자인 패턴을 남용하지 마라. 클래스를 작게 만들고 메서드가 한가지 일만 하게 해도 충분히 유지보수하기 좋은 코드를 만들 수 있다.
  • 정말 필요한 곳에서 인터페이스를 사용해야 한다.
    • Tip) 인터페이스가 남발되는 곳을 찾아봐라

레거시 코드 리팩토링

• layerd architecture
  • Web Layer, Service Layer, Repository Layer, Domain Model
  • 비즈니스 로직은 Domain Model에서 만들어져야 한다.
  • Service Layer
    • 얇은 레이어(thin layer)
    • 해당 계층은 로직이 많아서는 안된다. 그저 흐름 제어만 해야 한다.
      • 다른 서비스 레이어 호출
      • 도매인 객체에 메시지를 보내는 역할
      • Repository Layer를 통해 도메인 객체를 만드는 역할