[Clean Code] 냄새와 발견법

Red : 냄새

Blue : 권장사항



1. 주석

○ 부적절한 정보 주석.
  - 코드와 설계에 기술적인 설명을 하거나, 메타 정보를 기술한 것을 제외하고는 대부분이 부적절한 정보이다.


○ 쓸모없는 주석.
  - 오래된 주석( 유지 보수 없는.. ), 엉뚱한 주석, 잘못된 주석은 필요 없다.


○ 중복된 주석.


○ 성의없는 주석.
  - 내용이 모호하거나, 별 기능을 못하는 주석.


○ 주석 처리된 코드.
  - SVN 같은 코드 관리 시스템으로 관리하라.




2. 환경

○ 빌드에 여러 단계가 걸린다.


○ 테스트에 여러 단계가 걸린다.




3. 함수

○ 너무 많은 인수
  - 없는 것이 가장 좋고, 하나는 봐줄만 하다. 넷 이상부터는 절대 피하는것이 좋다.


○ 출력인수.
  - 인수를 전달할 때는 보통 입력으로 간주한다. 입력의 상태를 변경하는 것을 출력인수라 하고, 이는 최대한 피해야 한다.


○ 플래그 인수
  - 플래스를 인수로 보낸다는 것은 명백히 여러 가지 기능을 수행한다는 의미이다. 나눠야 한다.


○ 죽은 함수
  - 아무도 호출하지 않는 함수를 죽은 함수라 하고 삭제 해야 한다.




4. 일반

○ 한 소스 파일에 여러 언어를 사용한다.
  - 한 소스 파일이 한 언어만 사용하는 편이 가장 좋다. ( 불가피한 경우가 많지만, 최대한 언어수를 줄여야 한다. )


○ 당연한 동작을 구현하지 않았다.
  - 함수나 클래스는 독자가 당연하게 여길 만한 동작과 기능을 제공해야 한다.


○ 경계를 올바로 처리하지 않는다.
  - 모든 경계 조건, 모든 구석진 곳, 모든 예외는 반드시 처리되어야 한다.
  - 경계조건에 대한 테스트 케이스는 필수이다.


○ 안전 절차 무시
  - 컴파일러 경고를 무시하거나, 실패하는 테스트 케이스를 제쳐두는 등의 행위는 피한다. ( 바로 처리해야 한다. )


○ 중복
  - 중복되는 부분을 함수로 뺀다.
  - switch/case 나 if/else 문은 다형성 ( polymorphism ) 으로 처리.
  - 미묘한 유형인, 알고리즘은 유사하나 코드가 서로 다른 중복은 Template method 나 strategy pattern 으로 처리.


○ 추상화 수준이 올바르지 못하다.
  - 모든 저차원 개념은 파생 클래스에 넣고, 모든 고차원 개념은 기본 클래스에 넣는다.


○ 기본 클래스가 파생 클래스에 의존한다.
  - 기본 클래스는 파생 클래스가 뭘 하는지 전혀 몰라야 한다.


○ 과도한 정보 ( 많은 interface )
  - 잘 정의된 인터페이스는 많은 함수를 제공하지 않는다.그래서 결합도 ( coupling ) 이 낫다.
  - 클래스가 제공하는 메소드 수는 적을수록 좋다.
  - 함수가 아는 변수 수도 작을수록 좋다. ( 맴버 변수도 작을수록 좋다. )


○ 죽은 코드
  - 실행되지 않는 코드를 제거하라. 예를 들어 switch/case 문에서 실행되지 않는 case 문은 삭제하라.


○ 수평 분리
  - 변수와 함수는 사용되는 위치에 가까이 정의한다. 지역 변수는 처음으로 사용하기 직전에 선언하며 수평 범위가 짧아야 한다.
  - private 함수는 처음으로 호출한 직후에 정의한다. ( 쉽게 눈에 띄어야 한다. )


○ 일관성 부족
  - Naming 의 일관성을 유지한다. 한 쪽에서 get 을 썻으면 얻어오는 행위는 계속 get 을 사용하고, 만일 fetch 를 썼다면 계속 fetch 만 사용한다.


○ 잡동사니
  - 비어 있는 생성자 등 사용하지 않는 변수, 함수, 주석 등을 제거한다.


○ 인위적 결합
  - 무관한 개념을 결합하지 않는다. 
  - 일반적인 enum은 특정 클래스에 속할 이유가 없다.  enum이 클래스에 속하면 사용하는 측에서는 그 class 를 알아야 한다.
  - 범용 static 함수도 마찬가지로 특정 클래스에 속할 이유가 없다.
  - 범용 static 변수도 특정 클래스에 속할 이유가 적다.


○ 기능 욕심
  - 클래스 메소드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 관심을 가져서는 안 된다.


○ 선택기 인수 ( boolean 인수 )
  - boolean 으로 작업을 구분하는 행위는 피한다.


○ 애매한 의도
  - 코드내용과 함수명 등으로 확실한 의도를 표시한다.


○ 잘못 지운 책임
  - 올바른 위치에 올바른 변수, 상수, 함수를 위치해야 한다.


○ 부적절한 static 함수
 

○ 서술적 변수
  - 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 방법


○ 이름과 기능이 일치하는 함수.


○ 알고리즘을 이해하라.
  - 대다수 괴상한 코드는 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓.
  - 실험적인 방법으로 검증하기 보다는 알고리즘이 올바르다는 사실을 이해하면 더 깔끔하고 확실히 코드를 만들고 검증할 수 있다.


○ 논리적 의존성은 물리적으로 드러내라.
  - 한 모듈이 다른 모듈에 의존한다면 의존하는 모든 정보를 명시적으로 요청하는 편이 좋다.


○ If/Else 혹은 Switch/Case 문보다는 다형성을 사용하라.


○ 표준 표기법을 따르라.
   - 인스턴스 변수 이름을 선언하는 위치, 클래스/메소드/변수 이름을 정하는 방법, 괄호를 넣는 위치 등을 명시해야 한다.


○ 매직 숫자는 명명된 상수로 교체하라.


○ 정확하라.
  - 검색 결과 중 첫 번째 결과만 유일한 결과로 간주하는 행동은 순진하다.
  - 아주 minor 한 케이스라 해도 발생 가능성이 있다면 고려되어야 한다.
  - 코드에서 뭔가 결정할 때는 정확히 결정한다.


○ 관례보다 구조를 사용하라.


○ 조건을 캡슐화하라.
  - 조건문의 의도를 확실히 나타나도록 함수를 사용한다.


○ 부정 조건은 피하라
  - 조건 함수는 부정조건을 피한다.


○ 함수는 한 가지만 해야 한다.


○ 숨겨진 시간적인 결합.
  - 함수를 짤 때 함수 인수를 적절히 배치해 함수가 호출되는 순서를 명백히 드러낸다.


○ 일관성을 유지.


○ 경계 조건을 캡슐화하라.
  - 경계 조건은 한 곳에서 별도로 처리한다. 예를 들어 +1, -1 등을 사방에 뿌리지 말고, 한 변수로 만들어 처리한다.


○ 함수는 추상화 수준 한 단계만 내려가야 한다.
  -  함수 내 모든 문장은 추상화 수준이 동일해야 한다.


○ 구성 정보는 최상위 단계에 두어라.
  - static 상수들은 최상위에 배치.


○ 추이적 탐색을 피하라.
  - 일반적으로 한 모듈은 주변 모듈을 모를수록 좋다. 예를 들어 A가 B를 사용하고 B가 C를 사용할 때 A가 C를 알 필요가 없다. 
   ( 디미터의 법칙 )




5. 자바

○ 긴 import 목록을 피하고 와일드카드를 사용하라
  - 패키지에서 클래스를 둘 이상 사용한다면 와일드카드를 사용해 패키지 전체를 가져오라. ( 진정한 의존성은 생기지 않는다. )


○ 상수는 상속하지 않는다.


○ 상수 대 Enum
  - enum 은 메소드와 필드를 사용할 수 있어 편하고 유용하다.




6. 이름

○ 서술적인 이름을 사용하라.


○ 적절한 추상화 수준에서 이름을 선택하라.
  - 구현을 드러내는 이름은 피하라. ( how 가 아니라 what 만 드러내도록 한다. )


○ 가능하다면 표준 명명법을 사용하라.


○ 명확한 이름을 사용하라.


○ 긴 범위는 긴 이름을 사용하라.
  - for 문과 같은 짧은 범위는 i, j 등이 괜찮다.


○ 인코딩을 피하라


○ 이름으로 부수 효과를 설명하라.




7. 테스트

○ 불충분한 테스트
  - "이 정도면 충분하지 않을까"라는 척도가 아니라, 확인하지 않은 조건이나 검증하지 않은 계산은 모두 테스트되어야 한다.


○ 커버리지 도구를 사용하라.
  - 커버리지 도구는 테스트가 빠뜨리는 공백을 알려준다.


○ 사소한 테스트를 건너뛰지 마라
  - 사소한 테스트는 짜기 쉽다. 그렇지만 무시하면 안된다.


○ 무시한 테스트는 모호함을 뜻한다.


○ 경계 조건을 테스트하라.


○ 버그 주변은 철저하게 테스트하라.
  - 버그는 서로 모이는 경향이 있다. 한 함수에서 버그를 발견했다면 그 함수를 철저히 테스트하는 편이 좋다.


○ 실패 패턴을 살펴라.


○ 테스트 커버리지 패턴을 살펴라.


○ 테스트는 빨라야 한다.