[클린코드] Ch 17

Chapter 17

냄새와 휴리스틱

코드

• 쓸모 없어질 주석은 아예 달지 않는 편이 가장 좋다
• 주석 처리된 코드는 즉시 삭제하라
• 독자는 인수를 일반적으로 입력으로 간주한다. 함수에서 뭔가의 상태 변경이 필요하면 함수가 속한 객체의 상태를 변경하라.
• 아무도 호출하지 않는 함수는 삭제해라
• 모든 경계 조건을 찾아내고, 이를 테스트하는 TC를 작성하라
• 중복을 피하라! DRY원칙 (Don't Repeat Yourself)
  • 코드에서 중복을 발견할 때마다 추상화할 기회로 간주하라
  • 복사한 듯이 보이는 코드 -> 간단한 함수
  • switch/case, if/else -> 다형성 (polymorphism)
    • 새 유형을 추가할 확률보다 새 함수를 추가할 확률이 높은 코드에서는 switch문이 더 적합하지만
    • 유형보다 함수가 더 쉽게 변하는 극히 드물기 때문에 최대한 조건문은 줄이고, 다형성을 이용하자.
  • 알고리즘이 유사하나 코드가 서로 다른 중복 -> template method 패턴/strategy 패터
• 추상화 수준을 맞춰라
• 기초 클래스 개념을 저차원 파생 클래스 개념으로부터 분리해 독립성을 보장하라
• 잘 정의된 인터페이스는 많은 함수를 제공하지 않는다
  • 결합도가 낮다
• 비어있는 기본 생성자는 코드만 복잡하게 만든다
• 기능 욕심은 한 클래스의 속사정을 다른 클래스에 노출하므로, 최대한 제거하자
  • 예를들어 A 클래스의 메소드에서 B 클래스를 인수로 받아, 인수의 값들로 조작해서 A 클래스 인스턴수 변수/로컬 변수에 저장한다던가..
  • B 클래스의 메소드에서 구현하고, A 클래스 메소드에서는 B 클래스의 메소드만 구현하는 형태로 전환 필요
• 함수를 재정의할 가능성이 존재하는 함수들은 static으로 정의하면 안된다
  • 일반적으로 static 함수보다 인스턴스 함수가 더 좋다
• 숫자는 명명된 상수 뒤로 숨기자
• 병행 (concurrent) 특성으로 인해 동시에 갱신할 가능성이 있다면 적절한 잠금 매커니즘을 구현하자
• 부정 조건 대신에 가능하면 긍정 조건으로!
• 함수를 짤 때는 함수 인수의 적절한 배치로 함수 호출 순서를 명백히!
• 함수 내 모든 문장은 추상화 수준을 동일하게 한다
• 설정 정보는 최상위 단계에
• 디미터의 법칙: 한 모듈은 주변 모듈을 모를수록 좋다
  -a.getB().getC(). ... 피하기

자바

• 와일드카드 import문은 때로 이름 충돌이나 모호성을 초래 (이름이 같으나 패키지가 다른 클래스)
• 상수는 상속하지 않는다! (상수를 상위 계층에 숨겨두는 행위는 몹쓸 행위..)
• enum 잘 사용하기 :)

명명법

• 가능하다면 표준 명명법을 이용하자
  • ex) decorator 패턴을 활용하는 경우는 클래스 이름에 Decorator 라는 단어를 사용해야한다.
• 헝가리식 표기법의 잔해: 이름에 유형 정보/범위 정보는 피하자

테스트

• TC는 커버리지 도구를 활용하여 테스트가 빠뜨리는 공백을 찾아내고 메우자
• TC는 빨리 돌아가게 최대한 노력한다!