1. 설계와 아키텍처란?

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수 하는 데 투입되는 인력을 최소화 하는 데 있다.

새로운 기능을 출시할 때마다 비용이 증가한다면, 나쁜 설계다. 좋은 설계란 단순 명료하다.

개발자 입장에서 보면 이러한 도표는 절망감을 안겨준다. 모두 열심히 일하기 때문이다. 전력을 다하지 않는 개발자는 없다.

경영자는 어떠한가

초기에는 매월 수십만 달러의 비용으로 많은 기능을 탑재할 수 있었지만, 마지막 출시에서는 2찬만 달러를 들이고도 얻은게 없다.

저자는 말한다.

개발자도 항상 경주를 한다. 개발자가 항상 속는 거짓말은 "지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로만 생산성이 낮아진다."는 견해다.

명심하자

빨리가는 유일한 방법은 제대로 가는 것이다.

모든 소프트웨어는 이해관계자에게 서로 다른 두가지 가치를 제공한다. 그것은 행위와 구조다.

프로그래머를 고용하는 이유는 기계가 수익을 창출하거나 비용을 절약하기 위해서다.

기계가 요구사항을 위반하면, 프로그래머는 디버거를 통해 고친다.

많은 프로그래머는 이러한 활동이 전부라고 여긴다. 이들은 요구 사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업의 전부라고 믿는다. 슬프지만 그들은 틀렸다.

소프트웨어는 그 이름따라 부드러움을 지니도록 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.

이해관계자가 기능 변경을 원하면 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는데 드는 어려움은 변경되는 범위에 비례해야 하며, 변경사항의 형태와는 관련 없어야 한다.

두 가치에 대해

둘 중 어느 가치가 높은가?

저자는 단순 논리로 양 극단 사례를 검토하는 방식으로 주장한다.

완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 된다. 따라서 이런 프로그램은 쓸모 없다.
동작은 하지 않지만 변경이 쉬운 프로그램을 준다면, 나는 프로그램이 돌아가도록 만들 수 있고, 변경이 발생해도 동작하도록 보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한 채로 남는다.

저자는 책임을 위해 투쟁하라 말한다. 아키텍처는 곧 개발팀의 몫이기 때문이다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해 진다.