코드에서 나는 악취

코드에서 나는 악취

• 기이한 이름
  • 변수, 함수, 모듈 등등 이름을 보고도 무슨 일을 하고 어떻게 사용해야 하는지 명확해야 함
• 중복 코드
  • 똑같은 코드가 여러 곳에서 반복되는 코드.
• 긴 함수
  • 함수 내용이 너무 긴 경우.
• 긴 매개변수 목록
  • 매개 변수가 너무 많은 경우.
• 전역 데이터
• 가변 데이터
  • 어떤 데이터가 언제 어디서 변경될지 모르는 상태.
• 뒤엉킨 변경
  • 단일 책임 원칙을 지키지 않는 코드
• 산탄총 수술
  • 어설프게 분리되어 있는 코드의 경우, 어떤 기능을 변경할 때 전혀 동떨어진 곳의 코드도 수정해야함.
• 기능 편애
  • A라는 모듈이 자기 자신보다 다른 모듈과 더 많은 상호작용을 할 경우.
• 데이터 뭉치
  • 서로 연관이 있는 데이터 (변수등) 끼리 뭉쳐있지만 클래스나 구조체로 되어있지 않는 경우
• 기본형 집착
• 반복되는 switch문
  • 크리티컬 하진 않지만, 다형성에 관련한 .. (인터페이스 등) 을 사용하지 않는 코드에 대한 냄새
• 반복문
  • 반복문을 파이프라인으로 바꾸자. (자바스크립트 filter, map)
• 성의 없는 요소
  • 의미 없이 클래스나 함수로 분리한 경우.
• 추측성 일반화
  • 미래를 위해 작성 해놓은 코드등.. 실제로 당장 사용에 필요 없는 코드들. (죽은코드)
• 임시 필드
  • c 언어 시절에서 많이 쓰던 문법 말하는거 같음. 반복문을 위해서 함수 최상단에 int i; 이런거
• 메시지 체인
  • aPerson.department.manager.name; .. 이렇게 줄줄이 .. 나오는것.
• 중개자
  • 클래스가 단순히 중개자 역할만 할 때. (클래스가 다른 클래스에 구현을 위임하는 역할만 할 때)
• 내부자 거래
  • 모듈 사이에 데이터 거래가 많으면 결합도가 높아진다. 결합도를 낮추자.
• 거대한 클래스
  • 클래스가 너무 많은 일을 담당하면 냄새난다. (중복 코드가 생기기 쉽다)
• 서로 다른 인터페이스의 대안 클래스들
  • 서로 다른 클래스의 메서드가 하는 일은 비슷한 경우, 인터페이스를 통일시키고 가능하면 추출하자.
• 데이터 클래스
  • 게터/세터로만 정의된 클래스를 말한다. 다른 클래스에서 이 데이터 클래스의 게터 세터를 사용하는 부분을 살펴보고 데이터 클래스 자체로 가져올 수 있는 방법을 찾아보자.
• 상속 포기
  • 부모 클래스의 특정 부분을 상속하고 싶지 않을때.. 하지만 이 정도의 냄새는 견딜만하다.
• 주석
  • 주석은 탈취제가 아니다. 주석 대신 함수 이름을 명확하게 해보자. 주석을 다는건 사실 미안해해야할 일이다.

테스트 구축하기

테스트 코드가 있어야 리팩터링 후 발생하는 버그를 미연에 방지가 가능하다.

테스트 코드가 있어야 리팩터링의 효율이 높아진다.

테스트 코드로 임시로 스펙을 정의

임시로 구현

테스트.

리팩토링을 통하여 코드 개선.

위와 같은 프로세스가 TDD 다.

테스트 코드 작성 시 유의할 점

성공하기 위한 테스트는 의미가 없으므로, 테스트 작성 후 일부러 버그를 만들어서 잡아내는지 확인하자.

작성중인 코드는 자주자주 테스트를 계속계속 돌려보자. (직전에 수정한 코드가 문제라는것을 바로 알 수 있음)

작성한 테스트가 감지하지 못하는 부분을 항상 생각해보자.

테스트는 지속적으로 보강하자.

버그를 발견하면 발견하는 즉시 해당 버그를 테스트하는 테스트 코드도 작성하는 습관을 기르자.