Refactoring

Refactoring

1. 리팩터링은 언제 해야 하는가?

• 코드가 더 이상 잘 맞지 않아서 장애물에 부딪혔을 때, 사실은 하나로 합쳐져야 할 두개를 발견 했을 때, 어떤 것이든 '잘못'되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안된다. 언제나 바로 지금이 최적기다. 어떤 것이라도 코드를 리팩터링해야 할 이유가 될 수 있다.

  • 중복
  • 직교성이 좋지 않은 설계
  • 유효기간이 끝난 지식: 코드는 지금 상황에 뒤떨어지지 않게 유지되어야 함
  • 성능: 성능을 개선하려면 시스템의 한 영역에서 다른 영역으로 기능을 옮겨야 함

• 여러분의 코드를 리팩터링하는 것 - 기능을 이리저리 옮기고 이전에 내린 결정을 갱신하는 것 -은 사실 고통 관리를 실천하는 것이다. 현실을 피하지 말자. 소스코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일 수도 있다. 거의 작동하는 수준까지 올려놓은 코드였는데, 이제 완전히 망가져 버린다. 코드를 산산조각으로 해체하는 일을 주저하는 개발자들이 많은데, 그 까닭은 그런 일을 하면 절대 안 될 것같기 때문인다.

• 현실 세계의 복잡한 문제들
  리팩터링이 필요한 코드를 일종의 '종양'이라고 생각하자. 종양을 제거하려면 수술이 필요하다. 지금이 바로 수술해서 아직 종양이 작을 때 제거할 수도 있다. 하지만 종양이 자라고 다른 곳으로 전이할 때까지 놓아둘 수도 있다. 하지만 그 때가 되면 제거하는 데 드는 비용도 더 커질 뿐더러 위험도 훨씬 커진다. 시간을 더끌면 환자는 생명을 잃을지도 모른다.

  일찍 리팩터링하고, 자주 리팩터링하라

  리팩터링해야 할 것들의 명단을 만들고 유지하라. 어떤 것을 지금 당장 리팩터링하기 힘들다면, 일정에 그것을 리팩터링할 시간을 확실히 포함시켜 두도록 한다. 그 코드를 사용하는 사람들이 코드가 조간만 리팩터링될 것이라는 사실과 그 사실이 그들의 코드에 어떤 영향을 주게 될지 인지하도록 만들어야 한다.

2. 리팩터링은 어떻게 하는가?

리팩터링의 본질은 재설계이다.

여러분 또는 여러분 팀의 다른 사람이 설계한 모든 것은, 새로운 사실이 밝혀지거나 문제에 대한 이해가 더 깊어지거나 요구사항이 바뀌는 것과 같은 일이 생긴다면, 언제라도 재설계의대상이 될 수 있다. 하지만 그렇다고 규모가 거대한 코드에서 아무 부분이나 닥치는 대로 삭제해 버리면서 산산조각으로 분해한다면, 나중에는 일을 시작하기 전보다 더 좋지 않은 처지에 놓일지도 모른다.

분명히 리팩터링은 천천히, 신중하게, 조심스럽게 진행해야하는 작업니다. 마틴 파울러는 손해보다 이득이 큰 방향으로 리팩터링을 하기 위한 다음 몇 가지 간단한 조언을 제공한다.

• 리팩터링과 새로운 기능 추가를 동시에 하지 말라.
• 리팩터링을 시작하기 전 든든한 테스트 집합이 있는지 먼저확인한다. 할 수 있는 한 자주 테스트를 돌려본다. 이렇게 하면 여러분의 변경 때문에 무엇이 망가졌을 경우 재빨리 그 사실을 알 수 있다.
• 단계를 작게 나누어서 신중하게 작업한다. 필드를 한 클래스에서 다른 클래스로 옮기기, 비슷한 메서드를 합쳐서 수퍼클래스로 옮기기. 리팩터링에서는 국지적인 변경들이 많이 모여서 커다란 규모의 변화를 낳는 일이 자주 발생한다. 단계를 작게 나누고, 한 단계가 끝날 때마다 테스트를 돌린다면, 기나긴 시간의 디버깅 작업을 피할 수 있다.

어떤 기준으로 리펙토링 하시나요?

깔끔한 코드, 더 나은 코드라는 것은 어떤것인가요?

• 코드컨벤션
• atomic한 함수
• testable한 코드

Reference

• [책] 실용주의 프로그래머, 앤드류 헌트 외 1명