리팩토링의 정의는 명사형과 동사형으로 나뉘어 있다.

리팩토링(명사형)-소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.

리팩토링 하다(동사형)-일련의 리팩토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어의 구조를 바꾸다.

이 부분에서 주목할 것은...
첫 째 리팩토링의 목적은 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 만드는 것이다.
두 번째로 강조하고 싶은 것은, 리팩토링은 겉으로 보이는 소프트웨어의 기능을 변경하지 않는 다는 것이다.

왜 리팩토링을 해야 하는가?

  • 리팩토링은 소프트웨어의 디자인을 개선시킨다.
  • 리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.
  • 리팩토링은 버그를 찾도록 도와준다.
  • 리팩토링은 프로그램을 빨리 작성하도록 도와준다.

여기서 Kent Beck이 자신에 대해 했던 멋있는 말이 하나 나온다. "나는 훌륭한 프로그래머는 아니다. 그냥 훌륭한 습관을 가지고 있는 좋은 프로그래머이다."

다른 건 그렇다 치고.. 네 번째 프로그램이 빨리 작성하도록 도와 준다는데.. 어떻게 코딩->리팩토링->코딩->리팩토링을 하는데 코딩 쭉~~~~ 보다 빠를 수 있을까 잠시 의아했었지만.. 유지보수 하는데 엄청난 비용이 들어간다는 점을 고려했을 때 소 잃고 외양간 고치는 폭포수 개발 절차에 비해 외양간에 못을 틈틈히 박아줌으로 써 외양간을 새로 짓는 일이 안생기도록 한다는 측면에서 빠르다고 생각한다.(물론 비유는 별로 적절치 않은 듯하다.)

언제 리팩토링을 해야 하는가?

  • 삼진 규칙(세 번째로 비슷한 것을 하게 되면 리팩토링 한다.).
  • 기능을 추가할 때 리팩토링을 하라.
  • 버그를 수정해야 할 때 리팩토링을 하라.
  • 코드 검토(code review)를 할 때 리팩토링을 하라.

여기서 또 Kent Beck의 '리팩토링이 작동하는 이유'라는 글이 나온다. 프로그램은 두 종류의 가치를 가지고 있는데 하나는 오늘 당장을 위한 것, 하나는 내일을 위한 것이라고 한다. 오늘 할일은 확실하지만 내일 할일은 알 수 없다. 하지만 오늘만을 위해서 일한다면 내일은 전혀 일을 할 수 없을 지도 모른다. 리팩토링은 이런 상황에서 빠져 나오는 방법이다.

관리자에게는 뭐라 말해야 하나?

관리자에 따라 다르다. 만약 관리자가 기술적인 지식이 있는 사람이라면 어렵지 않다. 품질을 고려하는 사람이라면 리팩토링이 버그를 줄이고 따라서 개발 속도를 빠르게 한다고 설득하면 된다. 하지만 보통은 시간을 중요시 하는데 이때는 리팩토링에 대해 말하지 말라.

자.. 여기서 또다시 Kent Beck의 '인디렉션과 리팩토링'이라는 글이 나온다. 인디렉션은 양날의 칼과 같다. 하나를 둘로 나누면 그만큼 관리해야 하는 것도 많아지게 된다. 하지만 그만큼 충분한 가치가 있다. 그 예로는 로직의 공유(서브 메소드), 의도와 구현을 분리하여 설명(클래스의 이름과 메소드의 작명은 의도를 설명할 기회 클래스와 메소드의 내부는 구현), 변경의 격리(하나의 객체가 두 곳에서 사용될 때 나는 그것의 서브클래스를 만들고 바꾸려는 것에서 이 객체를 참고하게 한다.), 조건 로직의 부호화(조건문 말고 다형성을 이용)다.

리팩토링을 할 때의 문제

  • 데이터베이스
  • 인터페이스 변경
  • 리팩토링이 어려운 디자인 변경
  • 언제 리팩토링을 하지 말아야 하는가?

데이터베이스에서 리팩토링이 어려운 이유는 대부분의 비즈니스 애플리케이션이 DB 스키마와 밀접하게 결합되어 있기 때문이고 또하나 데이터 마이그레이션의 어려움이다.

완전하지 않은 인터페이스를 공표하지 마라. 매끄러운 리팩토링을 위해 코드 소유권 정책을 수정하라.

다른 사람이 코드를 바꿀 수 있도록 코드 소유권 정책을 수정하라는 것이며 페어 프로그래밍에서 이와 같이 하는 것이 좋다.

코드를 처음부터 다시 작성해야 할 떄는 하지 않는 것이 좋으며 또한 마감일이 얼마 남지 않은 시점에서는 리팩토링을 부채의 개념으로 생각해야 한다.

리팩토링과 디자인

리팩토링은 디자인을 보완한다. 리택토링이 없다면 초기 디자인을 할 때 완벽하게 하려고 많은 시간과 노력을 들이게 된다. 그렇게 디자인을 하고 개발을 해도 어차피 처음에 디자인한 것이 변경되는 경우가 자주 생기는데 그 때 디자인을 변경하는 것은 비용이 너무 크다. 하지만 리팩토링을 하게되면 초기 디자인을 할 때 그러한 부담이 없으며 따라서 단순한 디자인을 가지고 시작하게 된다. 리팩토링은 변경의 위험에 대한 접근을 다르게 한다. 또 리팩토링은 융통성의 희생 없이 단순한 디자인을 유도한다.

이번에는 Ron Jeffries의 '아무것도 한 것 없이 시간만 보냄'이라는 글이 나온다. 이 글에서는 Date에 대한 5분여 간의 리팩토링을 통해 시스템의 속도가 2배나 빨라 졌다고 한다. 팀원이 Kent랑 Martin이였다는데 이 둘은 여기 참여 한적이 없다고 부인하고 있다고 한다.ㅋ;;
이 글의 교훈 : 시스템이 어떻게 돌아가는지 정확하게 알고 있다 하더라도, 추측만 하지 말고 실제로 퍼포먼스를 측정해보라. 무엇인가 배울 것이고, 십중팔구는 추측이 틀렸을 것이다.

리팩토링과 퍼포먼스

퍼포먼스 향상을 위해 가장 효율적으로 보이는 접근 방법은 일단 개발을 하고 그 뒤 최적화 단계에서 프로그램을 모니터 하여 특별하게 시간을 지체하거나 공간을 많이 차지 하는 부분을 발견하여 집중적으로 튜닝하는 것이다.

프로그램을 잘 분해하는 것은 이런 최적화를 수행할 때 두 가지 측면에서 도움이 된다. 첫째, 코드가 잘 분해되어 있으면 퍼포먼스에 집중할 수 있는 시간이 늘어난다. 둘째, 퍼포먼스를 분석할 때 좀 더 세밀한 분석이 가능하다.

리팩토링 기원

1980년대 초 smalltalk 사용자인 Ward Cunningham과 Kent Beck으로 부터 시작하여 Ralph Johnson도 스몰토크 계를 선도 했고.. 이 분의 제자인 Bill Opdyke의 박사학위 논문이 지금까지도 리팩토링 분야의 가장 중요한 연구 결과라고 한다.

2장은.. 코드가 없네... 그래도 재밌게 읽었습니다.