Clean Code - 3주차

이번 주 목차 
9장 단위 테스트
10장 클래스
11장 시스템
12장 창발성

---

9장 단위 테스트

- TDD 법칙 세 가지

첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- Clean Code 155 Page 인용 - 

실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. 

적당한 테스트 코드를 작성하자. 무리하지 말자. 

 

- 깨끗한 테스트 코드 유지하기 

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.

단위 테스트란 테스트 코드이다? 

유닛 테스트 (unit test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다.

https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8

- 깨끗한 테스트 코드

가독성이 좋은 코드가 깨끗한 코드이다. 항상 최소한의 표현으로 많은것을 나타내기, 중복하지 않기! 

 

- 테스트 당 assert 하나

결혼이 하나라서 코드를 이해하기 쉽고 빠르다. 

(실제로 이번 우테캠에서 이런 요구사항을 코테에 제시하기 했다고 한다...) 

 

- F. I. R. S. T.

빠르게(Fast) : 테스트는 빨라야 한다.
독립적으로(Idependent) : 각 테스트는 서로 의존하면 안된다.
반복가능하게(Repeatable) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
자가검증하는(Self-Validating) : 테스트는 부울(boolean) 값으로 결과를 내야 한다. 성공 아니면 실패다.
적시에(Timely) : 테스트는 알맞은 때에 작성해야 한다.
- Clean Code 167 Page 인용 - 

테스트 코드를 작성할 때 룰이다. 

9장 단위 테스트 내 맘대로 정리

단위테스트가 곧 클린코드이다? 같은 말을 계속해서 반복하는 기분이다.

왜 단위테스트를 해야하는지 설명하는 것 같다.

---

10장 클래스

- 클래스 체계

클래스를 캡슐화 하자. 추상화 단계가 낮아지도록 쪼개고 또 쪼개자. 

 

- 클래스는 작아야 한다!

작게가 기본 규칙이다. 수정 할 이유가 하나뿐이야 한다. 

계속해서 쪼개고 쪼개서 객체간 결합도를 낮추자. 

 

- 변경하기 쉬운 클래스 

새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.
이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.
- Clean Code 188 Page 인용 - 

10장 클래스 내 맘대로 정리

10장을 읽는 내내 디미터 법칙이 생각났다. 최대한 작게 클래스를 나누자!

 

---

11장 시스템

- 도시를 세운다면?

복잡한 시스템에서도 깨끗함을 유지하는 방법을 알아보자. 

 

- 시스템 제작과 시스템 사용을 분리하라

제작하는 방법과 사용하는 방법은 다르다.

1. 생성과 사용을 분리하라? 

마침 회사에서 대시보드와 ADMIN페이지를 다르게 사용하고 있다. 

이게 시스템 제작과 사용을 분리하는 것인가 싶다...(?) 

2. 팩토리 구성하기 

클래스를 쪼개서 팩토리를 따로 구성하라는 이야기 인가...(?) 이 방법도 마침 회사에서 사용중이다. 3. 의존성 주입 한객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으면 된다. 팩토리를 구성하게 되면 의존성은 주입은 당연한 수순이 되지 않는가...? 잘 모르겠다.

 

- 확장

작은 단위의 클래스를 조정하고 같은 것을 모아 팩토리를 구성하고 점차 시스템을 확장한다는 말인 것 같다. 

 

- 자바 프록시

프록시를 사용하면 깨끗한 코드를 작성하기 어렵다! 

프록시는 시스템 단위로 실험 지점을 명시하지 않아 테스트 코드하기도 어렵다. 

근데 왜 설명한걸까? 

 

- 순수 자바 AOP 프레임워크

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다.

“우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고.” — 마틴 파울러

POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임워크이다.

https://ko.wikipedia.org/wiki/Plain_Old_Java_Object

테스트 코드가 상대적으로 단순하기 때문에 미래 스토리에 맞춰 코드를 보수하고 개선하기 쉽다. 

 

- AspectJ 관점

AspectJ는 PARC에서 개발한 자바 프로그래밍 언어용 관점 지향 프로그래밍 (AOP) 확장 기능이다. 
이클립스 재단 오픈 소스 프로젝트에서 독립형 또는 이클립스로 통합하여 이용 가능하다. 

https://ko.wikipedia.org/wiki/AspectJ

 

- 테스트 주도 시스템 아키텍처 구축

최선의 시스템 구조는 각기 POJO 시스템은 기민함을 제공한다. 이런 기민함 덕택에 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.

- Clean Code 211 Page 인용 - 

- 의사 결정을 최적화하라

가능한 마지막 순간까지 결정을 미루자! 너무 일찍 결정하면 고객 피드백을 무시하게 되고, 프로젝트의 구현 방안을 고민할 기회가 사라지게 된다고 한다. 맞는 말같다 고객 피드백으로 인해 프로젝트가 갈아엎어지는 장면을 몇 번 본것 같다.

이 정도면 마지막까지 결정을 미루다 마지막에 만들면 되지 않는가~? 

 

- 명백한 가치가 있을 때 표준을 현명하게 사용하라

고객의 가치가 뒷전으로 밀리지 않게! 

 

-시스템은 도메인 특화 언어가 필요하다

시스템 역시 개끗해야 하며 모든 추상화 단계에서 의도는 명확하게 표현해야 한다. 당연한 말을 너무 반복하고 있다. 

11장 시스템 내 맘대로 정리

고객의 가치가 뒷전으로 밀리지 않게! 고객사의 피드백을 중시하며 만들자! 

---

12장 창발성

- 창발적 설계로 깔끔한 코드를 구현하자

모든 테스트를 실행한다.
중복을 없앤다.
프로그래머 의도를 표현한다.
클래스와 메서드 수를 최소로 줄인다.

- Clean Code 216 Page 인용 - 

- 단순한 설계 규칙 1 : 모든 테스트를 실행하라

- 단순한 설계 규칙 2~4 : 리팩터링

테스트 케이스가 있어 시스템이 깨질까 걱정할 필요가 없는 리팩토링을 하자! 

 

- 중복을 없애라

계속되는 중복을 없애라는 말 3번 넘게 나오는 말이다.

 

- 표현하라

첫째, 좋은 이름을 선택한다.
둘째, 함수와 클래스 크기를 가능한 줄인다.
셋째, 표준 명칭을 사용한다.
넷째, 단위 테스트 케이스를 꼼꼼히 작성한다.

- Clean Code 221 Page 인용 - 

앞에서 나온 말을 반복하고 있다. 

 

- 클래스와 메서드 수를 최소로 줄여라

클래스와 메서드의 크기를 줄이면서도 수도 최소로 줄여라!

하지만 마지막 글을 읽어보면 이 규칙은 간단한 설계 규칙중 우선순위가 가장 낮다고 한다. 

그러니 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻이다! 

12장 창발성 내 맘대로 정리

계속되는 반복되는 구문들이다. 언제까지 클린코드를 읽고만 있고 실생활에 적극 활용하지 않을것인가? 반성하게 된다.