TDD, CleanCode, Refactoring 4주차 정리

4주차

점진적 리팩토링
- 기존의 테스트가 깨지지 않는 선에서 리팩토링 하기
- 컴파일 에러가 발생하면 안된다.
일반적 상황
- 메소드에 인자가 추가되었다.
- 인스턴스 변수 타입이 변경되었다.
  - -> 컴파일 에러가 발생 , 에러 해결
위 방식 대로 리팩토링 하면 긍정적인 측면 보다. 부정적인 측면이 생길 수 있다.
우리가 연습해야할 리팩토링은 ?
- 메소드에 인자가 추가 되는 경우
  - 메소드를 그대로 복사하여 메소드 이름을 임시로 변경
  - 임시 메소드를 하나씩 실제 사용한 메소드와 변경
  - 더이상 이전 메소드가 존재하지 않으면, 이전 메소드를 제거 후 이름 변경
- 인스턴스 변수의 타입이 변경되는 경우
  - 새로운 인스턴스 변수 추가
  - String to Integer로 변경 시 일시적으로 두개 타입을 도시에 사용
  - 두개 변수에 동시에 데이터를 넣고 리팩토링
점진적 리팩토링 - TDD 에 대한 감이 생길때 시작
- 1단계 - 메소드를 다른 클래스로 이동
- 2단계 - 메소드에 인자 타입이나, 반환 타입이 변경 시
- 3단계 - 인스턴스 변수 타입이 변경되는 경우
  - 데이터의 중복을 만든다. (임시 변수를 만들고, 메소드에 인자가 추가되는 경우와 같이 점차 변경해나간다.)
리팩토링은 시간 날때마다 진행하는것이다.
객체지향 설계 및 구현 접근 방식은 ?
- Bottom Up 설계 및 구현
  - 구현에 초점을 맞추어 일단 구현 후 지속적 리팩토링을 통해 역할,책임,협력을 찾아 나간다.
- Top Down 구현 및 설계
  - 책임에 초점을 맞추어 전체적인 설계 후 구현
책임 주도 설계
- 책임을 수행할 적절한 객체를 찾아 책임을 할당하는 방식으로 협력을 설계
  - 클래스를 먼저 설계하는것이 아니다.
책임이란 ?
- 책임이란 객체가 유지해야할 정보와 수행해야할 행동
- 즉 객체가 무엇을 알고있는가 와 무엇을 할 수 있는가로 구성된다.
역할을 다른것으로 교체할 수있는 책임의 집합이다.
테스트 하기 쉬운 코드가 유연한 코드는 아니지만 연습하다 보면 유연한 코드가 될 수 있다.
유연한 설계를 지향한다면 컴파일타임 의존성을 런타임 의존성으로 대체한다.
- 의존성을 주입 한다.
런타임 의존성으로 대체하다보면 테스트하기 쉬운 설계가 가능해진다.
테스트하기 쉬운 설계를 지향하다보면 유연한 설계가 가능해지는 경험을 종종 할 수 있다.
책임 주도 설계가 진정한 대안인가 ?
- 책임 주도 설계에 익숙해지기 위해선, 부단한 노력과 시간이 필요.
- 책임 관점에서 사고하기 위해선 부단한 노력과 학습이 필요하다.
- 빠르게 구현 후 지속적 리팩토링
- TDD 사이클을 반복해 설계의 품질을 높힌다.
  - 리팩토링 시 객체지향 설계 체조원친, 클린코드 설계 원칙을 지키면서..