[최서희] 11장, 12장, 13장: 시스템 외 2장

11장/최서희.md

@@ -0,0 +1,25 @@
+# 11장. 시스템
+
+## 인상 깊은 내용 - 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법
+
+* **테스트 주도 시스템 아키택처 구축**
+
+   코드 수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다. 그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수도 있다.
+   물리적 구조는 일단 짓기 시작하면 극적인 변경이 불가능한 탓이다. 소프트웨어 역시 나름대로 형체가 있지만, 소프트웨어 구조가 관점을 효과적으로 분리함다면, 극적인 변화가 경제적으로 가능하다.
+   다시 말해, '아주 단순하면서도' 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다는 말이다.
+
+* **의사 결정을 최적화하라**
+  모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.
+  성급한 결정은 불충분한 지식으로 내린 결정이다. 너무 일찍 결정하면 고객 피드백을 더 모으고, 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다.
+
+* **시스템을 설게하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자**
+
+---
+
+## 느낀점
+
+과거 한 프로젝트에서 기술 스택을 선택하면서 성급한 결정을 내린 적이 있다. 당시에는 장점만을 빠르게 분석한 뒤, 전체적인 리스크나 다른 대안들을 충분히 고려하지 않은 채 선택을 확정지었다. 그 결과, 해당 기술이 프로젝트에 적합하지 않다는 사실을 뒤늦게 깨닫게 되었고, 더 나은 구현 방안을 모색할 기회를 놓친 적이 있다.
+
+이 경험을 통해 기술 선택 이전의 사전 의사결정 과정이 코딩만큼이나 중요하다는 점을 깨달은 바 있다. 단순히 구현 가능한 수준을 넘어서, 여러 가능성과 리스크를 체계적으로 검토하고 비교하는 것이 얼마나 중요한지를 뼈저리게 배운 경험이다.
+
+앞으로는 기술 선택 전, 다양한 대안을 탐색하고 의사결정 구조를 명확히 세운 뒤 진행할 계획이다. 충분한 고민과 탐색이 더 나은 결과를 만든다는 교훈을 실천에 옮기고자 한다.

12장/최서희.md

@@ -0,0 +1,32 @@
+# 12장. 창발성
+
+## 인상 깊은 내용 - 켄트 벡의 단순한 설계 규칙 (중요도 순)
+
+**1. 모든 테스트를 실행한다**
+
+   결합도가 높으면 테스트 케이스를 작성하기 어렵다. 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다. 테스트 케이스를 작성하면 설계 품질이 높아진다.
+
+**리팩터링 (2~4)**
+
+**2. 중복을 없앤다.**
+   소규모 재사용은 시스템 복잡도를 극적으로 줄여준다. 
+   * TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법
+
+**3. 프로그래머 의도를 표현한다.**
+   개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.
+   * 좋은 이름을 선택한다.
+   * 함수와 클래스 크기를 가능한 줄인다
+   * 표준 명칭을 사용한다. 예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다.
+   * 단위 테스트 케이스를 꼼꼼히 작성한다. 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어온다.
+
+**주의는 대단한 재능이다!!**
+
+**4. 클래스와 메서드 수를 최소로 줄인다.**
+
+---
+
+## 느낀점
+
+4가지의 단순한 설계 규칙은 앞으로 평생 기억해야 할 원칙이라고 생각해왔던 내용들이라, 깊이 공감하며 읽었다. 특히 이러한 규칙들이 모두 개인의 꾸준한 노력과 주의에서 비롯된다는 점에서, “노력은 배신하지 않는다”는 말이 자연스럽게 떠올랐다.
+
+

13장/최서희.md

@@ -0,0 +1,55 @@
+# 13장. 동시성
+
+## 인상 깊은 내용 
+
+**동시성이 필요한 이유?**
+
+  동시성은 겨합을 없애는 전략이다. 즉 무엇과 언제를 분리하는 전략이다.
+  스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다.
+
+**동시성과 관련한 일반적인 미신과 오해**
+
+  * **동시성은 항상 성능을 높여준다.**
+  동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다.
+
+  * **동서성을 구현해도 설게는 변하지 않는다.**
+  무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.
+
+  * **웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.**
+  실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다.
+
+**동시성과 관련된 타당한 몇 가지**
+
+  * **동시성은 다소 부하를 유발한다.*
+  동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다.
+
+  * **동시성은 복잡하다.**
+  무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.
+
+  * **동시성 버그는 재현하기 어렵다.**
+  진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다.
+
+  * **동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.**
+
+**동시성 방어 원칙**
+
+  * **단일 책임 원칙**
+    동시성 코드는 다른 코드와 분리하라
+  * **따름 정리: 자료 범위를 제한하라**
+    자료를 캡슐화하라, 공유 자료를 최대한 줄여라
+  * **따름 정리: 자료 사본을 사용하라**
+  * **따름 정리: 스레드는 가능한 독립적으로 구현하라**
+    독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라.
+  * **라이브러리를 이해하라**
+  * **실행 모델을 이해하라**
+  * **동기화하는 메서드 사이에서 존재하는 의존성을 이해하라**
+  * **동기화하는 부분을 작게 만들어라**
+  * **올바를 종료 코드는 구현하기 어렵다**
+  * **스레드 코드 테스트하기**
+
+---
+
+## 느낀점
+
+처음엔 프론트엔드와 동시성이 어떻게 연결되는지 명확하지 않아 와닿지 않았지만, 관련성을 찾으려 노력하며 읽었다. 직접적으로 적용할 부분은 많지 않았지만, 그래도 시스템의 복잡성과 설계에 대한 이해를 넓히는 데 도움이 된 것 같다.
+