[클린 코드] 12장 - 창발성

 

켄트 백은 단순한 설계 규칙 네 가지를 제시했어요. 이 규칙에 따라 설계하게 되면 코드 구조와 설계를 파악하기 쉬워지고, SRP나 DIP와 같은 원칙을 적용하기 쉬워진다고 생각했어요.

이번 챕터는 이 규칙에 대해 이야기해보려고 해요.

 

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

무엇보다 먼저, 설계는 의도한 대로 돌아가는 시스템을 내놓아야 해요. 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도대로 돌아가는지 검증할 간단한 방법이 없다면 그 가치를 인정받기 힘들어요.

테스트가 불가능한 시스템은 검증도 불가능해요. 검증이 불가능한 시스템을 출시하는 것은 위험한 일이에요. 

테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아져요. 크기가 작고 목적 하나만 수행하는 클래스가 나와요. SRP를 준수하는 클래스는 테스트가 훨씬 더 쉬워요. 

결합도가 높으면 테스트 케이스를 작성하기 어려워요. 테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춰요. 이것을 통해 설계 품질은 더 높아져요.

"테스트 케이스를 만들고 계속 돌려라"를 지키면 시스템은 낮은 결합도와 높은 응집력을 갖게되요.

 

🛠 Refactoring

테스트 케이스를 모두 작성했다면 이제 코드와 클래스를 정리해도 괜찮아요. 코드 몇 줄을 추가할 때마다 잠시 멈추고 설계를 조감해요. 새로 추가하는 코드가 설계 품질을 낮춘다면 깔끔히 정리한 후 테스트 케이스를 돌려 기존 기능을 깨뜨리지 않았다는 사실을 확인해요.

아래의 규칙 2~4는 리팩터링에 속하는 작업이에요.

 

단순한 설계 규칙 2: 중복을 없애라

똑같은 코드는 당연히 중복이며, 비슷한 코드는 더 비슷하게 고쳐주면 리팩터링이 쉬워져요. 구현 중복도 중복이에요. 공통적인 코드를 새 메서드로 뽑고 보면 클래스가 SRP를 위반할 수 있어요. 

 

나의 생각: 평소에 중복되는 코드를 매우 싫어하는 편이에요. 중복을 추출해 메서드로 만들어주는 것은 좋은 작업이라 여겼는데 클래스의 SRP를 위반하게 만드는 행위일 수 있다는 것을 알게 되었어요. 그런데 이 추출만을 위해서 새로운 클래스를 생성해주고, 그 클래스를 통해 작업하면 다른 객체와의 결합도가 올라가는 결과가 될 수도 있을 것 같아요(일반적으로). 관점에 따라 추출된 메서드는 특정 목적을 위한 작업의 일부라고 생각하면 객체의 SRP를 해치지 않는다고 볼 수 있겠지만, 어떤 객체가 하는 일의 범위를 넓힐 수 있기 때문에 앞으로 신경 써야 할 것 같아요. 

 

단순한 설계 규칙 3: 표현하라

자신이 이해하는 코드를 짜기는 쉬워요. 코드를 짜는 동안에도 문제에 빠져서 코드를 구석구석 이해하기 때문이에요. 하지만 나중에 코드를 유지 보수할 사람이 코드를 짜는 사람만큼이나 문제를 이해할 가능성은 적어요.

소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어가요. 그래서 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워져요. 그리고 결함이 줄어들고 유지보수 비용이 적게 들어요.

 

명백한 코드를 작성하기 위해서는 우선, 좋은 이름을 선택해요.

둘째, 함수와 클래스 크기를 가능한 줄여요.

셋째, 표준 명칭을 사용해요.

넷째, 단위 테스트 케이스를 꼼꼼히 작성해요. 테스트 케이스는 소위 '예제로 보여주는 문서'예요. 다시 말해, 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어와요.

 

가장 중요한 것은 결국, 다음에 코드를 읽을 사람을 배려해 주의를 기울이는 것이에요.

 

단순한 설계 규칙 4: 클래스와 메서드 수를 최소로 줄여라

여기서 중요한 포인트는 '가능한 최대로' 줄이는 것이에요. 중복 제거, 의도 표현, SRP 준수 등의 좋은 목표도 극단으로 치달으면 득 보다 실이 많아져요. 클래스와 메서드를 줄이기 위해 작은 사이즈의 클래스와 메서드가 무분별하게 생성되면 오히려 문제가 생겨요. 이 규칙은 간단한 설계 규칙 네 개 중 우선순위가 가장 낮아요.

 

나의 생각: 이 주제는 설계할 때 정말 주관적으로 해석된다고 생각해요. '작은' 클래스의 기준도 없을뿐더러 '가능한 최대로' 역시 기준이 없기 때문이에요. 상황마다 다르겠지만 클래스와 메서드 수를 최소로 줄이는 것은 중복을 제거하는 것과 상충하는 측면이 있을 것 같아요. 그래서 저자 역시 우선순위를 둔 것 같아요. 저 역시도 클래스 수를 줄이기 위해 노력하기보단 중복을 제거하고, SRP를 지키는데 신경을 쓸 것 같아요. 다만, 무분별하게 클래스를 생성하거나 충분히 다른 메서드에 포함될 수 있는 개념인데 굳이 메서드를 추출해서 사용하는 등에 대한 것은 경계하려고 해요.

 

 

클린코드(Clean Code) by Robert.C.Martin