Clean Code - 4주차

이번 주 목차 

17장 냄새와 휴리스

부록A 동시성Ⅱ

부록B org.jfree.date.SerialDate

부록C 휴리스틱의 교차 참조 목록

---

17장 냄새와 휴리스틱

 
- 주석

C1: 부적절한 정보 : 일반적으로 작성자, 최종 수정일, SPR번호 만 주석으로 넣는다.
C2: 쓸모없는 주석 : 오래된 주석, 엉뚱한 주석, 잘못된 주석은 아예 달지 말자.
C3: 중복된 주석 : 구구절절 설명하는 주석 달지 말자.
C4: 성의 없는 주석 : 간결하고 명료하게 주석 달자.
C5: 주석 처리된 코드 : 주석으로 처리된 코드는 즉각 삭제하자!

- 환경

 

E1: 여러 단계로 빌드해야 한다 : 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.
E2: 여러 단계로 테스트해야 한다 : 모든 단위 테스트는 한 명령으로 돌려야 한다.

 

- 함수

F1: 너무 많은 인수 : 함수에서 인수 개수는 아예 없으면 가장 좋다.
F2: 출력 인수 : 함수에서 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경하자.
F3: 플래그 인수 : boolean 인수는 함수가 여러 기능을 수행한다는 증거이다. 피하자!
F4: 죽은 함수 : 아무도 호출하지 않는 함수는 삭제한다.

 

- 일반

 

G1: 한 소스 파일에 여러 언어를 사용한다 : 이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다! 최대한 줄이자.
G2: 당연한 동작을 구현하지 않는다 : 신뢰하지 못하는 동작은 구현하지 말자!
G3: 경계를 올바로 처리하지 않는다 : 모든 경계 조건을 테스트하는 테스트 케이스를 작성하자.
G4: 안전 절차 무시 : 실패하는 테스트 케이스를 미루지 말자.
G5: 중복 : 최근 15년 동안 나온 디자인 패턴 대다수가 중복을 제거하는 방법에 불과하다. 중복은 발견 즉시 없애라!
G6: 추상화 수준이 올바르지 못하다 : 잘못된 추상화는 임시변통으로 고치기 불가능하다.
G7: 기초 클래스가 파생 클래스에 의존한다 : 독립적인 개별 컴포넌트 단위로 배치하면 시스템을 유지보수하기 쉽다.
G8: 과도한 정보 : 정보를 제한해 결합도를 낮춰라.
G9: 죽은 코드 : 실행되지 않는 코드는 제거해라.
G10: 수직 분리 : 변수와 함수는 눈에 띄기 쉽게 위치상 가깝게 정의한다.
G11: 일관성 부족 : (변수 이름등을) 유사한 개념으로 같은 방식으로 구현하라.
G12: 잡동사니 : 비어 있는 기본 생성자는 제거해라.
G13: 인위적 결합 : 함수, 상수, 변수를 선언할 대 시간을 들여 올바른 위치에 배치해라.
G14: 기능 욕심 : 클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야한다.
G15: 선택자 인수 :  boolean 인수 대신 새로운 함수를 만드는 편이 좋다.
G16: 모호한 의도 : 의도를 분명하게 밝혀라.
G17: 잘못 지운 책임 : 함수 이름을 제대로 짓자.
G18: 부적절한 static 함수 : 재정의할 필요가 없는지 꼼꼼하게 따져보자.
G19: 서술적 변수 : 서술적인 변수 이름은 많이 써도 괜찮다.
G20: 이름과 기능이 일치하는 함수 : 더 좋은 이름을 붙이자.
G21: 알고리즘을 이해하라 : 기능이 뻔히 보일 정도로 깔끔하고 명확하게 재구성하는 방법이 최고다.
G22: 논리적 의존성은 물리적으로 드러내라 : 한 모듈이 다른 모듈에 의전한다면 물리적 의존성도 필요하다.
G23: if/else 혹은 switch/case 문보다 다형성을 사용하라 : 같은 선택을 수행하는 코드에서 다형성 객체를 생성해 대신한다.
G24: 표준 표기법을 따르라 : 팀이 정한 표준은 팀원들 모두가 따라야 한다.
G25: 매직 숫자는 명명된 상수로 교체하라  : 의미가 분명하지 않은 토큰 등 모든 숫자를 포함한다.
G26: 정확하라 : 코드에서 모호성과 부정확은 의견차나 게으름의 결과이다.
G27: 관례보다 구조를 사용하라 : 설계 결정을 강제할 때는 규칙보다 관례를 사용한다.
G28: 조건을 캡슐화하라 : 조건의 의도를 분명하게 밝히는 함수로 표현하자.
G29: 부정 조건은 피하라 : 부정 조건은 긍정 조건보다 이해하기 어렵다.
G30: 함수는 한 가지만 해야 한다
G31: 숨겨진 시간적 결합 : 함수가 복잡해져도 시간적인 결합이 필요하다. 
G32: 일관성을 유지하라 : 코드 구조를 잡을 때 이유를 고민하고 명백히 표현해라.
G33: 경계 조건을 캡슐화하라 
G34: 함수는 추상화 수준을 한 단계만 내려가야 한다 : 함수 내 모든 문장은 추상화 수준이 동일해야 한다.
G35: 설정 정보는 최상위 단계에 둬라
G36: 추이적 탐색을 피하라 : 한 모듈은 주변 모듈을 모를수록 좋다.

- 자바

J1: 긴 import 목록을 피하고 와일드카드를 사용하라  : import package.*; 를 사용해라.
J2: 상수는 상속하지 않는다 : static import 를 사용해라.
J3: 상수 대 enum : public static final int 대신 enum을 활용해라!

- 이름

 

N1: 서술적인 이름을 사용하라 : 서술적인 이름을 신중하게 고른다.
N2: 적절한 추상화 수준에서 이름을 선택하라 : 구현을 드러내는 이름은 피해라.
N3: 가능하다면 표준 명명법을 사용하라 : 프로젝트에 유효한 의미가 담긴 이름을 많이 사용할수록 독자가 코드를 이해하기 쉬워진다.
N4: 명확한 이름 : 함수나 변수의 목적을 명확히 밝히는 이름을 선택한다.
N5: 긴 범위에는 긴 이름을 사용하라 : 범위가 작으면 아주 짧은 이름을 사용하고 범위가 길어지면 긴 이름을 사용하라.
N6: 인코딩을 피하라 : 이름에 유형 정보나 범위 정보를 넣지 말자.
N7: 이름으로 부수 효과를 설명하라 : 함수, 변수, 클래스가 하는 일을 모두 기술하는 이름을 사용하자.

- 테스트

T1: 불충분한 테스트 : 테스트는 많을수록 좋다. 
T2: 커버리지 도구를 사용하라! : 커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다.
T3: 사소한 테스트를 건너뛰지 말라
T4: 무시한 테스트는 모호함을 뜻한다 
T5: 경계 조건을 테스트하라 : 알고리즘의 중앙 조건은 올바르게 짜놓고 경계 조건에서 실패하는 경우가 흔하다.
T6: 버그 주변은 철저히 테스트하라 : 버그 주변에 다른 버그들이 발견된 확률이 많다. 
T7: 실패 패턴을 살펴라 
T8: 테스트 커버리지 패턴을 살펴라 
T9: 테스트는 빨라야 한다 

- 결론

전문가 정신과 장인 정신은 가치에서 나온다. 그 가치에 기반을 둔 규율과 절제가 필요하다.

 

17장 냄새와 휴리스틱 내 맘대로 정리

책에 써진 모든 내용을 복습하는 장같다. 계속해서 반복되는 이야기가 나온다...

 

---

부록A 동시성Ⅱ

https://devmoons.tistory.com/entry/%EB%B6%80%EB%A1%9D-A-%EB%8F%99%EC%8B%9C%EC%84%B12