TDD, CleanCode, Refactoring 2주차 정리
코드 컨벤션을 지켜라
다른 개발자와 협업이나 미래의 나를 위해서라도.
공백 라인을 의미있게 사용해라.
공백 라인이 메소드의 기능을 나누게 되는 기준이 된다.
추후 리펙토링 시 메소드 기준으로 기능이 나뉜다는것을 알고 공백기준으로 메소드 리펙토링이 가능하다.
네이밍
객체지향 생활 체조 규칙 5 : 축약하지 말라.
적당한 길이의 이름을 찾는데 집중해라.
인스턴스 변수의 중복을 줄이고, 개수를 최소화 해라.
데이터를 꺼내려고 하지않고 메시지를 던져라
비지니스 로직과 ui로직의 분리.
테스트 가능한 코드와 불가능한 코드가 섞여 있으면 분리를 해야 한다.
어느 부분을 테스트 할 것인가 ?
경계값을 기준으로 테스트해야 한다.
Test Fixture를 위해서 생성자를 추가하는것이 옳은 일인가 ?
도메인이 DTO역할을 하는 경우라면 생성자를 추가하는것이 허용된다.
해당 경우에는 허용하는 것으로 ..
역할이 여러개이면 클래스 분리.
private메소드가 많아지면 테스트를 해야 하는것인가 ?
Private 메소드가 중요한 비지니스 역할을 한다면 새로운 클래스로 분리 되어야 한다.
분리 된다면 다른 클래스에서 접근 가능한 메소드가 되기때문에 테스트가 가능하다.
TDD
이번주 부터는 메소드 분리가 아닌 클래스 분리를 연습 하자
모든 원시값과 문자열을 포장한다.
일급 콜렉션을 쓴다.
생성자를 중복해 정의할 때는 정적 팩토리 메소드를 사용한다.
tdd는 리팩토링이 가장 중요하다.
테스트와 production code를 추가할 때 마다 리팩토링을 해야한다.
한번에 리팩토링을 하지 않고 테스트 케이스가 추가 될 때 마다 리팩토링을 하는 연습을 해야 한다.
todo리스트를 제대로 만드는것이 tdd를 잘하는 방법이다.
설게를 안하는것이 아니고 초반에 대략적인 설계가 필요하다.
초반 설계시 테스트 가능한 부분과 힘든 부분까지 설계를 한다면 설계를 잘한 것이다.
tdd 시작시 인풋과 아웃풋을 결정해야 한다.
Getter 를 쓰는순간 없애려고 노력해라 (상태를 가진 데이터를 꺼내는것보다 객체에 메시지를 보내서 일을 시켜라)
접근 제어자를 잘 사용해서 클래스 및 메소드의 접근 범위를 한정하는것도 도메인을 지키는 방법이다. 특히 default 접근 제어자는 도메인을 지키는 좋은 방법중 하나이다.
토이 프로젝트에선 최대한 조건을 강제해라
인덴트 1, 인스턴스 변수 2개 등의 극한의 조건을 걸어라.
Q&A
Void method 는 검증하는것만으로도 의미가 존재 하는지 ?
-> 존재한다.
Void method 내부에서도 인풋과 아웃풋이 있는 부분을 분리할 수 있을것이다. 그부분을 메소드로 분리해서 테스트 가능하다.
유효성 검사
도메인은 반드시 유효성 검사를 해야 하는것이 맞다.
그렇다고 controller나 다른 레이어에서 유효성검사를 안해도 된다는것은 아니다.