01 소개

프로그램이 동장하도록 만드는 데 엄청산 수준의 지식과 기술이 필요하지는 않다. 하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 적정 수준의 지식과 기술을 겸비해야만 하며, 훈련과 헌신을 필요로 한다.

그렇지만 제대로 된 소프트웨어를 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다. 변경은 단순해지고 빠르게 반영할 수 있다. 결함을 적어지고 잦아든다. 최소한의 노력으로 기능과 유연성을 최대화할 수 있다.

---

1장. 설계와 아키텍처란?

설계(design) = 아키텍처(architecture)

저수준의 세부사항과 고수준의 구조는 모두 전체 소프트웨어의 구성요소

저수준과 고수준을 구분하는 경계는 없다. 고수준에서 저수준으로 향하는 의사결정의 연속성만 존재한다.

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

 

아키텍처에 대한 고민을 하지 않으면 제품이 커질수록 생산성을 떨어진다.

 

"코드는 나중에 정리하면 돼. 당장은 출시하는게 먼저야!"

→ 개발자는 결코 나중에 코드를 다시 정리하지 않는다. 시장의 압박은 절대로 수그러들지 않기 때문이다.

 

"지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다."

→ 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.  빨리가는 유일한 방법은 제대로 가는 것이다.

 

개발자는 처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답이라고 생각할지도 모른다.

→ 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다

---

2장. 두가지 가치에 대한 이야기

모든 소프트웨어 시스템은 이해관계자에게 두가지 서로 다른 가치를 제공한다.

행위(behavior)와 구조(structure)

한가지 가치에만 집중하면 결국 소프트웨어 시스템은 쓸모없게 된다.

 

행위

프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다. 그리고 이해관계자가 기계의 이러한 요구사항을 만족하도록 코드를 작성한다.

많은 프로그래머가 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신이 해야할 전부라고 생각하지만, 틀렸다.

 

아키텍처

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 변경하기 쉬워야한다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.

변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야하며 변경사항의 형태(shpae)와는 관련이 없어야한다.

아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는게 더 힘들어진다.

따라서 아키텍처의 형태는 독립적이어야하고, 그럴수록 더 실용적이다.

 

아이젠하워 매트릭스

긴급한 문제는 중요하지 않으며, 중요한 문제는 긴급하지 않다.

 

행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.

아키텍처는 중요하지만 즉각적인 긴급성을 필요로하진 않는다.

 

기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 책임져야 한다.

 

아키텍처를 위해 투쟁하라

개발자는 소프트웨어를 안전하게 보호해야할 책임이 있다. 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.