Clean Code

서술적인 이름을 사용하라. 길고 서술적인 이름이 짧고 어려운 이름보다 낫다. 길고 서술적인 이름이 길고 서술적인 주석보다 낫다. 이름을 붙일때는 일관성이 있어야 한다. 모듈내에서 함수 이름은 같은 문고, 명사, 동사를 사용한다. ​ 함수에서 이상적인 인수 개수는 0개다. 다음은 1개고, 다음은 2개. 3개는 가능한 피하는 편이 좋다. 4개 이상은 특별한 이유가 필요하다. 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 함수가 여러 가지를 처리한다고 대놓고 공표하는 셈이니까

명령과 조회를 분리하라 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다. ​ 특별한 이유 없이 의무감으로 혹은 프로세스에서 결정 하라고 하니까 마지못해 주석을 단다면 전적으로 시간낭비 주석을 달기로 결정했다면 충분한 시간을 들여 최고의 주석을 달도록 노력한다.

같은 이야기를 반복하는 주석, 오해할 여지가 있는 주석, 의무적으로 다는 주석, 있으나 마나 한 주석, 닫는 괄호에 다는 주석, 주석으로 처리한 코드

코드 형식은 중요. 코드 형식은 의사소통의 일환. 의사 소통은 전문 개발자의 일차적인 의무 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.

테스트코드는 신문 기사처럼 작성하라 테스트 코드는 실제 코드 못지 않게 중요하다. 테스크 코드는 이류 시민이 아니다. 테스트코드는 사고와 설계의 주의가 필요하다. 각 테스트는 테스트 자료를 만든다, 테스트 자료를 조작한다, 조작한 결과가 올바른지 확인하는 세 부분으로 나눠진다.

테스트 API코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다. 단순하고, 간결하고 표현력이 풍부해야 하지만, 실제 코드만큼 효율 적일 필요는 없다. 실제 환경이 아니라 테스트 환경에서 돌아가는 코드이기 때문. 테스트당 assert 하나, 하나의 테스트코드는 하나의 개념만

1. Fast : 테스트는 빨리 돌아야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다.
2. Independent: 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
3. Repeatable: 테스트는 어떤 환경에서도 반복 가능해야한다. 실제 환경, QA 환경, 노트북 환경, 집으로 가는 환경에서도 실행 가능해야 한다.
4. Self-Validating: 테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패다. 통과 여부를 알려고 로그 파일을 어렵게 만들어서는 안 된다.
5. Timely: 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다.

클래스 이름은 해당 클래스 책임을 기술해야 한다. 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 커서 그렇다. 클래스 설명은 만일(“if”), 그리고(“and”), 하며(“or”), 하지만(“but”)을 사용하지 않고서 25단어 내외로 가능해야 한다. 단일 책임 원칙. Single Reponsiblilty Principle 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇개를 두고 모두를 던져 넣고 싶은가? 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.

켄트 벡이 제시한 단순한 설계 규칙 4가지 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다.​

임계영역 설정으로 자료 범위를 제한하라. 쓰레드는 가능한 독립적으로 구현하라.