[7주차] 17장 정리

[17장] 냄새와 휴리스틱

🚩 나쁜 코드 정리하기

주석

1. 부적절한 정보
   • 다른 시스템에 저장할 정보는 주석으로 적절하지 않다
   • 작성자, 최종 수정일, SPR 번호
2. 쓸모없는 주석
   • 오래된 주석, 엉뚱한 주석, 잘못된 주석
   • 쓸모없는 주석은 빠르게 삭제하는 것이 좋다
3. 중복된 주석
   • 주석은 코드만으로 다하지 못하는 설명을 부언한다
4. 성의없는 주석
   • 간결하고 명료하게 가치 있는 주석을 작성한다
5. 주석 처리된 코드
   • 주석으로 처리된 코드를 발견하면 즉각 삭제한다

환경

1. 여러 단계로 빌드해야 한다
   • 한 명령으로 전체 를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다
2. 여러 단계로 테스트해야 한다
   • 모든 단위 테스트는 한 명령으로 돌려야 한다
   • 모든 테스트를 한번에 실행하는 능력은 아주 근본적이고 아주 중요하다

함수

1. 너무 많은 인수
   • 함수에서 인수 개수는 작을수록 좋다
2. 출력 인수
   • 직관을 정면으로 위반하게 됨
   • 함수에서 상태를 변경해야한다면 함수가 속한 개체의 상태를 변경한다
3. 플래그 인수
   • boolean 인수는 함수가 여러 기능을 한다는 증거이므로 피한다
4. 죽은 함수
   • 아무도 호출하지 않는 함수는 삭제한다

일반

1. 한 소스 파일에 여러 언어를 사용한다
   • 소스 파일 하나에 언어 하나만 사용하라
2. 당연한 동작을 구현하지 않는다
3. 경계를 올바로 처리하지 않는다
   • 모든 경계 조건을 찾아내고, 모든 경계조건을 테스트하는 테스트 케이스를 작성하라
4. 안전 절차 무시
   • 컴파일러 경고를 무시하지 않는다
5. 중복
   • 가장 중요한 규칙
   • 코드에서 중복을 발견할 때마다 추상화할 기회로 간주하라
   • 중복의 유형
     1. 똑같은 코드가 여러 차례 나오는 중복
     2. 여러 모듈에서 일련의 조건문으로 똑같은 조건을 거듭 확인하는 중복
     3. 알고리즘이 유사하나 코드가 다른 중복
6. 추상화 수준이 올바르지 못하다
   • 추상화로 개념을 분리할 때는 철저해야 한다
     • 모든 저차원 개념은 파생 클래스에 넣고, 모든 고차원 개념은 기초 클래스에 넣는다
7. 기초 클래스가 파생 클래스에 의존한다
   • 기초 클래스는 파생 클래스를 아예 몰라야 한다
   • 기초 클래스와 파생 클래스를 다른 JAR 파일로 배포하라
8. 과도한 정보
   • 클래스나 모듈 인터페이스에 노출할 함수를 제한할 줄 알아야 한다
   • 정보를 제하해 결합도를 낮춰라
9. 죽은 코드
   • 시스템에서 제거하라
10. 수직 분리
    • 변수와 함수는 사용되는 위치에 가깝게 정의하라
11. 일관성 부족
    • 비슷한 함수에서 사용한다면 다른 함수에서도 일관성 있게 동일한 변수 이름을 사용한다
12. 잡동사니
    • 쓸모없는 코드는 제거한다
13. 인위적 결합
    • 서로 무관한 개념을 인위적으로 결합하지 않는다
    • 함수, 변수, 상수를 선언할 때는 시간을 들여 올바른 위치를 고민한다
14. 기능 욕심
15. 선택자 인수
    • 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 것이 좋다
16. 모호한 의도
    • 코드를 짤 때는 최대한 의도를 분명히 드러낸다
17. 잘못 지운 책임
18. 부적절한 static 함수
    • static함수보다 인스턴스 함수가 좋다
19. 서술적 변수
    • 서술적으로 변수 이름을 사용하여 단계를 나눈다
20. 이름과 기능이 일치하는 함수
21. 알고리즘을 이해하라
    • 알고리즘을 충분히 이해한 후 코드를 구현하라
22. 논리적 의존성은 물리적으로 드러내라
    • 의존하는 모듈이 상대 모듈에 대해 뭔가를 가정하면 안된다
    • 의존하는 모든 정보를 명시적으로 요청하는 편이 좋다
23. if/else 혹은 switch/case 보다 다형성을 사용하라
24. 표준 표기법을 따르라
25. 매직 숫자는 명명된 상수로 교체하라
    • ex) SECONDS_PER_DATE
26. 정확하라
27. 관례보다 구조를 사용하라
    • 설계 결정을 강제할 때는 규칙보다 관레를 사용한다
28. 조건을 캡슐화하라
    • 조건의 의도를 분명히 밝히는 함수로 표현하라
29. 부정 조건은 피하라
30. 함수는 한 가지만 해야 한다
31. 숨겨진 시간적인 결합
    • 함수를 짤 때는 함수 인수를 적절히 배치해 함수가 호출되는 순서를 명백히 드러낸다
32. 일관성을 유지하라
    • 코드 구조를 잡을 때는 이유를 고민해라
33. 경계 조건을 캡슐화하라
    • 경계 조건을 빼먹거나 놓치지 않도록 여기저기에서 처리하지 않는다
34. 함수는 추상화 수준을 한 단계만 내려가야 한다
35. 설정 정보는 최상위 단계에 둬라

자바

1. 긴 import 목록을 피하고 와일드 카드를 사용하라
2. 상수는 상속하지 않는다
3. 상수 대 Enum

이름

1. 서술적인 이름을 사용하라
   • 이름은 성급하게 작명하지 않는다
   • 이름을 잘 지으면 기능도 잘 알 수 있다
2. 적절한 추상화 수준에서 이름을 선택하라
   • 구현을 드러내는 이름은 피하라
3. 가능하다면 표준 명명법을 사용하라
4. 명확한 이름
5. 긴 범위는 긴 이름을 사용하라
6. 인코딩을 피하라
7. 이름으로 부수 효과를 설명하라

테스트

1. 불충분한 테스트
   • 테스트 케이스가 확인하지 않는 조건이나 검증하지 않는 계산이 있다면 그 테스트는 불완전하다
2. 커버리지 도구를 사용하라
   • 테스트가 빠뜨리는 공백을 알려준다
3. 사소한 테스트를 건너뛰지 마라
4. 무시한 테스트는 모호함을 뜻한다
   • 선택 기준은 모호함이 존재하는 테스트 케이스가 컴파일이 가능한지 불가능한지에 달려있다
5. 경계 조건을 테스트하라
6. 버그 주변은 철저히 테스트하라
7. 실패 패턴을 살펴라
8. 테스트 커버리지 패턴을 살펴라
9. 테스트는 빨라야 한다