클래스 - 특히 여러 모듈을 Assembling 하면서 프레임워크의 컴포넌트인 클래스, 이를테면 안드로이드의 “Activity” - 를 작성하다보면, 메소드들이 기능별로 그룹지어지고 이 그룹을 구분하기 위해 이른바 “섹션 주석”을 달곤 한다. 예를들면,

위의 클래스는 BaseActivity를 상속하여 변경시킬수 있는 “행동” 부분과 상속받는 자식 클래스들이 유용하게 사용가능한 공통 메소드등으로 메소드들이 그룹지어지고 그 그룹을 “주석”으로 나누고 있다.

각 메소드 그룹간에는 관계가 거의 없어서 클래스 응집도도 떨어지기 때문에, UI Common methods 같은것은 따로 클래스로 뽑아내는것이 바람직하고 클린코드에서도 조언하는 방향이다.

성장하는 도메인과 ‘Over-Engineering’

내가 고집하는(?) 많은 안티-클린코드가 사실은 이 두가지 때문에 발생하는 경우가 많다.

성장하는 도메인

응용단의 어플리케이션을 개발하다보면, 정책과 함께 프로그램이 성장하는 경우가 매우 많다. 따라서 요구사항이 변경되거나 혹은 확정이 안되어 있는 경우가 많고 따라서, 세부적인 구조를 예측하기 어려운 경우가 많다.

UI만 하더라도, 어떤것이 프로그램 전체의 “공통”요소인지 확정되는것은 도메인 모델에 많은 영향을 받는다.

만일 이러한 경우에 “미확정된 그룹”을 세부적인 클래스로 나눈다면

• 소프트웨어 구조 자체가 미확정된 클래스에 종속될 수 있고
• 중요하지 않은 구조 변경 때문에 많은 비용이 소모

되는 경우가 많을 것이다.

오버 엔지니어링

사실 위의 경우가 “오버 엔지니어링”의 전형이라 할 수 있겠다. 오버 엔지니어링은 구조가 복잡해지는 것도 문제이긴 하지만, 핵심 정책이 변경되었을때 변경에 대응하기가 어려운게 가장 큰 문제이다 - 만일 정책 변경에 대응을 잘 한다면 그건 오버 엔지니어링이 아니라 훌륭한 추상화일 것이다.

정책의 변경으로 많은 클래스들을 다시 짜는 경우를 많이 겪었기 때문에 나는 미확정 정책 - 혹은 명쾌하지 않은 정책 - 에 기반한 오버 엔지니어링을 경계하는 편이다.

이럴때는 “확정”된 정책을 기반으로 공통적인 부분들을 그룹핑하는, 섹션 주석 방법이 나쁘지 않다.

안티클린코드