Agile

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

dextto™ 2011. 6. 20. 22:59

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

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


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

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

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

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

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

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

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

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

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

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


반응형