•
오래된 애플리케이션은 무질서하게 확장되기 쉽다.
◦
처음에는 잘 설계된 구조를 가지고 있다가 시간이 지남에 따라 일정 압박에 시달리며 무분별하게 증축되고는 한다.
•
이렇게 무질서한 구조는 우리에게 시스템의 설계를 변경하는 것과 전면적으로 재작성하는 것 중 하나의 선택을 강요하곤 한다.
•
전통적으로 많은 조직들이 이런 문제를 풀기 위해 아키텍트라는 역할을 두고 구조를 관리했다. 그러나 이는 소통 오류가 발생할 지점을 하나 더 늘릴 위험이 있다.
•
개발자들은 스스로 자신 시스템의 아키텍처를 이해하고 있어야 한다.
•
이를 방해하는 요인들은 다음이 있다.
◦
시스템이 너무 복잡하여 전체 그림을 이해하는데 비용이 많이 든다.
◦
시스템이 너무 복잡하여 전체 그림이 없다.
◦
전체 그림이 없다 보니 긴급한 상황이 자주 발생하고 이를 막고자 간이 처방만 하게 된다.
⇒ 문제는 근본적으로 풀어내어야 한다.
시스템의 스토리텔링
•
이 기법은 최소한 두 사람이 필요하다.
•
먼저 한 사람이 다른 사람에게 다음과 같이 질문한다. “시스템의 아키텍처는 어떤가요?”
•
그러면 상대방은 최대 2~3개의 개념만을 가지고 시스템의 아키텍처를 설명한다.
◦
이때, 설명을 듣는 당사자가 전혀 모르고 있음을 가정하고 쉽게 설명해야 한다.
•
이런 과정을 시스템의 핵심 설계와 관련 있는 중요 사항이 모두 나올 때까지 반복한다.
⇒ 시스템을 추상화하여 간략한 약도를 그릴 수 있게끔하라는 의미의 내용 같다.
네이키드 CRC
•
CRC는 클래스, 책임, 협력의 첫 글자를 따서 만든 용어다.
•
카드에 클래스의 이름, 책임, 협업 클래스를 기재한 후, 이들 간의 의존성을 연결하는 방법이다.
•
네이키드 CRC는 조금 더 발전된 형태로 카드를 인스턴스라고 가정한다.
•
그리고 각 인스턴스들이 어떻게 상호작용하는지 손으로 설명한다.
대화 음미
•
대화 내용이나 회의 내용 등, 명세한 내용과 코드가 다르다면, 그 이유를 알아내야 한다.
•
개발 팀이 같은 언어를 공유하고 있지 않거나 서로 다른 목표를 바라보고 있을 가능성이 있다.
