[클린 코드 Clean Code] 9장 - 11장 정리

9장 - 단위 테스트

• 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야한다.
• 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
  • 테스트 케이스가 있으면 변경이 두렵지 않다.( 없었으면 모든 변경이 잠정적인 버그다.)
  • 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.
• 깨끗한 테스트 코드를 만들려면 가독성, 가독성, 또 가독성이 필요하다. -> given / then / when 사용하는 이유
• 깨끗한 테스트는 다음 다섯가지 규칙을 따른다. 각 규칙에서 첫 글자를 따오면 FIRST가 된다. 
  1. Fast(빠르게) : 테스트는 빨라야한다. 빨라야 자주 돌리면서 문제를 찾아내 수정한다. 
  2. Independent(독립적으로): 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야한다.
  3. Repeatable(반복가능하게): 테스트는 어떤 환경에서도 반복 가능해야한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다. 
  4. Self-Validating(자가검증하는): 테스트는 부울(bool) 값으로 결과를 내야한다. 성공 아니면 실패여야 한다. 객관적이어야 명확하다. 
  5. Timely(적시에): 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지 모른다.

10장 - 클래스 

• 클래스는 작아야 한다. 함수는 물리적인 행 수로 크기를 측정하지만 클래스는 맡은 책임으로 크기를 책정한다.
• 클래스 이름은 해당 클래스 책임을 기술해야 한다.
• 응집도가 높은 클래스는 바람직하지 않다. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단의로 묶인다는 의미기 때문이다.
• 변경하기 쉬운 클래스로 만드는게 좋다. 밑에 예시를 봐보자. 

public class Sql{
    public Sql(String table, Column[] columns)
    public String create()
    public String insert(Object[] fields)
    public String selectAll()
}

위와 같이 새로운 SQL문을 지원하려면 위에 코드를 수정해야한다. SRP(단일 책임 원칙)을 위반한다. 변경하기 쉬운 클래스로 바꿔보자.

abstract public class Sql{
    public sql(String table, Column[] columns)
    abstract public String generate();
}

public class CreateSql extends Sql{
    public CreateSql(String table, Column[] colummns)
    @Override public String generate()
}

public class SelectSql extends Sql{
    public SelectSql(String table, Column[] colummns)
    @Override public String generate()
}

public class InsertSql extends Sql{
    public InsertSql(String table, Column[] colummns)
    @Override public String generate()
}

public class SelectWithCriteriaSql extends Sql{
    public SelectWithCriteriaSql(String table, Column[] colummns)
    @Override public String generate()
}

위와 같이 리팩토링 하면 클래스는 극도로 단순하고 이해하기가 쉬워진다. update 문을 추가할 때 기존 클래스는 변경할 필요없고 sql 클래스를 상속받아 새로운 update 클래스를 만들면 끝이다. 위처럼 하면 다른 클래스를 건들 필요는 없고 확장성이 좋은 구조로 변경된다. OCP(Open Closed Principal) & SRP(Single Responsibility Principal)을 지킬 수 있는 좋은 구조가 된다.

 

11장 - 시스템

• 처음부터 올바른 시스템을 만들 수 없다. 우리는 주어진 사용자 스토리에 맞춰 시스템을 구현하고 확장해 나가야한다.
• 최선의 시스템 구조는 각기 POJO 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. ->  클래스간의 결합도를 낮추고 각 클래스 내부의 기능들이 응집도를 갖도록 설계되었다.
• 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 도시든 소프트웨어 프로젝트든 한 사람이 모든 결정을 내리기 어렵다.
• 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.