클린 코드(Clean Code) 요약

Clean Code - 로버트 C.마틴
 

워낙 유명한 책이기도 하고, 언젠간 읽어봐야지 하고 묵혀뒀던 책을 완독하는 것을 목표로 정리해보려고 한다.
 
 

9. 단위 테스트

- TDD : 실제 코드를 짜기 전에 단위 테스트 짜는 방식
 
- TDD 법칙
1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
 
- 테스트 코드는 실제 코드 못지 않게 깨끗하게 짜야 한다.
- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트이다.
- 테스트 케이스가 있으면 변경이 쉬워진다.
- 단일 assert 문 규칙 권장 (함수마다 assert문을 단 하나만 사용하기) => 적을수록 좋다.
- 테스트 함수 하나는 개념 하나만 테스트하라
 
- F.I.R.S.T : 깨끗한 테스트를 위한 규칙

• 빠르게(Fast) : 테스트는 빨리 돌아야 한다.
• 독립적으로(Independent) : 각 테스트는 서로 의존하면 안된다.
• 반복가능하게 (Repeatable) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
• 자가검증하는 (Self-Vaildating) : 테스트는 boolean 값으로 결과를 내야 한다.
• 적시에 (Timely) : 테스트코드는 실제 코드 구현전에 구현해야한다.

---

 

10. 클래스

- 클래스는 작아야 한다. (맡은 책임)

• 클래스 이름은 해당 클래스 책임을 기술해야 한다. (간단명료하게)
• 단일 책임 원칙 SRP(Single Responsibility Principle) : 클래스는 변경할 이유가 하나여야 한다.
• 클래스는 인스턴스 변수 수가 작아야 한다. (응집도가 높아야 한다) => 인스턴스 변수가 많다 = 새로운 클래스로 쪼개야 한다.
• OCP (Open-Closed Principle) : 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다
• DIP (Dependency Inversion Principle) : 클래스는 상세한 구현이 아니라 추상화에 의존해야 한다. => 상세한 구현에 의존하는 코드는 테스트가 어렵다.

---

 

11. 시스템

• 시스템 제작과 시스템 사용을 분리하라

• 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 '준비 과정'과 준비과정 이후에이어지는 '런타임 로직'을 분리해야 한다.
• 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다.
• 의존성 주입(DI) : 제어 역전 기법을 의존성 관리에 적용한 매커니즘
• ‘처음부터 올바르게’ 시스템을 만들 수 있다는 믿음은 미신이다. 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현하고, 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.
• TDD와 리팩터링은 코드 수준에서 시스템을 조정하기 쉽게 만든다
• 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 의사 결정이 가능해진다
• 명백한 가치가 있을때에 표준을 현명하게 사용하라 => 표준에 집착하게되면 고객 가치가 뒷전으로 밀릴수 있다

---

12. 창발성

• 모든 테스트를 실행하라 : 테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춤으로서, 설계 품질이 높아진다.
• 중복을 없애고 재사용성을 높여라
• 코드는 개발자의 의도를 분명히 표현해야 한다.

좋은 이름을 선택한다.
함수와 클래스 크기를 가능한 줄인다.
표준 명칭을 사용한다. ex) 클래스 이름에 패턴 이름 넣기
단위 테스트 케이스를 꼼꼼히 작성한다.

• 클래스와 매서드 수를 최소로 줄여라

---

13. 동시성

• 동시성 : 결합을 없애는 전략 (‘무엇’과 ‘언제’를 분리)
• 필요한 이유 : 병렬 처리로 응답 시간과 작업 처리량 개선