창발성

창발적 설계로 깔끔한 코드를 구현하자

우리는 켄트 백이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿고 있습니다. 켄트 벡은 다음 규칙을 따르면 설계는 '단순하다'라고 말합니다.

• 모든 테스트를 실행한다.
• 중복을 없앤다.
• 프로그래머 의도를 표현한다.
• 클래스와 메서드 수를 최소로 줄인다.

위의 순서는 중요도 순서로 배치되어 있습니다.

단순한 설계 규칙 1: 모든 테스트를 실행하라

테스트할 수 없는 시스템은 검증도 불가능합니다. 논란이 조금 존재하지만, 검증할 수 없는 시스템은 절대 출시해서는 안 됩니다.

 

테스트 케이스가 많을수록 테스트가 쉽게 코드를 작성할 수 있습니다. 결국 테스트가 가능한 시스템을 만들면 더 나은 설계를 얻을 수 있습니다. 결합도가 높으면 테스트하기 어렵기에 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 적절히 결합도를 낮춰야 합니다.

단순한 설계 규칙 2~4: 리팩터링

테스트가 완성되었다면 코드를 정리해 나가야 합니다. 새로 추가된 코드가 시스템을 무너뜨릴 걱정은 없습니다. 꼼꼼히 작성된 테스트 케이스가 존재하기 때문입니다.

중복을 없애라

메서드 안에서 발생하는 중복을 줄여 소규모 재사용으로 변경한다면 단일 책임 원칙, 가시성, 재사용성 등에 도움을 줄 수 있습니다. 소규모 재사용에 대해 제대로 적용돼야 대규모 재사용이 가능합니다.

표현하라

자신이 이해하기 쉬운 코드를 작성하는 것은 매우 쉬운 일입니다. 하지만 읽는 사람이 이해하기 쉬운 코드를 작성하는 것은 큰 노력이 필요합니다. 프로젝트 비용의 대다수는 유지보수에 사용됩니다. 그렇기에 코드는 의도를 분명하게 드러낼 수 있어야 합니다. 의도가 분명히 드러난 코드는 다른 사람도 이해하기 쉽습니다.

• 좋은 이름을 선택한다.
• 함수의 클래스 크기를 가능한 줄인다.
• 표준 명칭을 사용한다.
• 단위 테스트 케이스를 꼼꼼히 작성한다.
• 많은 노력을 들인다!

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

클래스와 메서드 크기를 줄이고자 작은 클래스와 메서드를 무수히 만들면 득보다 실이 많아집니다. 그렇기에 우선순위에서도 가장 낮은 위치에 존재합니다. 중요한 것은 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 것이지 클래스와 메서드 수를 줄이는 것이 아님을 이해해야 합니다.

마치며

아무리 많은 이론적인 지식을 가진다고 한들 경험이 없으면 실질적으로 이해하기 어렵다고 생각합니다. 책을 읽으며 새로 깨달은 내용을 직접 코드로 작성해보는 것에도 이론적인 지식을 학습하는 것만큼 많은 시간을 투자해 나갈 것입니다. 어쩌면 이론적인 지식에 쏟은 시간의 배가 되는 시간을 투자해봐도 아깝지 않을 시간일 것으로 생각합니다.