[전호영] 8장, 9장, 10장: 경계, 단위 테스트, 클래스

10장/전호영.md

@@ -0,0 +1,9 @@
+# 다시 볼 문장들
+- 클래스를 만들 대 첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두 번째 규칙도 크기다. 더 작아야 한다.
+- 클래스의 크기는 클래스가 맡은 책임으로 센다.
+- 클래스 이름은 해당 클래스 책임을 기술해야 한다.
+- 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
+- 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이다.
+
+# 느낀점
+객체지향에서 클래스가 가져야 하는 기본 개념에 대해 다시 숙지했다. 응집도, 책임에 관한 생각은 자주 했었지만, 모든 인스턴스 변수와 클래스 내 메서드의 관계에 대해선 생각한 적 없었다. 이런 부분에서 의식적으로 코드를 작성하는 습관을 들여야겠다.

8장/전호영.md

@@ -0,0 +1,9 @@
+# 다시 읽어 볼 문장들
+- Map 클래스를 사용하 때마다 위와 같이 캡슐화하라는 소리가 아니다. Map을(혹은 유사한 경계 인터페이스를) 여기저기 넘기지 말라는 말이다. Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다. Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.
+- 학습 테스트는 공짜 이상이다. 투자하는 노력보다 얻는 성과가 더 크다. 패키지 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다.
+- 우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다. 또한 코드 가독성도 높아지고 코드 의도도 분명해진다.
+- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. Map에서 봤듯이, 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자. 어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아지며, 외부 패키지가 변했을 때 변경할 코드도 줄어든다.
+
+# 느낀점
+
+Node.js 로 개발할 땐, Interface의 장점이 무엇인지 잘 몰랐던 것 같다. Spring을 사용하면서 Interface의 장점을 많이 느끼고 있는데, 이는 특히 개발 시에 그렇다. 기본으로 제공되는 Map, Set을 사용하면 결국 해당 타입이 무엇을 요구하는지 바로 알기 힘들다. 단순한 타입이어도, Interface로 래핑했을 때, 가독성이 더 높아지는 경험을 했다. 이게 결국은 경계를 관리하는 것과 연결된다는 것을 알게 되었다.

9장/전호영.md

@@ -0,0 +1,10 @@
+# 다시 읽어 볼 문장들
+- 팀은 지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보 백보라는, 아니 오히려 더 못한다는 사실을 개닫지 못했다.
+- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 
+- 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
+- 숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링해야 마땅하다. 
+- 가장 좋은 규칙은 "개념 당 assert 문 수를 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"라 하겠다.
+- 테스트는 부울값으로 결과를 내야한다. 성공 아니면 실패다. 통과여부를 알려고 로그 파일을 읽게 만들어선 안 된다. 통과 여부를 보려고 텍스트 파일 두 개를 수작업으로 비교하게 만들어서도 안 된다. 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 지루한 수작업 평가가 필요하게 된다.
+
+# 느낀점
+테스트 코드에 대한 리팩터링과 텍스트 비교에 대한 부분에서 느낀 점이 있다. 비즈니스 로직을 다루는 코드에 대한 리팩터링은 많이 생각해 봤지만, 테스트 코드에 대한 리팩터링은 고민해 본 적이 없다. 결국 잘 짜인 테스트 코드는 API 문서 역할을 할 수 있다는 점을 생각해 봤을 때, 테스트 코드에 대한 리팩터링은 필수라고 느꼈다. 추가로 에러 테스트를 하며 에러 문에 대한 텍스트 비교를 했었는데, 이런 부분도 테스트 시 줄여 나가야 하나 고민이 있다. 하지만 어떤 경우, 같은 에러 코드지만 다른 메시지를 주는 경우가 있다. 이럴 때 더 정밀한 테스트를 위해서 테스트 문에 대한 텍스트 비교를 해야 하지 않나? 생각도 든다.