[이상조] 챕터 2: 실용주의 접근법

2장/이상조.md

@@ -0,0 +1,70 @@
+## 좋은 설계의 핵심
+사용하는 사람에 적응하여 변화하기 쉬운 설계가 좋은 설계.  
+Easier to Change. ETC  
+즉, 느슨한 결합, 관심사의 분리
+
+## 중복의 해악
+Don’t Repeat Yourself. DRY  
+같은 개념을 두 군데서 표현하지 말라.  
+하나를 바꿀 때 다른 하나를 또 바꿔야 한다면 중복임을 의심하자.  
+
+코드의 중복과 지식의 중복은 다르다.  
+
+주석은 곧 코드의 다른 표현이다.  
+
+외부와 연결할 때 중복이 발생한다.  
+외부의 지식을 우리의 코드도 알아야 하기 때문. 한 쪽을 바꾸면 다른 한 쪽도 바뀌어야 한다.  
+
+최근 회사에서 비슷한 논의가 있었다.  
+protobuf라는 데이터 형식으로 통신하는데, 코드젠 비슷한 것이 있어 활용중이다.  
+protobuf에서 생성해준 모델을 클라이언트의 타입으로 활용하는 것이 바람직할까?  
+서버와 통신하기 위한 타입과 클라이언트에서 사용하기 위한 타입을 별도로 정의하고 둘을 연결해주는 어댑터를 두는 것이 결합을 느슨하게 만들 수 있을 것 같다.(ETC)  
+이러면 한 쪽이 바뀌어도 다른 한 쪽은 안전하다.(대신 어댑터를 고쳐야 한다.)  
+다만, 어쩌피 protobuf가 생성한 타입과 똑같은 타입을 클라이언트에서 사용해야하는데 이원화하는 것이 맞을까?(DRY)  
+
+팀원이 여러 명이라면 동일한 일을 하는 코드를 짜게 되는 경우가 생긴다.  
+이는 리뷰나 소통으로 해결한다.  
+근데 아무리 리뷰나 소통해도 이걸 100% 막을 수는 없을 것 같다.  
+
+재사용하기 쉽게 만들어라.
+
+## 직교성
+하나가 바뀌어도 나머지에 영향을 주지 않을때 직교한다고 표현함.  
+즉, 결합도를 낮춘다.  
+시스템이 느슨하게 결합되어 있다면 재조합하고 개량하기 쉽다.  
+테스트하기 쉽다. 즉, 테스트하기 쉬워서 더 많이 하게 된다.  
+
+코드의 결합도를 줄여라.  
+전역 데이터를 피하라.  
+유사한 함수를 피하라.  
+
+## 가역성
+결정은 언제나 바뀔 수 있다.  
+따라서 바꾸기 쉽게 만들어라.  
+컴포넌트를 쪼개고, 외부 API를 추상화 계층 뒤로 숨겨라.  
+
+## 예광탄
+시스템을 만들어내기 위해서 가장 핵심이 되는 요구 사항부터 빠르게 작업하라.  
+그리고 반복적으로 시도하며 불확실성을 줄여라.  
+단, 대충 하지 마라. 그 코드에 살을 붙여서 점점 더 정교하게 만들어야 한다. 프로토타이핑과의 차이가 이것이다.  
+
+## 프로토타입과 포스트잇
+아이디어를 실험하기 위해 가성비 좋게 이용하는 것이 프로토타입.  
+증명되지 않은 모든 것이 프로토타이핑의 대상이다.  
+프로토타입은 원초적 형태라는 의미이다. 즉, 안정성, 완전성과 같은 가치보다는 시스템의 핵심만 빠르게 체크하는 것이 목적이다.  
+
+## 도메인 언어
+이건 무슨 말인지 잘 모르겠다…
+
+## 추정
+적절한 추정치를 제공하는 것은 소통에 효과적이다.  
+추정치를 계산하는 것은 레퍼런스에 의존하는 것이 효과적이다.  
+
+시스템의 모델을 만들어라  
+이건 poc 하라는건가…?
+
+프로젝트 일정 추정하기
+
+여러 조건에 따라 추정치가 달라진다. 이를 범위로 나타내라.
+
+요구 사항 분석 > 구현 > 검증의 사이클을 돌려라. 몇 번의 사이클이 필요한지는 사이클이 반복되면서 구체화할 수 있을 것이다.