도서 리뷰 시리즈 - 클린 소프트웨어

 

출처

『클린 소프트웨어』 | 로버트 C. 마틴 저 / 이용원, 김정민, 정지호 공역 | 제이펍 | 2017년 05월 15일

 

한 줄 리뷰

설계를 처음 시작하는 개발자에 추천합니다.

 

에자일 설계

설계의 악취

소프트웨어에 다음과 같은 느낌이 든다면 소프트웨어 재설계가 필요한 것을 알 수 있다.

 

부동성

다른 시스템에 재사용할 수 있는 컴포넌트를 구분하기 어려울 때

 

경직성

시스템을 변경하려면 시스템의 다른 부분들까지 많이 변경이 필요할 때

 

취약성

시스템을 변경하면 그 부분과 개념적으로 아무런 관련이 없는 부분이 망가질 때

 

점착성

변경 사항이 발생했을 때 설계를 유지하기 어려워 옳은 동작을 하기 어려울 때

 

불필요한 복잡성

현재 시점에서 필요하지 않은 설계가 포함이 되어 있을 때

 

불필요한 반복

단일 추상 개념으로 통합할 수 있는 반복적인 구조가 설계에 포함될 때

 

불투명성

이해하기 어렵고 의도를 잘 표현하지 못할 때

 

원칙

단일 책임 원칙(SRP)

한 클래스는 한 가지 변경 사유로만 수정되어야 함

퍼사드나 프록시 패턴을 사용해 책임을 분리하여 해결

 

개방 폐쇄 원칙(OCP)

클래스는 확장에는 열려야 하고, 변경에는 닫혀야 함

 

리스코프 치환 원칙(LSP)

서브 클래스는 기반 클래스로 대체 가능해야 함

 

인터페이스 분리 원칙(ISP)

클래스의 메소드를 직접 호출하지 않고, 고유의 인터페이스를 만들어서 사용하게 해야 함

 

의존 관계 역전 원칙(DIP)

상위/하위 관계, 구현은 추상화에 의존해야 하며, 추상화는 구현에 의존해서는 안됨

 

테스트 코드

클린 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성. 어쩌면 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다. 테스트 코드에서 가독성을 높이려면? 여느 코드와 마찬가지다. 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

 

given-when-then이라는 관례를 사용하면 테스트 코드를 읽기가 쉬워진다. 하지만 불행하게도, 테스트를 분리하면 중복되는 코드가 많아진다. 그러므로 가장 좋은 규칙은 "개념 당 assert 문 수를 최소한 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"라고 하겠다.

 

F.I.R.S.T.

빠르게 Fast: 테스트는 빨라야 한다.

독립적으로 Independent: 각 테스트는 서로 의존하면 안 된다.

반복 가능하게 Repeatable: 테스트는 어떤 환경에서도 반복이 가능해야 한다.

자가 검증하는 Self-Validating: 테스트는 성공 아니면 실패다.

적시에 Timely: 테스트는 적시에 작성해야 한다.

 

---

 

 

도서 리뷰 시리즈 - 클린 소프트웨어