[Clean Code] 요약 (2)

1. 의미있는 이름 

• 의도를 분명히 밝혀라
• 그릇된 정보를 피하라
• 의미있게 구분하라
• 발음하기 쉬운 이름을 사용하라
• 검색하기 쉬운 이름을 사용하라
  • 검색 결과가 너무 많을 경우, 원하는 내용을 쉽게 찾기 힘들다.
• 인코딩을 피하라
• 자신의 기억력을 자랑하지 마라
• 클래스 이름
  • 명사, 명사구 - User, Payment)
• 메서드 이름
  • 동사, 동사구 - getName(), pay())
• 기발한 이름은 피해라
• 한 개념에 한 단어를 사용하라
  • User, Member, Customer
• 말장난을 하지 마라
• 해법 영역에서 가져온 이름을 사용하라
• 문제 영역에서 가져온 이름을 사용하라
• 의미있는 맥락을 추가하라
• 불필요한 맥락을 없애라

 

 

 

2. 메서드

• 작게 만들어라
  • 한 화면에 나오도록
  • 책에서는 가로 150자 이하, 세로 100줄 이하를 권장
• 한 가지만 해라
• 함수 당 추상화 수준은 하나로 (코드 가독성에 영향)
  • 위에서 아래로 코드 읽기
• Switch문의 사용법
• 서술적인 이름을 사용하라
• 함수 인수
  • 이상적인 인수의 개수는 무항 - 단항 - 이항 순
  • 삼항은 피하는 편이 좋다.
  • 다항은 특별한 이유가 필요하다.
  • 특별한 이유가 있어도 사용하면 안된다.
• 부수 효과를 일으키지 마라
• 명령과 조회를 분리하라
• 오류 코드보다 예외를 사용하라
• 반복하지 마라 (DRY - Do not Repeat Yourself)
• 구조적 프로그래밍
• 함수를 어떻게 짜죠?

 

 

 

3. 좋은 주석

• 법적인 주석
• 정보를 제공하는 주석
• 의도를 설명하는 주석
• 의미를 명료하게 밝히는 주석
• 결과를 경고하는 주석
• TODO 주석 (이후 코딩을 수정할 수 있도록)
• 중요성을 강조하는 주석
• 공개 API에서 Javadocs

 

 

 

4. 나쁜 주석

• 주절거리는 주석
• 같은 이야기를 중복하는 주석
• 오해할 여지가 있는 주석
• 의무적으로 다는 주석
• 이력을 기록하는 주석
• 있으나 마나 한 주석
• 무서운 잡음
• 함수나 변수로 표현할 수 있다면 주석을 달지 마라
• 위치를 표시하는 주석
• 닫는 괄호에 다는 주석
• 공로를 돌리거나 저자를 표시하는 주석
• 주석으로 처리한 코드
• HTML 주석
• 전역 정보
• 너무 많은 정보
• 모호한 관계
• 함수 헤더
• 비공개 코드에서 Javadocs

 

 

 

5. 형식 맞추기 (코딩 컨벤션)

• 적절한 행 길이 유지
  • 신문 기사처럼 작성하라 (위에서부터 아래로)
  • 개념은 빈 행으로 분리하라
  • 세로 밀집도
  • 수직 거리 (서로 밀접한 개념은 세로로 가까이 두고 한 파일에 속해야 한다.)
• 가로형식 맞추기
• 팀규칙

 

 

 

6. 객체와 자료 구조

• 자료 추상화
• 자료/객체 비대칭
  • 자료 구조를 사용하는 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.
  • 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
• 디미터 법칙
  • 클래스 C의 매서드 f는 다음과 같은 객체의 메서드만 호출해야한다.
  • 즉, 낮선 사람은 경계하고 근처에 있는 친구끼리 호출해야한다.

1. 클래스 C

2. f 가 생성한 객체

3. f 인수로 넘어온 객체

4. C 인스턴스 변수에 저장된 객체

 

• 자료 전달 객체

 

 

 

7. 오류 처리

• 오류 코드보다 예외를 사용하라
• Try-Catch-Finally 문부터 작성하라
• 미확인(unchecked) 예외를 사용하라
  • RunTimeException
• 예외에 의미를 제공하라
• 호출자를 고려해 예외 클래스를 정의하라
• 정상 흐름을 정의하라
• null을 반환하지 마라
• null을 전달하지 마라

 

 

 

8. 경계

• 외부 코드 사용하기
• 경계 살피고 익히기
• log4j 익히기
• 학습 테스트는 공짜 이상이다. (외부 라이브러리)
• 아직 존재하지 않는 코드를 사용하기
• 깨끗한 경계

 

 

 

9. 단위 테스트

• TDD 법칙 세 가지
  • 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  • 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  • 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 깨끗한 테스트 코드 유지하기
• 깨끗한 테스트 코드
• 테스트당 assert 하나
• FIRST 원칙
  • Fast 빠르게
  • Independent 독립적으로 (다른 테스트에 영향을 미치지 않도록)
  • Repeatable 반복가능하게 (Rollback)
  • Self-Validating 자가 검증하는
  • Timly 적시에

 

 

 

10. 클래스

• 클래스 체계
• 클래스는 작아야한다.
• 변경하기 쉬운 클래스

 

 

---

※ 앞의 내용을 확장한 챕터

 

11. 시스템

• 시스템 제작과 시스템 사용을 분리하라
• 확장
• 자바 프록시
• 순수 자바 AOP 프레임워크
• AspectJ 관점
• 테스트 주도 시스템 아키텍처 구축
• 의사 결정을 최적화하라
• 명백한 가치가 있을 때 표준을 현명하게 사용하라
• 시스템은 도메인 특화 언어가 필요하다.

 

 

 

12. 창발성

• 창발적 설계로 깔끔한 코드를 구현하자
  • 모든 테스트를 실행한다.
  • 중복을 없앤다.
  • 프로그래머 의도를 표현한다.
  • 클래스와 메서드 수를 최소로 줄인다.
• 단순한 설계 규칙
  • 모든 테스트를 실행하라
  • 리팩토링
• 중복을 없애라
• 표현하라
• 클래스와 메서드 수를 최소로 줄여라

 

 

 

13. 동시성

• 동시성이 필요한 이유
• 동시성 방어 원칙
  • 단일 책임 원칙 (SRP)
  • 자료 범위를 제한하라
  • 자료 사본을 사용하라
  • 스레드는 가능한 독립적으로 구현하라
• 라이브러리를 이해하라
• 실행 모델을 이해하라
• 동기화하는 메서드 사이에 존재하는 의존성을 이해하라
• 동기화하는 부분을 작게 만들어라
• 올바른 종료 코드는 구현하기 어렵다.
• 스레드 코드 테스트하기
  • 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라
  • 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
  • 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있도록 코드를 구현하라
  • 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있도록 작성하라
  • 프로세서 수보다 많은 스레드를 돌려보라
  • 다른 플랫폼에서 돌려보라
  • 코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라
  • 직접 구현하기
  • 자동화

---

14. 점진적인 개선

 

15. JUnit 들여다보기

 

16. SerialDate 리팩토링

 

17. 냄새와 휴리스틱