일화

악취 포럼에서 우연히 발견한 일화 중 하나는 자바로 작성한 툴킷 개발 프로젝트와 관련이 있다. 제품 출시 바로 전에, 팀에 속하지 않은 외부 전문가가 체계적인 시스템 검토를 수행하여 소프트웨어의 설계 품질을 평가했다.

검토 과정에서 findDiff()라는 이름이 붙은 메서드가 하나만 있는 Diff 클래스를 발견했다. findDiff() 메서드는 csv(comma separated values) 파일을 두 개 받아 파일 사이의 차이점을 보고한다. 클래스에 명령 추상화 악취가 있음이 명백했다.

설계를 자세히 검토한 결과, 대다수 클래스에 ‘generate’, ‘report’, ‘process’, ‘parse’와 같은 동사로 시작하는 이름이 있음을 발견했다. 이런 클래스에는 대부분 공개 메서드가 한 개뿐이며, 다른 메서드는 내부 도우미 메서드로 동작한다. 클래스 상속은 거의 사용하지 않았다(인터페이스 상속은 사용했지만, 주로 Comparable과 Cloneable과 같은 표준 인터페이스를 구현하는 것이 목적이었다). 더 큰 문제도 발견했다. 설계가 ‘객체 지향적인 분해’가 아닌 ‘기능적인 분해’를 따랐다는 점이다!

툴킷 설계를 다시 검토한 결과, 객체 지향 분해가 프로젝트에 더 이익을 줄 수 있음을 알게 되었다. 객체 지향 접근 방식은 새로운 기능을 더 쉽게 구현할 수 있게 하면서 변화에 적응하도록 도와줄 수 있기 때문이다. 툴킷은 뭔가를 ‘하는’ 도구의 집합이므로, 개발자들은 무의식적으로 ‘기능적인 분해’ 접근 방식을 사용하여 소프트웨어를 설계하고 발전시켰다.

설계 검토 결과는 개발 팀을 놀라게 했다! 개발 팀은 프로젝트의 구조적인 핵심 문제의 원인 중 하나로 ‘절차적인 프로그래밍’ 사고법은 결코 예상하지 못했다. 개발 팀에는 경험이 풍부한 설계자가 있었음에도 이 같은 주요한 문제를 간과했다.

하지만 객체 지향 분해 접근법에 따라 툴킷을 바꾸는 작업은 전체 툴킷의 아키텍처를 재구성하는 것이다. 이미 많은 고객이 툴킷을 사용하고 있었기에 이런 리엔지니어링(Reengineering) 활동을 계속 진행하면 위험성이 커진다. 따라서 관리층에서는 현재 설계를 감수하기로 결정했다.

이 일화에서는 다음 세 가지 통찰력을 얻을 수 있다.

• 심지어 개인이 프로젝트의 일부이거나 프로젝트에 익숙할 때조차도 명백한 설계 결함을 간과하기 쉽다. 경험에 따르면, 프로젝트 외부에 속한 전문가가 주기적으로 하는 체계적인 설계 검토는 소프트웨어의 설계 품질을 개선할 기회를 파악하는 데 도움을 준다.[4]

• 특정 악취의 존재는 종종 설계에 더 큰 문제가 있음을 나타낸다. 여기서는 명령 추상화 악취 뒤에 숨은 원인을 밝히니 더 큰 문제인 ‘기능적인 분해’가 드러났다.

• 대다수 심각한 문제를 종종 배포 직전에 발견한다는 사실은 역설적이다. 이런 경우 너무 늦은 설계 ‘수정’은 아주 위험하다. 따라서 악취를 배우고 전반적인 개발 주기에 걸쳐 악취를 회피하는 관례는 설계 품질을 유지하고 기술 부채를 피하는 과정에서 아주 중요하다.