코드를 정리하는 이유와 언제,어떻게 할지에 관한 켄트 벡의 생각을 정리한 글

• 코드 정리법

  • 보호구문: 중첩된 조건 대신 전제조건을 미리 제시하자

    • if (조건) return if (다른 조건) return .. 코드 ..

  • 안 쓰이는 코드라면 그냥 지우자 → SCM을 통해 얼마든지 복구 가능하다

  • 비슷한 일을 한다면 공통 루틴을 분리하고 전부 통일하여 유사하게 만들자

  • 기존 인터페이스 사용이 어렵다면 신규 인터페이스를 구축하고 기존 인터페이스를 호출하도록 만들자

    • 나중에 기존 인터페이스를 하나씩 옮기고 삭제하자

  • 읽기 좋은 순서대로 정렬하는 것도 좋은 리팩토링이다

  • 응집도를 높이기 위해 영향이 가는 흩어진 코드를 한 곳에 모아보자

    • 응집도가 높아지면 결합도 역시 찾아서 변경하기 쉽게 된다

  • 선언과 초기화를 가장 가까운 위치에 두자

  • 설명하는 변수 형태를 쓰자 → 객체 생성 시에 긴 표현식을 쓰지 마라

  • 리터럴 상수 대신 설명하는(상징적인) 상수를 선언하고 대체하자

  • 명시적인 매개변수를 사용하도록 함수를 서브루틴으로 쪼개보자

  • 함수 내에서 구분이 되는 부분이 있다면 빈 줄을 넣어 분리하자

  • 목적이 분명하고 나머지 코드와 상호작용이 적은 코드는 헬퍼로 추출할 좋은 대상이다

  • 코드에서 명확하지 않은 내용은 주석을 적으세요

  • 불필요한 주석은 삭제하세요 → 삭제하기 위한 정리 역시 좋은 방법입니다

• 관리
  • 코드 정리와 동작 변경에 대한 커밋은 분리되어야 한다!!
  • 커밋은 작게 만드는 PR에 도전하고 결국에 정리 PR을 따로 검토하지 않는 시도를 해보자
  • 코드 정리는 다른 코드 정리에 관한 힌트를 제공한다. 하지만 너무 많이 빠르게 변경하지 말자
    • 작은 정리를 순차적으로 성공하는 것이 무리한 정리로 인해 실패하는것보다 낫다
  • 코드 정리는 동작 변경에 필요한 비용을 줄이게 되어 결과적으로 검토(리뷰) 비용 감소로 이어진다
  • 코드 정리는 오랜 시간이 필요한 작업이 아니다 → 주기적으로 자주 해야 한다
  • 코드 정리 시점
    • 하지 말아야 할때
      • 코드를 변경할 일이 없을 때
      • 개선하더라도 배울것이 없을 때
    • 나중에 해야할 때
      • 분량이 많은데 보상이 적은 경우
      • 작은 묶음으로 여러번에 나눠서 코드 정리를 해야할 때
    • 기능 개발보다 나중에 해야 할 때
      • 기다릴수록 비용이 늘어나는 변경일 때
      • 일이 남았다는 느낌이 들 때
    • 기능 개발보다 먼저 해야 할 때
      • 이해하기 쉬워지거나 동작 변경이 쉬워지는 효과가 있을 때
      • 어떻게 정리할지 알고 있을 때
• 이론
  • 설계란 요소의 계층 구조, 관계를 통해 만들어지는 이점을 가지는 행위
    • 코딩하기 직전에 무엇을 어떻게 해야할지 떠오를 정도까지만 한다
    • 이후 리팩토링을 통해 지속적 설계를 고려해야 한다
  • 선택 가능성: 소프트웨어가 유연하게 변하기 위한 능력
    • 위험요소: 핵심 직원 퇴사, 고객과의 먼 거리, 변경에 따른 비용 증가
  • 구조 변경과 동작 변경의 근본적인 차이는 가역성(되돌릴 수 있음)
  • 소프트웨어의 총 비용은 결합도의 비용과 같다
  • 모든 결합을 제거하려고 애쓰지 말자 → 한 종류의 결합도를 줄일 수록 다른 종류의 변경에 큰 결합도를 가지게 된다
  • 코드 정리는 작지만 모든 팀원이 혜택을 볼 수 있는 행위이다