TDD, CleanCode, Refactoring 3주차 정리

TDD, CleanCode, Refactoring 3주차 정리

tdd 사이클이 익숙해질때 까지 반복적으로 연습해야 한다.
- 가장 자신있는 언어로 반복 연습하는것을 추천.
- 힘들고 지칠땐 주제를 바꿔서 해보는것이 좋다.

시작하기

요구사항 분석을 통한 기능 목록 작성
객체설계를 통해 어느 부분 부터 구현할 지 생각하는것이 우선이다.
기능목록
- 주제에 대해서 가장 일반적인 기능들을 다 적어보자.
- 점차 작은 단위의 기능들도 정의
TDD로 구현할 기능 찾기
- 큰 부분을 작게 자르는 연습을 해야한다.
인풋과 아웃풋이 있는 케이스가 테스트 하기 쉽다.
메서드 하나에 모든 로직이 들어가 있으면 객체지향적인 구조보다 절차지향적 구조로 변질되게 된다.
리팩토링, 어디서 부터 시작할까 ?
1. 첫밴쨰는 메소드 분리부터 시작. (Naming Rename도 해야한다.)
  1. 메소드가 한가지 일만 잘하도록 구현한다.
    - 한가지 일만 하기 위해 메소드 라인을 제약하는것도 좋은 방법이다.
2. Indent를 줄이자.
  1. Else 예약어를 쓰지 않는다.
3. 클래스를 분리하자.
  1. 원시값과 문자열을 포장
  2. 일급 콜렉션을 사용한다.
  3. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않기.
  4. 메소드 인자수를 제한한다. 2개까지만 허용한다.
    1. 3개는 고민을 많이 하고, 4개는 절대 안된다.
    2. 비슷한 속성을 가진 인자수를 클래스로 만들어 보자.
      1. 속성과 라이프 사이클이 동일하면 쉽게 판단할 수 있다.
private method를 분리해서 단위테스트 해야하는 것이 아닌가 ? 라는 의구심
- private method를 다른 클래스로 만들어 public으로 open하는게 더 나은 구조는 아닐까 생각해보자.
새로운 클래스가 생성될때 테스트부터 만들어 보자.
상속(is-a) 조합(has-a)
- 일급 collection을 구현할 때 접근 방법으로 상속과 조합 방법으로 구현 가능
- 객체의 중복(Lotto와 WinningLotto)를 제거 할 때 상속과 조합 방법으로 구현 가능
상속은 의도하지 않은 인터페이스가 외부에 노출될 수 있다.
반면 조합을 사용하면 외부에 오픈할 인터페이스를 정의할 수 있다.
상속과 조합 중 어떤것이 좋을까 ?
- 상속 보단 객체 조합을 사용해라.
- 코드의 재사용성 측면에선 상속이 유리. 유연성 측면에선 조합이 유리.
  - 변화에 빠르게 대응하는 것이 점점 더 중요, 현재는 재사용성 보다 유연성이 훨씬 더 중요하다.
  - 확실하게 경험을 하는것이 좋다 !
생성자 대신 정적 팩토리 메소드 사용.
- 생성자의 수가 늘어날수록 클래스를 사용하기 위한 유연성은 높아진다.
가변객체보단 불변 객체를 사용해라.
불변 객체 만들기
- 객체의 상태를 변경하는 메소드를 제공하지 않는다.
- 클래스를 확장 할 수 없도록 한다. (Public final class)
- 모든 필드를 final로 선언한다.
  - 내부에 collection이 있다면 collection도 불변인지 확인해야 한다.
- 모든 필드를 private으로 선언한다.
immutable object 가 좋은것은 알겠는데, 인스턴스가 많이 생성되어 성능이 떨어지지 않을까 ?
- 캐싱을 적용해 인스턴스 생성을 최소화 할 수 있는 방법이 있는지 검토
  - 캐싱은 일반적으로 Map(key - value) 형식을 가장 많이 사용된다.

성능외에도 유지보수하기 좋은 코드, 읽기 좋은 코드, 유연한 코드, 버그 발생 가능성이 낮은 코드 와 같이 다양한 측면을 고려하면서 프로그래밍 하는습관을 가지자

경험해야할 학습 목표 - 사다리 타기

* TDD, 객체 지향 프로그래밍 연습
* 인터페이스를 추출하여 프로그래밍 하는 연습을 한다.
* stream, lambda를 사용해 프로그래밍하는 것을 연습.

경험할 객체 지향 생활 체조 원칙

한줄에 점 하나만 찍는다.
- Clean Code 가이드의 디미터 법칙을 지키는 것을 의미.
모든 엔티티는 작게
3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
getter / setter / property를 쓰지 않는다.

함수형 프로그래밍

함수형 프로그래밍은 input과 output이 항상 존재 하기 때문에 test하기 쉽다.
클래스 기반 함수를 모으로 메소드 레벨에서 함수형 프로그래밍에 맞게 설계 ?
람다를 쓰는게 중요한게 아니고 변경 가능성이 높은 부분을 인터페이스로 추출 할 수 있는지가 중요하다.