12. 복잡도 다루기

간결함은 가장 위대한 덕목이지만, 이를 달성하려면 고된 작업이 필요하며 또한 이해하려면 별도의 교육이 필요하다. 

상황을 더 어렵게 만드는 것은 "복잡하면 더 잘 팔린다" 라는 사실이다. 

에츠허르 데이크스트라

복잡한 무언가를 작성하는 일은 너무나 쉽게 일어진다. 집중하지 않고 충분히 계획을 세우지 않으면 일어날 수 있다.

복잡한 것을 간단한 문제로 간주하고 작업할 때도 일어날 수 있다.

소프트웨어의 복잡도는 크게 세 가지 원인에서 기인한다.

• - 블럽
• - 라인
• - 사람

1. 블럽( Binary Large OBject )

블럽의 크기와 수가 복잡도를 결정한다. 일부 소프트웨어의 복잡도는 블럽의 크기에 따른 자연스러운 결과라 할 수있다.

프로젝트가 크면 클 수록 더 많은 블럽을 필요로 한다. 그럴수록 이해하기는 더 어려워지며, 작업하기도 더 힘들어 진다.

그래도 이는 어디까지나 필연적인 복잡도라고 할 수 있다.

필연적인 복잡도는 관리해야 한다. 또한 불필요한 프로그래머들을 제대로 가르치거나 잘라버려야한다. ( 복잡도를 키우기만 한다면 문제가 심각하다 )

단지 크기 그 자체가 우리의 적이 아니라는 사실을 깨닫는 것이 중요하다. 만약 세 가지 일을 해야하는 소프트웨어 시스템을 다루고 있다면, 각각의 일을 하는 코드를 입력해야 한다.여기서 복잡도를 줄이기 위해 몇몇 코드를 제거한다면, 또 다른 문제에 봉착할 것이다.

실제로 크기 자체는 큰 문제가 되지 않는다. 요구사항을 충족시킬 만큼 큰 코드가 필요하다. 

이러한 코드를 어떻게 구성하는가, 그 크기를 어떻게 배분할지가 가장 중요하다.

더 좋은 구조 즉 이해하고 유지 보수하기에 더 간단한 구조로 만들기 위해서는, 각각의 부분을 모듈로 간주하고 각 모듈의 세부적인 부분으로 나누어야 한다.

세부적인 부분들로는 패키지, 컴포넌트, 클래스 가 있다. 

수많은 작은 컴포넌트들이 더 큰 전체에 연결되어 있듯이 계층으로 나누고 추상화해 간다면 좀더 이해하기 쉽고 수정하기도 쉬운 구조를 만들 수 있을 것이다.

누구나 작고 수많은 일을 잘 해내는 즉 더 응집도가 높은 클래스를 선호한다. 되도록이면 하나의 일만 처리하는 것이 중요하다. 이를 위해서는 겉보기에만 단순해 보이는 것이 아니라 실제로 간결해지도록 설계해야하며, 각 블럽이 정확한 역할과 책임을 확실히 갖도록 해야한다.

2. 라인 

복잡도는 각 블럽 안에서 홀로 커간 것이 아니라, 프로그래머가 블럽을 서로 연결하는 과정에서 커진 것이다.

일반적으로 라인이 적을수록 소프트웨어 디자인은 간결해진다. 블럽 사이의 연결이 많아질수록 설계는 더 경직되며, 시스템상에서 작업 시 이해햐아할 연동이 더 많아진다.

프로그래머는 객체들 사이를 연결하면서 실제 소프트웨어 시스템을 만들어간다. 더 많은 블럽을 추가하고 그 블럽들 사이에 연결을 추가하면서, 더욱 복잡한 시스템을 만드는 것이다.

연결들을 배치할 때 객체들 간의 순환 연결 관계로 인해 복잡도가 증가하기도 한다. 순환적인 의존 관계는 일반적으로 고려해야 할 가장 복잡한 관계이다. 객체들이 상호 종속적 관계일 경우, 그들의 구조는 융통성이 없고 쉽게 변하지 않으며 작업하기도 어렵다.

3. 사람

소프트웨어 복잡도는 블럽과 라인의 구조에 따라 달라진다. 하지만 블럽과 라인은 스스로를 창조하지 않는다는 점에 주의해야 한다. 이들 구조 자체가 본질적으로 비난받을 만한 것은 아니다. 책임은 코드를 작성하는 프로그래머에게 있다.

프로그래머에게는 믿기 힘든 복잡성을 불러일으킬 수 있는 힘이 있고, 반대로 지저분한 문제들을 보기 좋고 간결한 형태로 바꿀 수도 있는 힘이 있다.

복잡도가 높아지는 일은 대개 어쩌다 보니 일어난 일일뿐, 누군가가 고의적으로 일으키는 경우는 드물다. 복잡도를 줄일 수 있는 유일한 방법은 소프트웨어에 책임감을 가지고, 업무 압박으로 인해 적절하지 않은 구조로 코드를 밀어넣는 상황을 피하고자 노력하는 것이다.