[최서희] 15장,16장,17장 : JUnit 들여다보기, SerialDate 리팩터링, 냄새와 휴리스틱

15장/최서희.md

@@ -0,0 +1,7 @@
+# 15장. JUnit 들여다보기
+
+## 인상 깊은 내용 
+
+**코드를 리팩토링 하다보면 원래 했던 변경을 되돌리는 경우가 흔하다. 리팩터링은 코드가 어느 수준에 이를 때까지 수많은 시행착오를 반복하는 작업이기 때문이다.**
+
+**세상에 개선이 불필요한 모듈은 없다. 코드를 처음보다 조금 더 때끗하게 만드는 책임은 우리 모두에게 있다.**

16장/최서희.md

@@ -0,0 +1,16 @@
+# 16장. SerialDate 리팩터링
+
+## 인상 깊은 내용 
+
+**첫째, 돌려보자**
+
+**둘째, 고쳐보자**
+
+* 처음에 나오는 주석은 너무 오래되었다. 그레서 간단하게 고치고 개선했다.
+* 둘째, enum을 모두 독자적인 소스 파일로 옮겼다.
+* 셋째, 정적 변수(dateFormatSymbols)와 정적 메서드(getmonthNames, isLeap Year, lastDayOfMonth)를 DateUtil이라는 새 클래스로 옮겼다.
+* 넷째, 일부 추상 매서드를 DayDate 클래스로 끌어올렸다.
+* 다섯째, Month.make를 Month.fromInt로 변경했다. 다른 enum도 똑같이 변경했다, 다른 enum도 똑같이 변경했다. 또한 모든 enum에 toInt()접근자를 생성하고 index 필드를 private로 정의했다.
+* 여섯째, plusYears와 plusMonths에 흥미로운 중복이 있었다. correctLastDayOfMonth라는 새 메서드를 생성해 중복을 없앴다. 그래서 세 메서드가 모두 좀 더 명확해졌다.
+* 일곱째, 팔방미인으로 사용하던 숫자 1을 없앴다. 모두 MonthJANUARY,toInt() 혹은 Day.SUNDAY.toInt()로 적절히 변경했다. SpredsheetDate 코드를 살펴보고 알고리즘을 조금 손봤다. 
+

17장/최서희.md

@@ -0,0 +1,50 @@
+# 17장. 냄새와 휴리스틱
+
+## 인상 깊은 내용 
+
+**주석**
+
+  * 부적절한 정보
+    : 다른 시스템에 저장할 정보
+  * 쓸모 없는 주석
+    : 오래된 주석, 엉뚱한 주석, 잘못된 주석
+  * 중복된 주석
+    : 코드만으로 충부난데 구구절절 설명하는 주석
+  * 성의 없는 주석
+    : 작성할 가치가 있는 주석은 잘 작성할 가치도 있다. 간결하고 명료하게 작성한다.
+  * 주석 처리된 코드
+    : 코드를 읽다가 주석으로 처리된 코드가 줄줄이 나오면 신경이 아주 거슬린다.
+
+**환경**
+
+  * 여러 단계로 빌드해야 한다.
+    : 빌드는 간단히 한 단계로 끝내야 한다. 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.
+  * 여러 단계로 테스트해야 한다.
+    : 모든 단위 테스트는 한 명령으로 돌려야 한다. IDE에서 바튼 하나로 모든 테스트를 돌린다면 가장 이상적이다.
+
+**함수**
+
+  * 너무 많은 인수
+    : 함수에서 인수 개수는 작을수록 좋다.
+  * 출력 인수
+    : 출력 인수는 직관을 정면으로 위배한다. 일반적으로 독자는 인수를 입력으로 간주한다. 함수에서 뭔가의 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경한다.
+  * 플래스 인수
+    : boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거다. 플래그 인수는 혼란을 초래하므로 피해야 마땅하다.
+  * 죽은 함수
+    : 아무도 호출하지 않는 함수는 삭제한다.
+
+**일반**
+
+  * 한 소스 파일에 여러 언어를 사용한다.
+    : 이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다. 각별한 노력을 기울여 소스 파일에서 언어 수와 범위를 최대한 줄이도록 애써야 한다.
+  * 당연한 동작을 구현하지 않는다.
+    : 최소 놀람의 원칙에 의거해 함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 동작과 기능을 제공해야 한다.
+  * 경계를 올바로 처리하지 않는다.
+    : 코드는 올바로 동작해야 한다. 스스로의 직관에 의존하지 마라. 모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성하라.
+  * 안전 절차 무시
+    : 실패하는 테스트 케이스를 일단 제껴두고 나중으로 미루는 태도는 신용카드가 공짜 돈이라는 생각만큼 위험하다.
+  * 중복
+    : 이 책에 나오는 가장 중요한 규칙이다. 켄트 백은 익스트림 프로그래밍의 핵심 규칙 중 하나로 선언한 후 "한 번, 단 한번만이라 명명했다. 론 제프리스는 이 규칙을 "모든 테스트를 통과한다"는 규칙 다음으로 중요하게 꼽았다.
+  * 추상화 수준이 올바르지 못하다.
+    : 이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다. 각별한 노력을 기울여 소스 파일에서 언어 수와 범위를 최대한 줄이도록 애써야 한다.
+