01 Introduction

우리는 어떻게 해야 미래에 어떤 변경을 하게될지 지금 알아내 중요한 결정을 구체적으로 내릴 수 있을까?

어떻게 하면 앞으로 개발에 들어갈 노력과 비용을 줄일 수 있을까?

 

아키텍처는 종착지가 아니라 여정에 더 가까우며,

고정된 산출물이 아니라 계속된 탐구 과정에 더 가까움을 이해해야 좋은 아키텍처가 만들어진다.

---

근본적으로 다른 다양한 시스템을 구축하고 경험한 작가가 깨달은 것. --> 아키텍처 규칙은 동일하다.

 

현재의 소프트웨어는 과거와 동일한 것들로 구성된다. 여전히 if문, 할당문, while 루프로 구성된다.

1950년대와 마찬가지로 코드는 여전히 sequence, selection, iteration의 집합체일 뿐.

언어는 조금 발전했고 도구는 좋아졌지만 프로그래밍을 이루는 기본 구성요소는 바뀌지않았다.

 

이 책은 세월이 흘러도 변치 않는 그 규칙에 관한 것이다.

---

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

 

아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬때 흔히 사용되고 

설계는 저수준의 구조, 결정사항 등을 의미할 때가 많지만,

실제로 구분은 무의미하고 둘 사이는 아무런 차이가 없다.

 

좋은 소프트웨어 설계의 목표는??

--> 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 것.

 

- 잘못된 사례연구

엔지니어 직원의 수가 늘어난다고 해서 회사의 생산성이 좋아지지 않는 경우.

 

코드 한 라인당 비용

코드 한 라인당 증가하는 그래프의 라인을 보면 무언가 잘못됬다고 볼 수 있다.

 

- 엉망진창이 되어가는 신호

 

생산성/출시

이 비용곡선은 개발자의 관점에서 보는 것이다.

초반의 생산성은 100% 로 시작하였으나 나중에는 0에 수렴한다.

개발자의 노력은 기능개발보다 엉망이된 상황에 대처하는데 소모되기 시작한다.

 

- 경영자의 시각

 

출시별 월 인건비

경영자는 월 인건비가 점점 늘어난다.

 

- 무엇이 잘못되었나

 

'시장 출시가 먼저' 라는 생각을 하는 경우, 급하게 코드를 엉망으로 작성해 일단 출시하고 나중에 정리하자고 생각하기 마련이고.

이 경우 엉망인 코드가 쌓이면 개발자의 생산성은 낮아지고 코드가 엉망이 되는 추세는 멈추지 않는다.

 

엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.

 

또한

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

 

- 결론

개발 조직이 할 수 있는 선택은

과신을 인지, 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것.

시스템 아키텍처가 지닌 속성을 알아야 한다.

 

---

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

모든 소프트웨어 시스템이 제공하는 두가지 가치 - 행위 behavior 와 구조 structure 

 

- 행위

소프트웨어의 첫번째 가치는 행위.

많은 개발자가 요구사항을 구형하고 버그를 수정하는 일이 자신의 직업이라고 믿지만. 틀렸다.

 

- 아키텍처

소프트웨어의 두번째 가치는 부드러움, 유연함 이다.

개발 비용의 증가를 결정짓는 주 요인은 변경사항의 범위와 형태의 차이에 있다.

아키텍처는 형태(시스템의 형태, 요구사항의 형태)에 독립적이어야 하고 그럴수록 더 실용적이다.

 

- 더 높은 가치

• 완벽히 동작하지만 수정이 불가능한 프로그램
  - 요구사항 변경에 동작하지 않고 거의 쓸모가 없게 됨.
• 동작하지 않지만 변경이 쉬운 프로그램
  - 프로그램이 돌아가게 하고 변경사항이 발생해도 동작할 수 있도록 유지보수 가능.

변경에 드느 비용이 변경으로 창출되는 수익을 초과하면 수정이 현실적으로 불가능.

하지만

업무관리자의 변경요청을 '변경비용이 너무커서 현실적으로 적용하기 힘들다'고 하면

실제 변경이 불가능하게 방치했다며 비난이 돌아올것이다. ㅜㅜ

 

- 아이젠하워 매트릭스

중요성과 긴급서에 관한 매트릭스

아이젠하워 매트릭스

'행위' 는 긴급하지만 높은 중요도

'아키텍처' 는 중요하지만 긴급성을 필요하지 않음.

 

우선순위

1. 긴급 중요

2. 긴급하지 않고 중요

3. 긴급 중요하지 않음.

4. 긴급하지 않고 중요하지 않음.

 

업무관리자와 개발자가 흔히 저지르는 실수

-> 3번째의 긴급하지만 중요하지 않은 항목을 우선으로 하는 것.

중요도가 높은 아키텍처를 무시한 때 중요도가 떨어지는 기능을 선택하는 것.

 

기능의 긴급성이 아니 아키텍처의 중요성을 설득해야 한다.

 

- 아키텍처를 위해 투쟁하라

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 

일부 또는 전체 시스템에 변경을 가하는일이 현실적으로 불가능해 진다.

이런 상황이 발생하도록 용납하는 것은 

결국 개발팀이 옳다고 믿는 가치를 위해 충분히 투쟁하지 않은것이다.