로버트 C.마틴의 클린 코드를 읽고 정리한 포스트입니다.
창발적이다?
창발적이다라는 한 마리의 개미 수준에서는 관찰되지 않던 특성이, 개미 집단의 수준에서는 비로소 관찰되는 것처럼 하위 수준에서는 관찰되지 않는 것들이 상위 수준에서 발생한다.
개개의 개미는 집을 지을 만한 지능이 없다. 그럼에도 불구하고 흰개비의 집합체는 역할이 서로 다른 개미들의 상호작용을 통해 거대한 탑을 만들어 내는 것이다.
이처럼 하위계층(구성 요소)에는 없는 특성이나 행동이 상위계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상을 창발성이라고 한다. 창발성을 영어로는 ‘불시에 솟아나는 특성’(emergent property) 또는 이머전스(emergence)라고 한다.
창발적 설계로 깔끔한 코드를 구현하자
착실하게 따르기만 하면 우수한 설계가 나오는, SRP(Single Responsibility Principle, 단일 책임 원칙)나 DIP(Dependency Inversion Principle, 의존 관계 역전 원칙)와 같은 원칙을 적용하기 쉬워지는 규칙 4가지
- 모든 테스트를 실행한다
- 중복을 없앤다
- 프로그래머 의도를 표현한다
- 클래스와 메서드 수를 최소로 줄인다
위 목록은 중요도 순임
단순한 설계 규칙 1: 모든 테스트를 실행하라
테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다.
결합도가 높으면 테스트 케이스를 작성하기 어렵다. 테스트 케이스르를 많이 작성할수록 개발자는 아래와 같은 도구를 사용해 결합도를 낮춘다. 따라서 설계 품질은 더욱 높아진다.
- DIP 원칙 적용
- 의존성 주입
- 인터페이스
- 추상화
테스트 케이스를 만들고 계속 돌려라라는 간단하고 단순한 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는, 객체 지향 방법론이 지향하는 목표를 저절로 달성한다.
단순한 설계 규칙 2~4: 리팩터링
테스트 케이스를 모두 작성했다면 이제 코드와 클래스를 점진적으로 리팩터링 해나간다. 코드 몇 줄을 추가할 때마다 잠시 멈추고 설계를 조감한다. 새로 추가하는 코드가 설계 품질을 낮추지 않는다면 깔끔히 정리한 후 테스트 케이스를 돌려 기존 기능을 깨뜨리지 않았다는 사실을 확인한다.
코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!
리팩터링 단계에서의 다양한 기법들
- 응집도 높이기
- 결합도 낮추기
- 관심사 분리
- 시스템 관심사를 모듈로 나누기
- 함수와 클래스 크기를 줄이기
- 더 나은 이름을 선택하기
또한 이 단계를 단순한 설계 규칙 중 나머지 3개를 적용해 중복을 제거하고, 프로그래머 의도를 표현하고, 클래스와 메서드 수를 최소로 줄이는 단계이기도 하다.
중복을 없애라
- 구현 중복의 예
int size() {} boolean isEmpty() {}하나의 함수로 표현하면 아래와 같다
boolean isEmpty() { return 0 == size(); } - 단 몇 줄이라도 중복을 제거해야 한다
- Template Method 패턴 : 고차원 중복을 제거할 목적으로 자주 사용하는 기법
- 두 개의 비슷한 함수를 중복되는 부분은 상위 클래스 안에 묶고, 중복되지 않은 부분은 상위 클래스 안에 있는 추상화된 클래스를 오버라이딩해서 빠진 ‘구멍’을 메운다
표현하라
자신이 이해하는 코드를 짜기는 쉽다. 하지만 나중에 유지보수할 사람이 코드를 짜는 사람만큼이나 깊이 이해할 가능성은 희박하다.
소프트웨어 프로젝트 비용 중 대다수는 유지보수에 들어가는만큼 코드를 이해하기 쉽게 짜야 한다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.
아래 방법들을 통해 유지보수가 쉬운 코드를 짜자.
- 좋은 이름 선택하기
- 함수와 클래스 크기를 줄이기
- 표준 명칭을 사용하기
- 단위 테스트 케이스를 꼼꼼히 작성하기
클래스와 메서드 수를 최소로 줄여라
때로는 무의미하고 독단적인 정책 탓에 클래스 수와 메서드 수가 늘어나기도 한다. 클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준이 좋은 예다. 자료 클래스와 동작 클래스는 무조건 분리해야 한다고 주장하는 개발자도 좋은 예다. 가능한 독단적인 견해는 멀리하고 실용적인 방식을 택하자.
클래스와 함수 수를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다.
Previous
‘[클린 코드 리뷰] 시스템 11장’ -> Previous
Next
‘[클린 코드 리뷰] 동시성 13장’ -> Next