개발자들이 리팩토링을 하지 않는 이유

  "리팩토링"(Martin Fowler저)에서 개발자들이 프로그램을 리팩토링 하지 않는 이유에 대해 Willam Opdyke가 다음과 같이 이야기 하고 있습니다.

1. 리팩토링을 하는 방법을 이해하지 못한다.
2. 리팩토링이 장기적으로 이익이라면, 왜 지금 당장 노력을 기울여야 하는가? 장기적으로 리팩토링의 이익을 챙길 그 프로젝트에 있지 않을 수도 있다.
3. 코드를 리팩토링하는 것은 오버헤드다. 여러분이 해야 하는 일은 새로운 기능을 추가하는 것이다.
4. 리팩토링은 기존 프로그램을 망칠 수 있다.

  정말 정곡을 찔러 주네요. 회사 내에서 뭔가 코드 정리활동 같은 걸 하고자 하면 늘상 하는 핑계들입니다.

  이 책에서는 위 네 가지 핑계에 대한 해답도 제시하고 있습니다.

1. 어디를 어떻게 리팩토링 해야 하는가?
  이 책과 여타 논문들에서 리팩토링을 템플릿 처럼 (이름까지 붙여가며) 만들어 놓았습니다. 물론 리팩토링 템플릿이라는 것이 고수들의 경험을 바탕으로 깔끔한 코드를 작성하는 방법을 기술한 것이기 때문에 상황에 맞게 적용해야 합니다. 각 리팩토링 예제를 무작정 따라하기 전에 왜 이런 리팩토링을 해야 하는 지 꼼꼼하게 읽고 이해해야 합니다.

2. 단기적인 이점을 달성하기 위한 리팩토링
  우리 회사에서 너무도 자주 접하는 상황입니다. 지금 진행중인 프로젝트만 끝나면 버리는 코드가 될 지도 모르고, 현재 프로젝트의 코드 베이스를 가져다 쓰게 될 다음 프로젝트에 투입될 지 말지도 모르는 데 뭐하러 노력을 들여가며 리팩토링을 하냐고 말들 합니다. 그러고는 쓰레기 같은 코드를 당연하다는 듯이 작성합니다. 이런 사람들을 보면 도대체 일을 하면서 배우고 나아지고자 하는 자세가 안되어 있는 것 같아 안타깝습니다.
  100보 양보해서 피쳐폰을 개발할 때야 플랫폼이 자주 바뀌어서 같은 코드베이스를 사용하는 모델 수가 적다고 해도, 안드로이드가 대세인 요즘에는 이런 자세를 좀 고쳐야 하지 않을까요?

  책에서 이야기하고 있는 단기적, 중기적 이점은 다음과 같습니다.
- 단기적 이점: 테스트 중 공통으로 사용되는 부분에서 발견되는 에러는 단지 한 곳에서만 수정하면 된다. 그리고 코드 크기가 더 작아진다.
- 중기적 이점: 리팩토링 과정 중 추상화가 되었기 때문에 다른 파일 시스템(또는 클래스, 기능 등으로 이해해도 무방)을 추가하기가 쉬워졌다. 

3. 리팩토링의 오버헤드 줄이기
  아, 정말 리팩토링은 무의미한 오버로드 인가요? 아니면 너무도 많은 업무에 치여 자기 코드를 손 볼 여유도 없어져 버린 건가요? 자 요즘에는 리팩토링을 자동으로 해 주는 도구가 많이 존재합니다. 코딩 능력을 향상시키고자 한다면 이런 툴을 능수능란하게 사용하는 것도 필수입니다. Eclipse를 쓰고 계신다면 Refactor 메뉴를 참고하세요.

4. 리팩토링을 안전하게
- 여러분의 코딩 능력을 믿어라
- 여러분이 놓친 에러들을 컴파일러가 발견할 것이라고 믿어라
- 여러분과 컴파일러가 놓친 에러를 테스트 스위트(test suite)가 발견할 것이라고 믿어라  (TDD는 필수입니다!)
- 여러분, 컴파일러, 테스트 스위트가 놓친 에러는 코드 검토(code review)에서 발견될 것이라고 믿어라

  위 4가지 안전장치에서도 걸러지지 않는 에러가 있을 가능성이 충분히 있습니다. 그렇다고 리팩토링을 하지 않을 건가요? 꼼꼼한 당신을 위해 추천하는 코딩습관이 더 있습니다. 리팩토링은 짝 프로그래밍을 통해 그리고 평소에 정적 분석 툴을 사용하는 습관을 들입시다.

  이 장에서 제가 가장 마음에 들었던 문장으로 마무리 합니다. 제 경험상 이는 진실입니다.

프로그래머는 그들의 코드를 리팩토링하면 할수록 더 잘 이해하게 될 것이다.
- Willam Opdyke