Add 구글 엔지니어는 이렇게 일한다 1장 key summary

Author: mokhs00

to be better engineer/구글 엔지니어는 이렇게 일한다.md

@@ -7,6 +7,7 @@
 - [개요](#개요)
   - [소프트웨어 엔지니어링이란?](#소프트웨어-엔지니어링이란)
   - [하이럼의 법칙 - Hyrum's Law(암시적 의존성 법칙)](#하이럼의-법칙---hyrums-law암시적-의존성-법칙)
+  - [1장 key summary](#1장-key-summary)
 
 ## 소프트웨어 엔지니어링이란?
 
@@ -28,3 +29,25 @@
 - API 소유자는 인터페이스를 명확하게 설명놓으면 어느 정도의 유연성과 자유를 얻을 수 있다. 하지만 현실에서는 API 사용자가 명세에는 없는 기능을 찾아 활용하기도 하며(이를 암시적 의존성이라 한다) 그 기능이 유용해 널리 쓰이면 추후 해당 API의 변경은 어려워진다. 즉 하위 호환성을 지키면서 해당 API를 변경해야한다는 말이다.
 - 따라서 변경이 얼마나 유용한지 분석할 때 이런 점도 고려해야한다.
 - 이런 관점에서 하이럼의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 공표한 계약(명세)이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없는 현실을 표현하는 말이기도 하다.
+
+## 1장 key summary
+
+- **차원(고려해야하는 주제의 큰 축)의 개수라는 측면에서 `소프트웨어 엔지니어링`과 `프로그래밍`은 다르다**
+  - 프로그래밍은 코드 생산에 관한 것이고 소프트웨어 엔지니어링은 좀 더 확장하여 소프트웨어의 수명이 다할 때까지 코드를 유지보수하는 것까지 고려한다.
+- **단명하는 코드와 장수하는 코드의 수명은 적어도 10만 배는 될 것이다. 동일한 모범 사례를 수명 축의 양 끝단에 위치하는 두 프로젝트에 똑같이 적용하려는 것은 너무 안일한 생각이다.**
+  - 소프트웨어 엔지니어링은 흐르는 시간 위에서 순간순간의 결정에 따라 유동적으로 변경되어아 한다.
+- **코드의 기대 수명동안 의존성, 기술, 제품 요구사항 변경에 대응할 역량이 갖춰져야 지속 가능한 소프트웨어이다. 여러 이유로 변경을 받아들이지 않기로 선택하더라도 변경할 수 있는 역량 자체는 필요하다.**
+  - 기술부채를 만들더라도 이를 치울 수 있는 역량 정도는 준비되어 있어야한다.
+- **하이럼의 법칙**
+  - API 사용자가 충분히 많다면 API 명세서에 적어놓은 내용은 중요하지 않게 된다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 된다.
+  - 이는 사용자가 명세에 없는 기능을 발견하여(의도하지 않았지만 눈에 보이는 행위에 포함됨) 활용하기도 한다. 즉 변경이 얼마나 유용한지 분석할 때 이런 점도 고려해야한다.
+- **조직에서 반복적으로 수행하는 모든 작업은 필요 인력 측면에서 확장 가능(선형 증가 혹은 그 이하)해야한다.**
+  - 정책은 개발 프로세스를 확장 가능하게 해주는 멋진 도구이다.
+- **개발 프로세스를 포함한 소프트웨어 개발 업무의 많은 것의 효율은 눈치 채기 어렵게 천천히 나빠지는 경향이 있다.**
+  - 끓는 물의 온도를 인지하지 못하고 죽어가는 `끓는 물 속의 개구리`가 되지 않도록 주의해야한다.
+- **전문성은 규모의 경제와 결합될 때, 즉 조직이 커질수록 효과가 커진다.**
+- **`내가 시켰으니까`는 어떤 일을 수행하는 이유로는 아주 끔직하다.**
+- **의사결정을 데이터 주도로 하겠다는 생각은 좋은 출발이다. 하지만 현실에서의 의사결정 대부분은 데이터, 가정, 선례, 논의를 종합하여 이루어진다.**
+  - 고려 요소의 대부분에 객관적인 데이터가 주어지면 가장 좋겠지만, 순전히 데이터만으로 결정되는 경우는 드물다. 즉 데이터는 절대적이지만 결정 진행에 방해가 되어서는 안된다.
+- **데이터 주도 방식은 시간이 흘러 데이터가 변하면(혹은 가정이 무너지면) 프로젝트의 방향이 바뀔 수 있음을 의미한다.**
+  - 잘못을 인정하고 계획을 수정하는 것은 당연한 일이다.