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

* Create 최서희.md

* Create 최서희.md

* Create 최서희.md

* Update 최서희.md

* Update 최서희.md

Author: karnelll

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,97 @@
+# 17장. 냄새와 휴리스틱
+
+## 인상 깊은 내용 
+
+**주석**
+
+  * 부적절한 정보
+    : 다른 시스템에 저장할 정보
+  * 쓸모 없는 주석
+    : 오래된 주석, 엉뚱한 주석, 잘못된 주석
+  * 중복된 주석
+    : 코드만으로 충부난데 구구절절 설명하는 주석
+  * 성의 없는 주석
+    : 작성할 가치가 있는 주석은 잘 작성할 가치도 있다. 간결하고 명료하게 작성한다.
+  * 주석 처리된 코드
+    : 코드를 읽다가 주석으로 처리된 코드가 줄줄이 나오면 신경이 아주 거슬린다.
+    
+**환경**
+
+  * 여러 단계로 빌드해야 한다.
+    : 빌드는 간단히 한 단계로 끝내야 한다. 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.
+  * 여러 단계로 테스트해야 한다.
+    : 모든 단위 테스트는 한 명령으로 돌려야 한다. IDE에서 바튼 하나로 모든 테스트를 돌린다면 가장 이상적이다.
+
+**함수**
+
+  * 너무 많은 인수
+    : 함수에서 인수 개수는 작을수록 좋다.
+  * 출력 인수
+    : 출력 인수는 직관을 정면으로 위배한다. 일반적으로 독자는 인수를 입력으로 간주한다. 함수에서 뭔가의 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경한다.
+  * 플래스 인수
+    : boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거다. 플래그 인수는 혼란을 초래하므로 피해야 마땅하다.
+  * 죽은 함수
+    : 아무도 호출하지 않는 함수는 삭제한다.
+ 
+**일반**
+
+  * 한 소스 파일에 여러 언어를 사용한다.
+  * 당연한 동작을 구현하지 않는다.
+  * 경계를 올바로 처리하지 않는다.
+  * 안전 절차 무시
+  * 중복
+  * 추상화 수준이 올바르지 못하다.
+  * 기초 클래스가 파생 클래스에 의존한다.
+  * 과도한 정보
+  * 죽은 코드
+  * 수직 분리
+  * 일관성 부족
+  * 잡동사니
+  * 인위적 결합
+  * 기능 욕심
+  * 서낵자 인수
+  * 모호한 의도
+  * 잘못 지운 책임
+  * 부적절한 static 함수
+  * 서술적 변수
+  * 이름과 기능이 일치하는 함수
+  * 알고리즘을 이해하라
+  * 논리적 의존성은 물리적으로 드러내라
+  * If/Else 혹은 Switch/Case문보다 다형성을 사용하라
+  * 표준 표기법을 따르라
+  * 매직 숫자는 명명된 숫자로 교체하라
+  * 정확하라
+  * 곤례보다 구조를 사용하라
+  * 조건을 캡슐화하라
+  * 부정 조건은 피하라
+  * 숨겨진 시간적인 결합
+  * 일관성을 유지하라
+  * 경계 조건을 캡슐화하라
+  * 함수는 추상화 수준을 한 단계만 내려가야 한다
+  * 설정 정보는 최상위 단계에 둬라
+  * 추이적 탐색을 피해라
+
+**자바**
+  * 긴 import 목록을 피하고 와일드카드를 사용하라
+  * 상수는 상속하지 않는다
+  * 상수 대 Enum
+
+**이름**
+  * 서술적인 이름을 사용하라
+  * 적절한 추상화 수준에서 이름을 선택하라
+  * 가능하다면 표준 명명법을 사용하라
+  * 명확한 이름
+  * 긴 범위는 긴 이름을 사용하라
+  * 인코딩을 피하라
+  * 이름으로 부수 효과를 설명하라
+
+**테스트**
+  * 불충분한 테스트
+  * 커버리지 도구를 사용하라!
+  * 사소한 테스트를 건너뛰지 마라
+  * 무시한 테스트는 모호함을 뜻한다
+  * 경계 조건을 테스트하라
+  * 버그 주변을 철저히 테스트하라
+  * 실패 패턴을 살펴라
+  * 테스트 커버리지 패턴을 살펴라
+  * 테스트는 빨라야 한다