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

15장/최호.md

@@ -0,0 +1,22 @@
+# Part 15: JUnit 들여다보기
+
+
+## 내용
+
+> 조건문의 의도를 명확히 표현하려면 조건문을 캡슐화 해야한다. 즉, 조건문을 메서드로 뽑아내 적절한 이름을 붙인다.
+
+> 부정문은 긍정문보다 이해하기 더 어렵다. 그러므로 첫 if를 긍정으로 만들어 조건문을 반전한다.
+
+> formatCompatedComparison 이라는 함수처럼 함수의 의도를 정확히 표현하는 이름을 지어라.
+
+> 모듈은 일련의 분석 함수와 일련의 조합 함수로 나뉜다. 전체 함수는 위상적으로 정렬했으므로 각 함수가 사용된 직후에 정의된다. 분석 함수가 먼저 나오고 조합 함수가 그 뒤를 이어 나온다.
+
+> 리팩터링은 원래 했던 변경을 되돌리는 경우가 흔하다. 리팩터링은 코드가 어느 수준에 이를때까지 수많은 시행착오를 반복하는 작업이기 때문이다.
+
+## 느낀 점
+- 토스 프론트 문서에서 조건문에 관한 글을 본 적이 있다. 
+[글 1](https://frontend-fundamentals.com/code-quality/code/examples/submit-button.html)
+[글 2](https://frontend-fundamentals.com/code-quality/code/examples/ternary-operator.html)
+[글 3](https://frontend-fundamentals.com/code-quality/code/examples/condition-name.html)
+읽어보면 좋을거 같아요.
+- 항상 함수 이름도 짧게 코드도 짧게라는 생각을 하고 있었는데 하는 역할을 이름에 다 담는 함수를 만드는 것이 좋고, 너무 길면 한 함수가 하는 일이 너무 많은지도 다시 점검해봐야겠다고 생각했다.

16장/최호.md

@@ -0,0 +1,20 @@
+# Part 16:SerialDate 리팩터링
+
+
+## 내용
+
+> SerialDate는 시간 기반 날짜 함수가 아닌 순수 날짜 클래스이다.
+
+> 한 소스 코드에서 여러가지 언어를 사용한다. 이런건 좋지 않다.
+
+> 일련번호라는 용어는 정확하지 못하다. -> 영어의 정확한 의미를 알고, 그 도메인의 전문 용어를 사용하자
+
+> 추상 클래스는 구체적인 구현 정보를 포함할 필요가 없다.
+
+> 테스트 코드를 늘렸는데 코드 커버리지는 84.9%로 감소했다. 이는 클래스 크기가 작아지는 바람에 테스트를 하지 않는 코드의 비중이 커졌기 때문이다.
+## 느낀 점
+- 일련번호라는 용어은 어떻게 보면 좋은 이름일수 있다. 하지만 저자가 제시한 상대 오프셋이라는 용어가 이 상황에서는 더 적합하다고 느껴졌다. 비슷한 의미의 여러 단어가 있지만, 그 상황에 따라 무엇이 더 적합하고 무엇이 더 좋은 의미를 가지고 있는지 판단하는 건 개발자의 덕목인거 같다.
+
+- 추상 클래스는 구체적인 구현 정보를 포함할 필요가 없다는 말이 잘 이해가 안되는데 이야기 같이 해보면 좋을거 같습니다!
+
+- 테스트 코드를 늘렸는데 코드 커버리지는 감소했다고 한다. 이게 의미하는 바는 절대적인 수치가 중요한게 아니라 테스트가 무엇을 테스트 하는지, 테스트 하고자 하는 바를 정확히 이행했는지가 더 중요하다는 것인거 같다.

17장/최호.md

@@ -0,0 +1,77 @@
+# Part 17: 냄새와 휴리스틱
+
+
+## 내용
+
+### 주석
+> 변경 이력은 장황한 날짜와 따분한 내용으로 소스 코드만 번잡하게 만든다.
+
+> 쓸모 없어질 주석은 아예 달지 않는 편이 가장 좋다. 쓸모 없는 주석은 일단 들어가고 나면 코드에서 쉽게 멀어진다.
+
+> 코드만으로 충분한데 구구절절 설명하는 주석이 중복된 주석이다.
+
+> 작성할 가치가 있는 주석은 잘 작성할 가치도 있다. 시간을 들여 최대한 멋지게 작성해라.
+
+> 코드를 읽다가 주석으로 처리된 코드가 줄줄이 나오면 신경에 거슬린다. 주석으로 처리도니 코드는 지워버려라. 어차피 소스 코드 관리 시스템이 기억한다.
+
+### 환경
+> 빌드는 간단히 한 단계로 끝나야 한다. 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.
+
+> 여러 단계로 테스트해야 한다. 모든 단위 테스트는 한 명령으로 돌려야 한다.
+
+### 함수
+> 함수에서 인수 개수는 작을수록 좋다.
+
+> 출력 인수는 직관을 정면으로 위배한다. 함수에서 뭔가의 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경해라.
+
+> 플래그 인수는 함수가 여러 기능을 수행한다는 명백한 증거다. 피해라
+
+> 죽은 함수는 즉시 지워라, 얘도 관리 시스템이 기억한다.
+
+### 일반
+> 소스 파일 하나에는 언어 하나만 사용하는 방식이 좋다.
+
+> 최소 놀람의 원칙에 의거해 함수나 클래스는 다른 프로그래머가 당연하게 여길만한 동작과 기능을 제공해야 한다.
+
+> 모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성하라.
+
+> 실패하는 테스트 케이스를 일단 제껴두고 나중으로 미루는 태도는 신용카드가 공짜 돈이라 생각하는 급이다.
+
+> 코드를 Dry하게 만들어라.
+
+> 추상 클래스와 파생 클래스로 추상화를 수행해라. 어느 경우든 철저히 분리해야 한다. 고차원 개념과 저차원 개념을 섞어서는 안된다.
+
+> 클래스가 제공하는 메서드 수가 적을수록 좋다, 함수가 아는 변수 수도 작을수록 좋다. 인스턴스 변수 수가 작을수록 좋다.
+
+> 연관이 있으면 수직적으로도 가까워야한다.
+
+> 일관성 있는 변수명을 사용해야 한다.
+
+> 알고리즘을 이해해라. 괴상한 코드는 사람들이 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓이다. 잠시 멈추고 실제 알고리즘을 고민하지 않고 여기저기 if 문과 플래그를 넣어보며 코드를 돌리는 탓이다.
+
+### 이름
+> 서술적인 이름을 사용해라
+
+> 구현을 드러내는 이름을 ㅍ하고 적절한 추상화 수준에서 이름을 선택해라
+
+### 테스트
+> 테스트 케이스가 확인하지 않는 조건이나 검증하지 않는 계산이 있다면 그 테스트는 불완전하다.
+
+> 커버리지 도구는 테스트가 빠뜨리는 공백을 알려준다.
+
+> 사소한 테스트를 건너뛰지 마라. 제공하는 문서적 가치는 구현에 드는 비용을 넘어선다.
+
+> 무시힌 테스트는 모호함을 뜻한다.
+
+> 경계 조건은 철저히 테스트 하라.
+
+> 버그는 한고으로 모인 버그 주변을 철저히 테스트 해라.
+
+> 실패하는 패턴을 찾아라. 합리적인 순서로 정렬된 테스트 케이스는 실패 패턴을 드러낸다.
+
+> 테스트는 빨라야 한다.
+
+## 느낀 점
+> 두번째 독서 스터디 책의 모든 내용을 정리하는 장이였다. 책을 읽으면서 많이 고민했던 부분들을 위주로 정리해봤습니다.
+> 이 모든 규칙들을 항상 지킬 수는 없겠지만, 가끔이라도 이번 정리를 읽으면서 기억을 되살리며 코딩하고 싶다.
+> 알고리즘을 이해해라. 괴상한 코드는 사람들이 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓이다. 잠시 멈추고 실제 알고리즘을 고민하지 않고 여기저기 if 문과 플래그를 넣어보며 코드를 돌리는 탓이다. 이 문장이 제일 공감이 갔다. 항상 구현하기에 바빠서 코드 퀄리티는 신경쓰지 않고 돌아가는 코드만 만들었다. 이제는 여러 상황들을 고려하며 코딩하는 사람이 되어야겠다.