지표란 직접 경험을 하지 않아도 현재의 상황을 알수 있는 도구를 말합니다. 옛날 제주도에서는 식수가 귀해 빗물을 식수로 사용을 했습니다.  빗물의 오염도를 파악하기 위한 지표로, 개구리 (숫놈끼리만 넣거나, 암놈끼리만 넣거나)들을 넣었다고 합니다.

개구리 들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며, 또한 개구리의 생존 여부로 물 오염도를 파악을 할수 있기 때문입니다.

일전에 소프트웨어 품질을 판단하는 지표로,  1000 피트의 뷰 라는 글을 소개해 드렸습니다.    너무 상세하지도 않고, 너무 추상화되어 있지도 않은 그 사이의 뷰를 1000 피트의 뷰라고 불렀습니다.

이러한 지표중 하나로, 예전 저의 포스트에서  Dependency Structure Matrix (DSM) 을 소개해 드렸습니다.

이번 포스트는 이러한 연장선상으로 Clean Code로 유명하신 Robert C. Martin (줄여서 Uncle. Bob)님이  만드신 Instability/Abstractness Graph 하나를 설명해 드리고자 합니다. (이 그래프에 대해 국내에 명확하게 소개된 자료가 없어서,  꼭 여러분에게 공유를 해드릴려고 합니다. )

이 포스트를 읽기 이전에  Bob 삼촌이 발표하신 패키지 구조의 원칙들(Principles of Package Architecture) 을 읽어보시거나, 또는 저의 이전 포스트인 Dependency를 관리하는 방안 을 읽어보시길 바랍니다.

 Uncle Bob의 지표는  Instability와 Abstractness 두 개에 대해 이해를 하셔야 합니다.  물론 여기에 추가적인 지표를 더한 변종(Variant) 들도 있지만, 이 두 가지 개념을 확실히 이해하실 필요가 있습니다.

Instability

패키지의 변화 여부를 측정하는 지표입니다.  Stability를 안정성 보다는 “부동, 고정” 이라는 의미로 해석해서, Instability 변경할 수 있는 여력 여부로 이해 하시면 될듯 합니다.

그림 2. Instability – Afferent Coupling과 Efferent Coupling

그림 2에 Ca, Ce가 있는데 일단 Ca (Afferent Coupling – Outgoing Dependencies) 만 있다고 생각하시고 그림을 봐주세요.

여러분이 만든 Package (Code Element)가  Ca(Afferent Coupling)이 매우 많다는 것은, 여러분의 Package를 여기 저기서 재 사용하고 있다는 것을 말합니다.  다시 말하자면 다른 Package나 모듈에서 많이 사용하고 있으므로, 쉽게 변경할 수 없다는 것입니다. ( 즉  Core나 Framework와 같은 Infra성이 강한 Package일 가망성이 높다고 해석할 수 있습니다. )

반대로 여러분의 Package가 Ce (Efferent Coupling – Ingoing Dependencies)만 있다고 생각해 봅시다.  즉, Ca는 없다고 가정하지요.  이 Package를 사용하는 다른 Code Element는 없으며, 여기저기 다른 Code Element를  사용만 해왔다는 것을 의미합니다. 즉  최상위 Application Layer를 의미하며, 쉽게 변경해도 다른 Package나 모듈에게 영향을 미치지 않는다고 해석할 수 있습니다.

Bob 삼촌은  이 두 가지 개념을 통해 다음과 같은 Instability 수식을 만들어 내었습니다.

이 수식의 의미는 Instability가  0에 가까울 수록 움직일 여력이 없다는 것을 의미합니다.  Ca가 많다는 것이지요. 이에 반해 1에 가까울 수록 참조하고 있는 Code Element 비율이 적어서, 해당 Code Element를 변경을 해도 Change Propagation이 낮음을 의미합니다.

Abstractness 

Abstractness는 얼마나 Interface , Abstract Class들이 Package나, Code Element에 포함되어 있냐를 의미합니다.

Abstractness가 0에 가까우면 Concrete Class들의 비율이 높다는 것을 의미하며, 1에 가까우면 Abstract Class나 Interface의 비율이 높다는 것을 의미합니다.

실례로 보는 Instability, Abstractness

Static Analysis 툴 (STAN, xDepend)을 사용하면 Bob 삼촌의 그래프를 보실 수 있습니다.  저는 MIT에서 만든 Android Sensing Framework인 funf를 분석해 보았습니다.

그림 3. funf 분석

위 Graph에서, 노란색은 edu.mit.media.funf 는 Instability가 낮으므로 다른 Package 여기 저기서 참조하고 있음을 알수 있다. 그리고 Abstractness도 낮다는 것은 Interface나 Abstract Class가 적게 내포되어 있음을 의미합니다

다시 말하자면, edu.mit.media.funf는   Infra, Framework성 Package이지만, 안전장치 (Interface, Abstractness)가 없기 때문에 edu.mit.media.funf가 변경되면 다른 Package 여기저기에 영향을 미칠수 있습니다

그렇기 때문에 안전 장치들(인터페이스, 레이어, Parameter Object)를 사용해, 변화의 전파를 흡수할수 있게 만들어야 합니다.

Main Sequence

그림 1의 Main Sequence가 동일하게 그림 3에서 보입니다. 이것은 균형을 의미합니다.

인프라성 Code Element 는 인터페이스와 Abstract Class가 있어야 함을 의미합니다. 그리고 최상위 어플리케이션 로직단은 다른 Code Element에서 참조를 하지 않기 때문에, 굳이 Interface가 없어도 된다는 것입니다.  모든 클래스를 Interface 를 통해 호출하는 것은  Over Engineering이기 때문에,  Infra/Framework성 Package에 집중적으로 안전 장치를 걸자는 것을 의미합니다.

결국 Main Sequence 에 멀어지먼, 문제가 있음을 의미하며 여러 툴에서는 노란색 또는 빨간색으로 경고를 보여줍니다.

맺으며.

이러한 품질 지표 하나로는 모든 소프트웨어의 품질을 정확히 측정하기 힘듭니다.  하지만 이러한 지표들이 한,두개씩 모여  프로젝트의 건강함을 파악할 수 있는 좋은 도구가 됩니다. 그렇다고 너무나 이러한 툴을 신뢰하면 개발자는 이러한 지표에 노출되지 않도록, 설정파일이나 여기저기에 문제를 숨기게 됩니다.  오히려 문제를 덮어버려서 어디에 문제가 어디 있는지 모르는 상황이 발생하게 되지요.

Kent Beck이 한 명언이 생각나네요  “수술은 성공했다. 하지만 환자는 죽었다”..  결국 이러한 지표를 보는 것과 동시에 문제를 해결할 수 있는 설계 전문가가 더욱 필요합니다.

조만간 Stan4J라는 툴을 통해 추가적인 여러 지표들을 소개를 약속하며 맺겠습니다.