새로운 기능을 추가하기에 좋은(편한) 구조가 아니라면, 먼저 기능을 추가하기에 좋은(쉬운) 형태로 리팩토링하고 나서, 기능을 추가한다.

• 기존 코드가 동작이 잘 되고 있는 코드라고 할 지라도, 결국 코드의 심미성은 컴퓨터가 아닌 사람이 판단하므로 가독성이 좋은 코드를 작성하도록 한다.
• 가독성이 좋다는 것은 어떤 의미일까?
  • 수정이 용이한 코드
  • 클린 코드 & 클린 아키텍처 원칙을 기반으로 작성된 코드
    • JS의 https://github.com/ryanmcdermott/clean-code-javascript
  • 각 조직에서 논의된 네이밍 컨벤션/코드 패턴/패러다임의 원칙을 준수하여 작성된 코드

자주 변경될 일이 없거나 나중에도 변경이 많이 없는 코드라면, 굳이 지금 당장 관심을 가지지 않아도 좋다.

리팩터링은 테스트 코드 작성과 자가 진단 환경이 마련되어 있는지의 여부가 중요.

• 켄트백은 TDD는 불안함을 지루함으로 바꾸는 마법의 돌이라고 표현.

리팩터링 진행시, 작은 단위로 쪼개 진행하고 매번 테스트를 하도록 한다.

• 버전 관리 시스템을 사용중일 경우, 이 작은 단위 작업을 기준으로 커밋을 하도록 한다.

리팩터링으로 성능이 오히려 좋지 않은 코드가 생산될 경우, 일단 무시하자.

• 소프트웨어 성능은 대체로 코드의 작은 부분에 의해 결정되며, 그 외의 부분은 성능을 체감하기 쉽지 않다.
  • 물론, 성능에 크게 영향을 끼친다면 성능 개선을 위한 리팩터링을 추가로 진행한다.
    • 리팩터링된 코드로 성능 개선도 비교적 쉽게 진행이 가능하리라 예상된다.