[Book] Clean Code: 1 깨끗한 코드
클린 코드
애자일 소프트웨어 장인 정신
저자: 로버트 C. 마틴
1. 깨끗한 코드
page 1~20
깨끗한 코드라는 예술
깨끗한 코드를 작성하는 프로그래머는 빈 캔버스를 우아한 작품으로 바꿔가는 화가와 같다.
비야네 스트롭스트룹
우하하고 효율적인 코드
그래디 부치
가독성
큰 데이브 토마스
의미 있는 이름
마이클 페더스
누군가 주의 깊게 짰다는 느낌을 준다.
론 제프리스
중복이 없다.
워드 커닝햄
짐작했던 기능을 수행한다.
우리들 생각
이 책은 우리 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.
우리는 저자다
새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
보이스카우트 규칙
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
프리퀄과 원칙
이 책은 Agile Software Development: Principles, Patterns, and Practices의 프리퀄prequel이다.
이 책에서는 SRPSingle Responsibility Principle , OCP Open Closed Principle, DIPDependency Inversion Principle 와 같은 설계 원칙을 산발적으로 거론한다.
결론
예술가가 되기 위한 책은 없다. 나머지는 여러분에게 달렸다.
챕터 14 이후의 나머지 목차
15. JUnit 들여다보기
JUnit 프레임워크
결론
16. SerialDate 리팩터링
첫째, 돌려보자
둘째, 고쳐보자
결론
17. 냄새와 휴리스틱
주석
C1: 부적절한 정보
C2: 쓸모 없는 주석
C3: 중복된 주석
C4: 성의 없는 주석
C5: 주석 처리된 코드
환경
E1: 여러 단계로 빌드해야 한다
E2: 여러 단계로 테스트해야 한다
함수
F1: 너무 많은 인수
F2: 출력 인수
F3: 플래그 인수
F4: 죽은 함수
일반
G1: 한 소스 파일에 여러 언어를 사용한다
G2: 당연한 동작을 구현하지 않는다
G3: 경계를 올바로 처리하지 않는다
G4: 안전 절차 무시
G5: 중복
G6: 추상화 수준이 올바르지 못하다
G7: 기초 클래스가 파생 클래스에 의존한다
G8: 과도한 정보
G9: 죽은 코드
G10: 수직 분리
G11: 일관성 부족
G12: 잡동사니
G13: 인위적 결합
G14: 기능 욕심
G15: 선택자 인수
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 목록을 피하고 와일드카드를 사용하라
J2: 상수는 상속하지 않는다
J3: 상수 대 Enum
이름
N1: 서술적인 이름을 사용하라
N2: 적절한 추상화 수준에서 이름을 선택하라
N3: 가능하다면 표준 명명법을 사용하라
N4: 명확한 이름
N5: 긴 범위는 긴 이름을 사용하라
N6: 인코딩을 피하라
N7: 이름으로 부수 효과를 설명하라
테스트
T1: 불충분한 테스트
T2: 커버리지 도구를 사용하라!
T3: 사소한 테스트를 건너뛰지 마라
T4: 무시한 테스트는 모호함을 뜻한다
T5: 경계 조건을 테스트하라
T6: 버그 주변은 철저히 테스트하라
T7: 실패 패턴을 살펴하
T8: 테스트 커버리지 패턴을 살펴하
T9: 테스트는 빨라야 한다
결론
여기서 소개한 목록은 가치 체계를 피력할 뿐이다. 사실상 가치 체계는 이 책의 주제이자 목표다. 휴리스틱 목록을 익힌다고 소프트웨어 장인이 되지는 못한다. 전문가 정신과 장인 정신은 가치에서 나온다. 그 가치에 기반한 규율과 절제가 필요하다.