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