영향도 있는 코드들은 물리적으로 군집을 만들어 응집도를 높이자

질문을 만납니다.

코드를 읽다가 변경해야 할 동작을 찾았더니 여러 곳에 흩어져 있는 코드를 함께 바꿔야 한다는 걸 알면 불편한 감정이 일어납니다. 그럴 때는 어떻게 해야 할까요? - p.49

몇가지 상황을 상상해봅니다.

• 비슷한 코드가 흩어져 있는 경우, 하나의 함수로 묶을 것 같습니다.
• 변경한 동작의 영향으로 함께 바꿔야하는 경우, 영향도가 단일 지점이 되도록 설계 개선을 해야하지 않을까요?
• 위 두 경우 수행할 시간이 없는 경우, 주석을 남깁니다.

켄트 벡은 변경할 요소들을 가까이 두라고 합니다. 가까이에 두기만 하면 나중에 까먹지 않을지 궁금합니다.

변경할 요소의 근처 코드나 파일들은 읽어보는 개발자의 습성을 활용하는 것일지 자답해봅니다.

그리고 다시 한 번 알아차린 것들이 있습니다.

• 결함도는 제거할 수록 좋다.
• 팀에 스트레스가 있는 상황이면 여유를 가지자.

...

응집은 결국 문맥이 존재해야 하는데..

응집도는 응집을 위한 문맥이 필요하다고 생각합니다.
그리고 문맥은 구성원들이 비즈니스를 공통되게 이해하고
큰 덩어리 내부에서 작은 경계를 함께 설정함으로서 견고해진다고 생각합니다.
(이것이 비록 시간의 흐름에 따라 바뀔지라도)

이런 경계가 뚜렷하지 않은 코드들의 응집도를 높이는 배치는 이것 저것 코드를 잡탕 진흙공으로 뭉치는 계기가 되는 것 같습니다.

모을 때는 다 관련 있는 것 같아서, 이렇게 하면 응집도가 높을 것 같아서 모으는데
나중에 알고보면 여러 문맥의 커플링 역할을 하는 경우들이 있는 것 같아요!

비즈니스 안의 문맥과 밖의 문맥

우리가 흔히 코드에서 비즈니스 외적으로 순수하게 값을 가공하거나 판단할 때 XXXUtil을 많이 쓰게 되는데, 이것 또한 하나의 문맥이라고 생각합니다.

저의 처음 댓글에서 언급했던 것들이 비즈니스 안의 문맥과 관련 되어 있다면, 이것은 비즈니스 밖의 문맥이 될 것 같아요.

대표적인 것이 StringUtils/CollectionUtils 같은 것들이 있다고 생각합니다.
인자로 전달된 값에 대한 문맥만 가지고 있지요

그런데 흔히 우리는 XXXXUtils에 특정 비즈니스 문맥이 담긴 코드들을 담는 경우들이 있는 것 같아요. 그래서 흔히 global 영역의 utils 패키지의 XXXUtils를 보면 정말 많은 비즈니스가 혼재 되어 보입니다.

이런 부분도 우리가 잘 통제해야 하는 것이라 생각해요

응집도를 다양한 컨텍스트에서 바라보기

응집도 라는 개념은 너무 익숙하지만 또 짧게 정의해보라면 입이 떨어지지 않습니다.

높은 응집도는 낮은 결합도와 함께할 때 높은 응집도라는 의미가 완전하게 표현되므로
다양한 컨텍스트에서 어떤 상황이 응집도가 높고 결합도가 낮다라고 표현될까 생각해보았습니다.

1. 코드/파일
   함수(코드)라면 어떤 기능을 수정할때 바로 붙어있는 라인이 수정되는 것
   파일이라면 어떤 기능을 수정할 때 같은 디렉토리 하위에 있는 파일들만 수정되는 것

2. 모듈
   특정 역할을 수행해주길 기대하는 모듈 하나만 임포트 하여도 충분한 것(해당 모듈을 사용하기 위해 다른 모듈들이 필요하지 않은 것)
   다른 모듈에 있어야할 기능이 불필요하게 포함되어 이용자를 혼란스럽지 않게 하는 것

3. 시스템
   해당 시스템은 명확히 어떤 목표와 비전을 가지고 있는지 설명할 수 있는 것
   진화, 릴리즈를 거듭할 때 다른 시스템의 진화와 릴리즈를 함께 필요로하지 않은 것 (다른 시스템에 동기적으로 의존적이지 않은 것)

이런저런 컨텍스트로 생각해보니, 응집도가 높고 결합도가 낮다는 것은

• 같은 이유로 함께 변경되는 것을 가까이에 모으고 불필요한 것은 떼어내는 것 (SRP가 떠오릅니다)
• 어떤 역할과 책임을 해당하는 것(클래스, 모듈, 프로그램, 시스템) 하나로 충분히 제공할 수 있으면서, 스스로 진화해나갈 때 다른 것(클래스, 모듈, 프로그램, 시스템)에게 의존적이지 않는 것

이렇게 정리가 되네요!

지금까지는 별 관심 없었던 응집도

소프트웨어 개발을 업으로 살아오며 높은 응집도와 낮은 결합도라는 말을 수도 없이 읽어 왔습니다.
하지만 스스로 정의할 수 없었고 자신있게 실천하고 있다고 말할 수 없었습니다.

그러던 와중에 @정승주 님이 공유해 주신 켄트 벡이 ByteByteGo와의 인터뷰 내용을 자세히 읽었습니다.

인터뷰 내용 중 켄트 벡이 TidyFirst? 책에서 꼭 기억했으면 하는 사항에 응집도와 결합도에 대한 이해가 있었습니다.

Paying attention to software design as a relationship skill, separating behavior changes from structure changes, making large changes in small, safe steps, and understanding coupling and cohesion.

켄트 벡에 이렇게 얘기하는데 더 이상 무시하며 망설일 수 없다는 생각과
진지하게 이 문제를 고민하고 코드로 실천해 보겠다는 다짐을 합니다.

응집도와 결합도의 출발은 품질 측정

저는 역사를 좋아합니다. 현재 존재하는 이유를 설명해 주기 때문이죠.
응집도와 결합도의 기원을 위키피디아를 찾아 보니
켄트 벡이 뉴턴의 법칙으로 은유했던 에드워드 요던과 래리 콘스타틴의 'Structured Design' 에 있다는 것을 알았습니다.(물론 TidyFirst? 추천 서문에서 래리는 기원이 자신들의 책이 아닌 1968년 메사추세츠주 케임브리지에서 열린 콘퍼런스 발표라고 말하고 있지만..)
그리고 처음에는 품질 측정을 위해 소개되었다는 것을 인지했습니다.

The software quality metrics of coupling and cohesion were invented by Larry Constantine in the late 1960s as part of a structured design, based on characteristics of “good” programming practices that reduced maintenance and modification costs. Structured design, including cohesion and coupling, were published in the article Stevens, Myers & Constantine (1974)[4] and the book Yourdon & Constantine (1979),[5] and the latter subsequently became standard terms. - https://en.wikipedia.org/wiki/Coupling_(computer_programming)

응집도와 결합도 모두 '변경'에 관한 것이다

코드를 읽다가 변경해야 할 동작을 찾았더니 ... 코드의 순서를 바꿔서 변경할 요소들을 가까이 두면 ...

소프트웨어에서 응집도와 결합도를 말할 때 '변경'을 빼놓으면 논의하면 공허해지는 느낌입니다.
왜냐하면 우리가 말하는 클린코드라는 것도 변경이 쉬운 코드를 의미한다고 생각하기 때문입니다.
변경이 쉽다는 측면에서 응집도가 높을수록 변경의 대상과 범위가 명확해지기 때문에 코드를 변경하기 쉬워집니다.

어떻게 실천할것인가?

높은 응집도, 낮은 결합도 정의를 찾아보면 매우 추상적이고 모호합니다. 그렇다는 것은 당장 실천하기가 어렵다는 것입니다.
켄트 벡은 책에서 매우 실용적이고 당장 실천 가능한 방법을 알려줍니다.

코드의 순서를 바꿔서 변경할 요소들을 가까이 두면 됩니다. ... 두 파일에 결합도가 있으면 같은 디렉토리에 넣습니다. ... 결합도가 있는 코드를 같은 코드 저장소에 넣은 후 변경하세요.

쉽게 일상에서 경험을 쌓을 수 있다는 측면에서 매우 실용적이라고 생각합니다.

반면 책 <오브젝트>의 저자는 '캡슐화'를 강조합니다.

캡슐화를 지키면 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아진다. 캡슐화를 위반하면 모듈 안의 응집도는 낮아지고 모듈 사이의 결합도는 높아진다. 따라서 응집도와 결합도를 고려하기 전에 캡슐화를 향상시키기 위해 노력하라. - <오브젝트> 112 쪽

Information hiding

UML을 만든 사람 중의 한명인 그래디 부치는 OOAD 에서 캡슐화는 정보를 숨기는 것으로 달성한다고 했습니다.

캡슐화는 대부분 정보 숨기기로 달성되며(데이터 숨기기에 그치지 않고), 개체의 핵심 속성을 기술하는데 도움이 되지 않는 모든 비밀을 숨기는 프로세스다.

Information hiding 이 떠오르는 지점입니다.
앞서 저는 응집도와 결합도에 큰 관심없이 개발을 해왔다고 고백한 적이 있습니다.
하지만 Information hiding은 실천하려 노력해 왔습니다.

Information hiding이 응집도와 결합도에 영향을 미친다는 것을 깨닫습니다.