Eternity's Chit-Chat

aeternum.egloos.com



유연한 설계를 위한 패턴과 원리 - 3.리팩토링을 통한 진보 6부 Supple Design

오만과 편견

리팩토링 시간이다. 개선할 부분이 있을까? 코드 중복도 없고, INTENTION-REVEALING INTERFACE 따라 메소드 명도 의도를 드러낼 있는 이름을 사용하고 있다. 다만 가지 마음에 걸리는 부분이 있다면 ChangeBooth에서 환율을 관리하기 위해 double 타입을 사용한다는 점이다. double 환율이 소수점 이하 자릿수를 가질 있다는 사실 외에는 어떤 것도 표현하지 못한다. USD KRW 변환하기 위한 환율과 KRW USD 변환하기 위한 환율간에는 역수 관계를 가진다는 사실 또한 명확하게 표현하지 못하고 있다.

 

비율이라는 개념을 명시적으로 표현하기 위해 Ratio 클래스를 추가하면 어떨까? 비율 개념을 나타낼 있도록 분모, 분자를 속성으로 포함하고 역수를 계산할 있는 오퍼레이션을 할당한다면 표현하고자 하는 도메인 개념을 명확하게 코드 내에 담을 있다. 하지만 새로운 개념을 추가할 때마다 설계에 복잡성 역시 추가하고 있다는 점에 유의해야 한다. 설계를 때마다 항상 느껴지는 불편함은 명확성과 복잡성 간의 트레이드오프가 그렇게 명확하지 않아 머릿속이 복잡해진다는 것이다. 설계에 Ratio 추가하는 것이 정말 명확성을 높이는 것일까? Ratio 추가함으로써 설계에 불필요한 복잡성을 늘리는 것은 아닐까? Ratio 추가함으로써 개발자에게 부가되는 개념적 무게가 증가되지는 않을까? double에서 Ratio로의 이동이 XP에서 중요하게 여기는 가치 하나인 단순성 장점을 훼손시키지는 않을까?

 

문제에 대한 개인적인 결론은 Ratio 추가하는 것이 코드의 명확성은 향상 시키지만 설계 자체의 복잡성을 늘리지는 않는다는 것이다. 비율은 환율을 이야기할 암시적으로 포함되는 개념이기 때문에 도메인 상의 개념적 무게를 증가시키지 않는다. 오히려 double이라는 제한적인 의미를 지닌 타입을 사용함으로써 문맥 내에 암시적으로밖에 표현할 없었던 통화 간의 관계를 명확하게 수면 위로 끌어 올리는 효과가 있다. 따라서 비율의 개념을 명확히 함으로써 설계를 이해하는데 필요한 복잡성의 수위를 낮출 있다. 

 

동일한 모듈 내에서조차도 의존성이 추가됨에 따라 설계를 해석하는 것이 매우 어려워진다. 이것은 정신적 부담(mental overload) 증가시키고, 개발자가 다룰 있는 설계의 복잡도를 제한한다. 명시적인 참조보다 암시적인 개념이 많은 부담을 지운다.

-Eric Evan, Domain-Driven Design

XP 단순함에 대해 많은 사람들이 오해하고 있는 점이 있다. XP에서는 가능한 해결 방법 가장 단순한 방법을 선호한다. 그러나 그것이 반드시 전체 클래스의 수가 적음을 의미하는 것은 아니다. 대부분의 사람들은 설계에 포함된 클래스의 수가 많으면 복잡한 설계라고 생각한다. XP 선구자인 Kent Beck 적은 수의 크기가 클래스들로 구성된 시스템보다는, 크기는 작지만 많은 수의 클래스(Lots of little pieces) 구성된 시스템을 선호한다. 일반적으로 소수의 크기가 클래스들로 구성된 시스템의 순환 복잡도(Cyclomatic Complexity) 상대적으로 값을 가지는 경향이 있다. 일반적으로 순환 복잡도의 값이 크면 클수록 코드가 복잡해지고 이해하기 어려워 지며 버그가 발생할 확률이 높아진다. 반면 갯수는 많더라도 크기가 작은 클래스들로 구성된 시스템의 순환 복잡도 값은 작으며, 따라서 코드를 이해하기가 용이해지고 버그의 역시 적어지게 된다.

XP
에서의 단순한 설계는 불필요한 인프라스트럭처에 대한 의존성을 너무 일찍 도입하지 않는 것과 예상에 의한 불필요한 기능을 미리 추가하지 않는 것을 의미한다. XP 단순함을 오해하는 사람들은 XP 컨텍스트와 무관하게 무조건적인 단순함을 강요한다고 생각한다. XP 단순함을 성취하기 위해 코드를 읽은 독자에 대한 설계의 적합성, 정보전달력, 리팩토링 여부, 구성 요소 수의 최소화라는 4가지 요인 적절한 균형을 유지해야 한다고 말한다. 따라서 컨텍스트와 프로젝트 상황에 따라 단순함의 수위가 조절되어야 함을 있다. 4가지 요소 모두 코드를 읽는 사람들을 위한 배려라는 점에 주목하자. 단순한 코드는 의미가 명확환 코드를 말한다.