TDD, CleanCode, Refactoring 5주차 정리
사다리 타기 tdd 구현
- Out - in 접근 방식 vs in.- out 접근 방식
- TDD 로 구현하기에는 in.- out 방식이 더 적합하다.
- 가장 작은 단위의.객체부터 기능을 추가하면서 개발한다.
- 도메인 설계에서 가장 마지막 객체(의존관계가 없는)
- 가장 작은 단위의 객체가 구현되었으면, 객체를 더 작게 나눌수 없을까 고민
- 가장 작은 단위의 객체가 새롭게 만들어 졌으면 다시 고민
- 위와 같은 사이클을 계속하여 진행
- 책임주도설계로 사다리타기 재설계
- 책임주도설계 == 인터페이스 주도 설계
- 사다리 초기화(생성)
- 사다리 실행
- 사다리 결과 구하기
- 메시지를 먼저 결정하면 내부 상태가 어떻게 도출될지는 자연스럽게 정해진다.
- 책임 (객체가 해야할 행동, 메시지)를 먼저 정해보는것.
- 책임주도설계 == 인터페이스 주도 설계
- 패키지들 간의 의존성은 단방향으로 만들어야 한다.
- 추후에 큰변화 (분리) 할때 편리하다.
- sonarqube와 같은 정적 분석 도구를 활용해 cyclic dependency를 찾아준다.
- 서비스 로직은 어디에 구현하는것이좋을까 ?
- 일급 콜렉션을 쓴다.
- 3개 이상의 인스턴스 변수를 사용하지 않는다.
- 묻지 말고 시켜라. (데이터를 꺼내지말고 메시지를 던져라)
- 상태 변경의 주도권은 외부에 있지 않고 도메인이 가지고 있어야 한다.
- 도메인 설계, 구현 반복
- 요구사항을 분석후 도메인 설계.
- 한번에 완벽한 설계를 하겠다는 욕심을 버려라.
- 반복적인 설계와 구현을 통해 도메인에 대한 이해도를 높여야 한다.
- 도메인에 대한 이해도가 높아야 추상화 수준도 높아진다.