2장

01. 설계와 아키텍쳐란/README.md

@@ -20,7 +20,7 @@
 거의 2600년 전에 이솝은 토끼와 거북이 우화를 지었다. 이 우화의 교훈 ->
  - 느려도 꾸준하면 이긴다.
  - 발 빠른자가 경주에 이기는 것도 아니며, 힘센 자가 싸움에서 이기는 것도 아니다.
- - 급할수록 돌아가라
+ - 급할수록 돌아가라.  
 -> 
  - 코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야! -> 정리 안한다.
  - 지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다 -> 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.

02. 두 가지 가치에 대한 이야기/README.md

@@ -0,0 +1,38 @@
+# 2. 두 가지 가치에 대한 이야기
+모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위(behavior)와 구조(structure)가 바로 그것이다. 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.
+
+## 행위
+소프트웨어의 첫 번째 가치는 바로 행위다. 프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다. 이를 위해 프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화 할 수 있도록 돕는다. 그리고 이해관계자의 기계가 이런 요구사항을 만족하도록 코드를 작성한다.
+> 한마디로 요구사항대로 잘 돌아가는가.  
+많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다. 이들은 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다.
+
+## 아키텍쳐
+소프트웨어는 부드러움을 지니도록 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다. 만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면, 우리는 소프트웨어가 아니라 하드웨어라 불렀을 것이다.  
+소프트웨어는 반드시 부드러워야한다. 다시말해 **변경하기 쉬워야한다.**  
+소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다.  
+새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.  
+문제는 당연히 시스템의 아키텍쳐다. 아키텍쳐가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는게 더 힘들어진다.  
+따라서 **아키텍쳐는 형태에 독립적이어야 하고, 그록수록 더 실용적이다.**
+
+## 더 높은 가치
+기능과 아키텍처 둘중 어느것의 가치가 더 높은가?  
+업무 관리자에게 묻는다면 소프트웨어 시스템이 동작하는 것이 더 중요하다고 대다수가 대답할 것이다. 하지만 이는 잘못된 태도이다.  
+ - 완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 된다. 따라서 이러한 프로그램은 거의 쓸모가 없다.
+ - 동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한채로 남는다.
+
+## 아이젠하워 매트릭스
+### 내겐 두 가지 유형의 문제가 있습니다. 하나는 긴급하며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.
+### 우선순위
+ 1. 긴급하고 중요한
+ 2. 긴급하지는 않지만 중요한
+ 3. 긴급하지만 중요하지 않은
+ 4. 긴급하지도 중요하지도 않은
+
+아키텍쳐, 즉 중요한 일은 이 항목의 가장 높은 두 순위를 차지하는 반면, 행위는 첫 번쨰와 세 번째에 위치한다는 점을 주목하자.  
+업무 관리자와 개발자가 흔하게 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일이다. 다시 말해 긴급하지만 중요하지도 않은 기능과 진짜로 긴급하면서 중요한 기능을 구분하지 못한다. 이러한 실패로 인해 시스템에서 중요도가 높은 아키텍쳐를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.  
+업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하기 때문에 개발자는 딜레마에 빠진다. **소프트웨어 개발자를 고용하는 이유는 바로 이 딜레마를 해결하기 위해서다.**  
+
+## 아키텍처를 위해 투쟁하라
+이러한 책임을 다하려면 싸움판에 뛰어들어야 하며, 더 정확히는 '투쟁'해야 한다.  
+이러한 도전은 당신이 소프트웨어 아키텍트라면 두 배로 중요해진다. 아키텍트는 시스템이 제공하는 특성이나 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.  
+하나만 기억하자. 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.