[최서희] 8장, 9장, 10장: 경계, 단위 테스트, 클래스

10장/최서희.md

@@ -0,0 +1,17 @@
+# 10장. 클래스 
+
+## 인상 깊은 내용
+
+* **클래스 체계 - 캡슐화**
+
+  변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
+
+* **클래스는 작아야 한다! - 단일 책임 원칙/응집도**
+
+  단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙.
+
+* **변경하기 쉬운 클래스 - 변경으로부터 격리.**
+
+  깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
+  객체 지향 프로그래밍 입문에서 우리는 구체적인 클래스와 추상 클래스가 있다고 배웠다. 구체적인 클래스는 상세한 구현(코드)을 포함하며 추상 클래스는 개념만 포함한다고 배웠다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
+  시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.

8장/최서희.md

@@ -0,0 +1,20 @@
+# 8장. 경계
+
+## 인상 깊은 내용 
+
+* **경계 살피고 익히기**
+
+   곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨까? 짐 뉴커크는 이를 학습 테스트라고 부른다. 학습 테스트는 API를 사용하려는 목적에 초점을 맞춘다.
+
+* **학습 테스트는 공짜 이상이다**
+
+   경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다. 그렇지 않다면 낡은 버전을 필요 이상으로 오랫동안 사용하라는 유혹에 빠지기 쉽다.
+
+* **아직 존재하지 않는 코드를 사용하기**
+
+  아는 코드와 모르는 코드를 분리하라.
+
+* **깨끗한 경계**
+
+  통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.
+  외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.

9장/최서희.md

@@ -0,0 +1,21 @@
+# 9장. 단위 테스트
+
+## 인상 깊은 내용
+
+* **TDD 법칙 세 가지**
+
+    1. 실패하는 단위 테스트를 작성할 때까지 설계 코드를 작성하지 않는다.  
+    2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.  
+    3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
+
+* **테스트 당 개념 하나**
+
+* **F.I.R.S.T 원칙**
+
+    | 원칙        | 설명 |
+    |-------------|------|
+    | **Fast**    | 테스트는 빨라야 한다. 느리면 자주 실행할 수 없다. |
+    | **Independent** | 테스트는 서로 의존하지 않아야 한다. |
+    | **Repeatable** | 실제 환경, QA 환경, 네트워크가 없는 환경에서도 실행 가능해야 한다. |
+    | **Self-Validating** | 테스트는 불리언 값으로 결과를 알려야 한다. 로그를 읽게 해선 안 된다. |
+    | **Timely**  | 단위 테스트는 실제 코드를 구현하기 **직전**에 작성해야 한다. |