필자의 프로젝트 팀내 감금 사태로 인해 12월호 특집 기사에 2페이지가 부족하니 채워달라는 긴급 SOS 연락을 받고 급하게 작성해서 보낸 기사입니다. 옛날에 있던 회사 동료 분이랑 오랜만에 넷미팅과 구글토크를 이용해서 TDD 수련을 위한 짝프로그래밍 놀이를 했더니 이 글이 생각나서 올려봅니다.

테스트와 리팩토링
"리팩토링을 하고자 할때 견고한 테스트는 없어서는 안 될 필수조건이다.“

마틴 파울러는 리팩토링을 할 때 반드시 기억해야 할 기본 명제로 아래의 2가지 항목을 말했다.

(1) 리팩토링은 소프트웨어의 기능을 변경하지 않는다.
(2) 제대로 동작하지 않는 코드는 리팩토링하지 않는다.

이를 통해 기능을 추가하는 작업과 기능의 추가 없이 내부 구조를 개선하는 작업을 나누어 진행해야 함을 알 수 있다. 여기서 중요한 것은 이러한 기본 명제에 의해 파생되는 2가지 요구사항이다.

(1) 내가 추가한 기능이 제대로 동작한다는 것을 확인한 다음에야 리팩토링을 수행할 것인지에 대한 여부를 결정할 수 있다.
(2) 리팩토링을 한 이후에 소프트웨어는 리팩토링을 하기 전과 비교해서 기능 변경이 없어야 한다.

어떻게 추가한 기능이 개발자의 의도대로 바르게 동작함을 확인할 수 있을까? 어떻게 리팩토링 과정에서 기존에 잘 동작하던 기능들이 훼손되지 않았음을 보장할 수 있을까? 이 질문에 대한 답은 바로 테스트이다. 테스트는 리팩토링과 따로 떼어 생각할 수 없는 필수적인 행위인 것이다.

그럼에도 불구하고 리팩토링을 실천하고 있다고 주장하는 많은 개발자들 중에 테스트의 가치를 진심으로 인정하는 사람을 만나기는 쉽지 않다. 리팩토링 카탈로그에 소개된 리팩토링 기법들을 실천함으로써 “훌륭한 개발자는 사람이 이해할 수 있는 코드를 짠다”는 가치를 추구하고 있는 개발자라면, 일정 부족이나 기능추가 외에는 가치를 이해하지 못하는 관리자를 핑계로 테스트 개발을 소홀히 해서는 안된다. 테스트가 없는 리팩토링은 최소한의 전제 조건도 만족시키지 못하는 반쪽짜리에 불과하기 때문이다.

하지만 이미 구현을 끝내고 직접 실행시켜보는 방법으로 동작을 확인한 코드에 대해 테스트를 작성하다 보면 내가 왜 이 짓을 하고 있을까 하는 의구심이 들기 마련이다. 그래서 테스트를 개발한다 하더라도 형식적인 테스트에서 그치고 만다. 이러한 상황에서 벗어나기 위한 최선의 방법은 구현에 앞서 테스트를 먼저 개발하는 테스트 주도 개발(Test-Driven Development)을 도입하는 것이다. 테스트 주도 개발을 가끔 테스트 주도 리팩토링(Test-Driven Refactoring)이라고 부르는 이유는 이처럼 둘의 궁합이 잘 맞기 때문이다. 리팩토링에서 테스트는 강력한 버그 탐지기의 역할을 한다. 이런 테스트는 개발을 진행하는 전 주기에 걸쳐서 자주 실행된다. 따라서 자동화된 빌드 도구를 활용해서 모든 테스트를 자동화하는 것이 권장된다. 테스트 주도 개발과 자동화된 테스트는 여러분이 작성한 코드에 대해 자신감을 불어넣고, 리팩토링이라는 도구를 마음껏 휘두를 수 있도록 도와주는 든든한 후원자가 될 것이다.

안타깝게도 나쁜 냄새 목록과 리팩토링 카탈로그를 달달 외운다고 해서 리팩토링을 숙달했다고 말하기 힘든 것처럼, 테스트 주도 개발도 원리와 기술을 익히기는 쉽지만 실전에서 적용하기 위해서는 오랜 시간의 훈련을 필요로 한다. 아직 테스트 주도 개발을 시도해보지 않았던 개발자라면 모든 것을 한꺼번에 이루어 내리라는 기대는 버리는 것이 좋다. 1일 1테스트 만들기, 토요일 오후를 테스트 작성 훈련에 할애하기와 같이 조금씩 자신의 테스트 관련 기술을 향상시키는 방법을 고민하고 실천하기를 권한다. 아래 그림에서 보듯 일일이 수작업으로 동작을 확인하던 시절과 비교하면, 자동화된 테스트 작성을 위해 투자한 시간을 분명히 보상받을 수 있을 것이다.

디자인 패턴과 리팩토링
“패턴은 우리가 있고 싶은 곳이고, 리팩토링은 그곳에 이르는 방법이다.”

마틴 파울러가 저술한 리팩토링 서적은 나쁜 디자인을 좋은 디자인으로 바꿔주는 마법과 같은 기법들을 카탈로그 방식으로 잘 분류해서 정리해 주고 있다. 하지만 대부분 이름 변경이나 메소드 추출과 같은 저수준의 리팩토링을 다루고 있기 때문에, 풍부한 경험을 갖추지 못한 개발자들에게는 최선의 설계를 이끌어낼 수 있는 장치가 부족한 것도 사실이다. 이를 보완할 수 있도록 다양한 디자인 패턴이 존재하지만, 디자인 패턴에 집중하다 보면 지속적이고 발전적인 설계라는 리팩토링의 개념에서 벗어나기 쉽다. 패턴의 강력함에 빠져 간단하게 작성할 수 있는 코드를 괜히 복잡하게 만든다거나, 미래의 요구사항까지 모두 예측해서 미리부터 필요이상으로 과도한 설계를 하게 되는 경우가 있는 것이다.

리팩토링을 도입 하자니 패턴을 적용한 것과 같은 품질의 설계에 이르지 못하고, 패턴을 도입하자니 패턴 만능주의에 빠져 버리는 것이 두려운 개발자들을 위해 또 하나의 좋은 서적이 세상에 모습을 드러냈다. 그게 바로 “패턴을 활용한 리팩토링(Refactoring to Patterns)”이라는 책이다. 이 책은 리팩토링에서 소개한 저수준의 리팩토링 기법을 복합적으로 활용해서, 패턴 중심의 사전 설계를 했을 때와 같은 수준의 설계로 코드를 리팩토링 해 나가는 기법을 소개하고 있다. 동기->절차->예제로 구성된 각각의 복합 리팩토링 기법을 리팩토링 서적과 같은 카탈로그 방식으로 정리하고 있다는 것도 장점이다. 디자인 패턴과 리팩토링을 공부했지만 아직 그 두 가지 기술이 가지는 장점을 하나로 합칠 만큼의 내공을 갖추지 못했다면, “패턴을 활용한 리팩토링” 서적에 소개된 기법들을 훈련하고 적용해보기를 권한다.

프로젝트 팀의 리팩토링

팀 단위 개발을 진행할 때의 리팩토링은 몇 가지 주의할 점이 있다.

1. 리팩토링을 지원하는 툴이 표준 개발 환경에 포함되도록 하라.
툴의 도움없이 리팩토링을 수행하는 것은 지극히 위험하고 따분한 작업이다. 리팩토링을 수행하기 위해 필요한 최소한의 도구는 리팩토링 기능이 추가된 개발환경(예: 이클립스)과 최악의 경우 이전 상태로 되돌아 가기 위한 버전관리시스템(예: CVS)이다. 이러한 도구의 도움 없이 수작업으로 리팩토링 하는 것은 예상치 못한 버그를 만들어 낼 수 있으므로 피하는 것이 좋다.

2. 이름을 변경할 때는 반드시 코딩표준안을 참조하라.
이름 변경(Rename)은 단순하지만 가장 효과적인 리팩토링 방법이다. 개발자의 의도가 충분히 드러나도록 이름을 지어두는 것 만으로도 문제의 복잡성을 낮출 수 있다. 하지만 의미있는 이름에 대한 개발자의 생각이 서로 다르기 때문에, 자신이 선호하는 이름이 아니라고 해서 이름을 변경해 버리는 것은 팀 전체로 볼 때 오히려 혼란을 초래할 수 있다. 당신이 어떤 팀에 소속되어 일하고 있다면, 그 팀의 이름 작성 규칙을 반드시 숙지하고, 그 규칙이 허용하는 범위 안에서만 이름을 변경해야 한다.

3. 공개된 인터페이스를 변경할 경우 호환성 여부를 확인하라.
외부에서 참조하는 경우가 많고 버전까지 달라지는 경우라면 공개된 인터페이스에 대한 리팩토링을 신중하게 수행할 필요가 있다. 꼭 필요하다고 판단해서 메소드 명이나 파라미터를 변경했다면, 기존 시스템과의 호환성이 깨어지지 않도록 주의해야 한다. 호환성을 해치지 않기 위해서는 이전에 공개된 인터페이스와 그 구현을 미사용(Deprecated) 형태로 남겨둬야 하는데, 그런 API가 많아지면 유지보수가 힘들어진다. 따라서 공개 인터페이스는 이후의 확장이나 변경에 영향을 받지 않도록 초기 설계를 보다 신중하게 할 필요가 있다.

4. 마감일이 가까워 오면 리팩토링 시기를 미뤄라.
테스트 등을 통해 오류를 자동으로 검출해 낼 수 있다고 하더라도, 리팩토링으로 인해 발생한 오류를 수정할 시간이 필요해진다. 일주일 뒤에 중요한 보고회가 예정되어 있거나, 시스템 마감일이 가까워진 시점에서 리팩토링을 수행하는 것은 무모한 판단일 수 있다. 이럴 경우는 미진한 설계를 개선시키고자 하는 욕구를 잠시 억눌러 두고, 그 시간을 시스템 안정화를 위해 사용하는 것이 더 좋다.

5. 리팩토링을 포기하고 재작성하는 것이 옳을 때도 있다.
가끔 개발과 관련된 근거 문서도 없고, 어떤 것들이 제대로 동작하는 지를 확인할 수 있는 테스트 코드도 전혀 없고, 컴퓨터만이 겨우 해독해 낼 수 있는 특수한 스파게티 코드로 둘러싸여진 ‘괴물’과 같은 프로그램을 접할 때가 있다. 그런 코드를 리팩토링 하는 것은 설사 그것이 가능하다 하더라도 개발자란 직업을 포기하고 싶을 만큼의 강력한 스트레스를 유발하므로 피하는 것이 옳다. 그런 코드를 만나면 코드 작성자에게 전달되게끔 강력한 포스로 한바탕 욕을 퍼붙고 나서, 그로 인해 얻은 에너지를 토대로 처음부터 재작성할 결심을 굳히도록 하자.

각각의 서브 클래스에, 동일한 순서로 비슷한 단계를 행하지만 단계가 완전히 같지는 않은 두 메소드가 있다면,
그 단계를 동일한 시그너처를 가진 메소드로 만들어라.
이렇게 하면 원래의 두 메소드는 서로 같아지므로, 수퍼클래스로 올릴 수 있다.

동기
중복을 제거 할 수 있습니다.

절차
1. 빈 수퍼 클래스를 만들고 원래 클래스들이 이것을 상속하도록 한다.
2. Pull Up Filed, Pull Up Method, Pull Up Contruct Body들을 사용하여 공통 요소들을 옮긴다.
3. 옮길 때 마다 테스트를 한다.
4. 공통된 부분이 있다면 Extract Method를 사용한 뒤에 Pull Up Method를 사용할 수 있다.

예제
리팩터링 대상이 된 두 개의 클래스들
- AddController.java

less..

less..

- UpdateController.java

less..

less..

리팩터링
1. 상위 클래스를 만들고 각각의 클래스들이 그 클래스를 상속 받도록 한다.
Eclipse를 사용하신다면 리팩터링 대상이 된 클래스에서 Alt + Shift + T를 클릭하여 리팩터링 메뉴를 띄우고 Extract Super Class를 선택할 수 있습니다.

2. 상위 클래스의 이름을 설정하고 상위로 빼낼 멤버들을 선택합니다.

3. Eclipse의 리팩터링 기능을 사용하여 만들어진 클래스를 상속 받도록 수정 되었습니다.

4. 다른 클래스는 수동으로 상속 받고 있는 클래스를 수정해 주거나 상속 하도록 코드를 수정하고 공통 요소를 하나 둘 빼내거나 Pull Up XXX 리팩토링 기능을 사용하여 옮길 수 있습니다.

참조 : Refactoring

참조 : http://www.refactoring.com/catalog/introduceParameterObject.html

여러개의 파라미터를 가지는 메소드의 경우 그 일련의 파라미터들을 가지는 새로운 객체 타입을 받도록 변경할 수 있습니다.


Eclipse의 refactoring 기능 중에 저런 리팩터링을 지원하는 것이 없는지 찾아봤지만 못찾았습니다. 있으면 좋으련만...
http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg00188.html
http://download.eclipse.org/eclipse/downloads/drops/S-3.3M7-200705031400/eclipse-news-M7.html
위 글들을 보니 Eclipse3.3의 refactoring 기능에 추가해 줄 것 같습니다.

하나의 메소드 안에 뭉탱이로 들어가는 인자들이 있다면 그 인자들끼리 관계가 밀접할 수 있으며 해당 객체에서 따로 빼내는 것이 애플리케이션을 더 유연하게 만들 수 있습니다.

메소드에 넘겨줄 인자가 단순해집니다.

동기

클래스가 너무 많은 메소드와 데이터를 가지고 있어서 쉽게 이해할 수 없는 경우가 있다. 이때 데이터의 부분집합과 메소드의 부분집합이 몰려 다닌다면 새로운 클래스로 분리할 수 있다는 좋은 신호다.

절차

1. 클래스의 책임을 어떻게 나눌지를 결정하라.
2. 분리된 책임을 떠맡을 새로운 클래스를 만든다.
• 책임을 분리한 후 이전 클래스의 책임이 이름과 더 이상 맞지 않는다면, 이전 클래스의 이름을 변경한다.
3. 이전 클래스에서 새로 만든 클래스에 대한 링크를 만든다.
• 양방향 링크가 필요할지도 모른다. 그러나 필요해지기 전에는 새로 만든 클래스에서 이전 클래스로 링크를 만들지 마라.
4. 옮기고자 하는 각각의 필드에 대해 Move Field를 사용한다.
5. 각각의 필드를 옮길 때마다 컴파일, 테스트를 한다.
6. Move Method를 사용해서 이전 클래스에서 새로 만든 클래스로 메소드를 옮긴다. 저수준 메소드(호출하기 보다는 호출되는 메소드)부터 시작해서 짐점 고수준의 메소드에 적용한다.
7. 각각의 메소드를 옮길 때마다 컴파이르 테스트를 한다.
8. 각 클래스를 검토하고, 인터페이스를 줄인다.
• 양방향 링크를 가지고 있다면, 단바양 링크로 만들 수 있는지 알아본다.
9. 새로운 클래스를 공개할지 결정한다. 새로운 클래슬 공개하기로 결정했다면, 참조 객체로 드러낼지 또는 불변성 값 객체(immutable value object)로 드러낼지를 결정한다.

예제

닫기

닫기

위 예제 코드를 보시면 officeAreaCode와 officeNumber 데이타가 몰려 다니고 거기에 따른 getter와 setter들이 몰려 다니는 것을 볼 수 있습니다. 이것을 TelephoneNumber라는 class로 따로 뽑아내기 위해 먼저 TelephoneNumber 클래스를 만들고 Move Field를 사용합니다.

이클립스에서 클래스를 만들고 이동하고자 하는 필드를 선택하고 Alt + Shift + v 를 클릭하면 다음과 같은 팝업창이 뜨게 되고 이동시킬 클래슬 선택할 수 있다.


하지만 단순히 데이터만 옮겨 줄뿐 거기에 딸린 getter와 setter를 같이 옮겨 주지 않는 것은 조금 아쉬웠다. 이번에는 옮기고 싶은 것을 통째로 드래그를 해보았다. 그러나 메소드를 옮기는 일이 쉽지가 않은 듯하다.

결국 잘라내기 붙여넣기를 사용하여 아래와 같이 두개의 클래로 분리하였다.

닫기

닫기

닫기

동일한 일을 하는 메소드를 여러 서브클래스에서 가지고 있다면, 이 메소드를 수퍼클래스로 옮겨라.

동기

• 중복된 동작을 제거해야 하기 때문입니다. 한쪽은 바꿨는데 다른 쪽은 그대로 라면 수정하기도 번거롭고 나중에 버그가 될 가능성이 높을 것입니다.

Pull Up Method가 필요한 경우는 서브클래스에 있는 메소드가 수퍼클래스에 있는 메소드를 오버라이드하는데 여전히 같은 일을 하는 때입니다.
이 때 성사긴 것은 서브클래스의 메소드에서 수퍼클래스에 없는 메소드나 변수를 참조할 때입니다. 이 때는 메소드도 같이 일반화하거나 수퍼클래스에 추상 메소드를 만들 수 있습니다. (이럴 때 메소드의 시그너쳐를 변경하거나 위임 메소드(?)를 만들어야 할 지도 모른다고 합니다.)
비슷하지만 동일한 메소드가 아닐때는 Form Template Method를 사용할 수 있을지도 모릅니다.

절차

1. 메소드들을 조사해서 그것이 동일한지 확인한다.
• 만약 같은 일을 하지만 코드가 다른경우 메소드들 중 하나에 Substitute Algorithm을 사용하여 코드가 동일하게 만들어라.
  
2. 메소드가 서로 다른 시그너쳐를 가지고 있다면, 수퍼 클래스에서 사용하고 싶은 시그너처로 바꾼다.
3. 수퍼클래스에 새로운 메소드를 만들고, 메소드들 중 하나의 몸체를 새로운 메소드에 복사해서 적절히 수정한 후 컴파일한다.
• 그 메소드가 수퍼클래스에 없는 메소드를 호출한다면, 수퍼클래스에 추상 메소드를 만들어라.
• 수퍼클래스에 없는 필드를 사용한다면, Pull Up Field 또는 Self Encapsulate Field를 사용하고 추상 get메소드를 선언하여 사용하라.
  
4. 서브클래스 중 하나를 골라서 메소드를 삭제한다.
5. 컴파일, 테스트를 한다.
6. 수퍼 클래스 메소드만 남을 떄까지 서브클래 메소드를 삭제하고 테스트를 계속한다.
7. 필요한 타입을 수퍼클래스로 변경할 수 있는지 살펴보기 위해서 이 메소드의 호출부를 살펴본다.

예제

두 개의 서브클래스(RegularCustomer, PreferredCustomer)를 가진 Customer 클래스가 있다. 그리고 두 서브클래스에 있는 createBill 메소드는 둘다 다음과 같은 코드로 동일하다.

void createBill(Date date) {
   double chargeAmount = chatgeFor(lastBillDate, date);
   addBill(date, charge);
}


색칠 된 부분의 코드가 모두 중복되고 있지만 둘 중에 녹색으로 칠해진 chargeFor 메소드는 위로 복사해서 옮길 수가 없습니다. 클래스 몸체가 서브클래스마다 다르기 때문입니다. 이때는 수퍼클래스에 추상 메소드로 선언합니다.


addBill 메소드는 수퍼클래스로 옮겼고 chargeFor 메소드는 수퍼클래스에 추상 메소드로 선언했습니다.(UML 표기상 추상 메소드는 이탤릭체로 표기합니다. 그리고 추상 메소드를 가진 클래스는 추상 클래스가 되기 때문에 클래스 이름도 이탤릭체로 표기했습니다.)

그룹으로 함꼐 묶을 수 있는 코드 조각이 있으면 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.

동기

지나치게 긴 메소드나 주석이 필요한 코드를 보면 그 부분을 하나의 메소드로 뽑는다.(Martin Fowler 曰).

1. 메소드가 잘게 쪼개져 있을 때 다른 곳에서 사용하기 좋다.
2. High-level의 메소드를 보면 주석을 읽는 것 같은 느낌이 들도록 할 수 있다.
3. 오버라이드 하는 것도 훨씬 쉽다.

작은 메소드들은 작명을 잘했을 때 그 진가를 드러내므로 이름을 잘 짓도록 하자.

절차

1. 메소드를 새로 만들고, 무엇을 하는지를 나타내도록 이름을 정한다.
2. 원래 메소드에서 뽑아내고자 했던 부분을 복사하여 새 메소드로 옮긴다.
3. 원래 메소드에서 사용되고 있는 지역변수가 뽑아낸 코드에 있는지 확인한다. 있으면 새로운 메소드의 임시변수로 선언한다.
4. 뽑아낸 코드 안에서 지역변수의 값이 변화는지 확인한다. 만약에 하나의 지역변수만 수정 된다면, 뽑아낸 코드를 질의(query)로 보고, 수정된 결과를 관련된 변수에 대입할 수 있는지 본다. 이렇게 하는 것이 이상하거나, 값이 수정되는 지역변수가 두개 이상 있다면 쉽게 메소드로 추출할 수 없는 경우이다. 이럴 때는 Split Temporary Variable을 사용한 다음 다시 시도해야 한다. 임시변수는 Replace Temp with Query로 제거할 수 있다.
5. 뽑아낸 코드에서 읽기만 하는 코드는 파라미터로 넘긴다.
6. 지역변수와 관련된 사항을 다룬 후에는 컴파일을 한다.
7. 원래 메소드에서 새로 만든 메소드를 호출하도록 바꾼다.
8. 컴파일과 테스트를 한다.

예제 : 지역변수가 없는 경우
위 코드에서 처음에 수정할 부분은 노란색으로 표시된 부분입니다. 매우 단순한 경우이기 때문에 잘라서 새로운 메소드로 붙여넣고 저 노란 부분에서 새로운 메소드를 호출하면 되겠습니다.

이클립스에서 리팩토링 할 부분을 드래그 한 상태에서 Alt + Shift + m 을 클릭합니다. 그리고 새로운 메소드의 이름을 적어 줍니다.
그리고 OK 버튼을 클릭하면...
짠... 멋지게 처리해 주는 군요.. 주석만 빼고. ^^; 주석은 Ctrl + d (행삭제)를 사용하여 지워줍시다.

예제 : 지역변수가 포함되어 있는 경우

지역변수가 옮겨질 코드에 들어있는 경우 중에 가장 쉬운 경우가 바로 그 지역변수를 읽기만 하는 경우입니다.  이런 경우에는 변수를 파라미터로 넘겨주면 됩니다.


이번에는 저 노란 부분을 메소드로 뽑아 낼 것입니다. 보아하니 _name이라는 변수와 outstanding이라는 변수를 사용하고 있는데 outstanding만 지역변수고 _name은 필드네요. 따라서 outstanding만 넘겨주면 되겠습니다. 메소드  이름은 printDetails로 하는군요. 이번에도 뽑아내고 싶은 부분을 드래그 하고 Alt + Shift + m ...와오..


똑똑한 이클립스... 파라미터가 필요한 줄 알고.. 그것도 딱 지역변수만.. 아 정말 똑똑하네요. 역시 OK만 누르면..


대단합니다. 이클립스.

예제 : 지역변수에 다른 값을 여러 번 대입하는 경우 (마지막입니다. :)

이 경우는 복잡한데 이런 경우 중 임시변수에 대해서만 생각을 해봅니다. (파라미터에 다른 값을 대입하는 코드가 있다면 즉시 Remove Assignments to Parameters를 적용해야 한다.)만약에 그 임시변수가 뽑아내는 코드에서만 사용이 된다면 뽑아낸 코드로 그냥 그 임시변수까지 이동하면 되겠습니다. 하지만 그 임시변수가 뽑아내는 코드 밖에서도 사용이 된다면 뽑아낸 코드에서 그 값을 리턴해 주어야 합니다.
노란 부분을 보시면 each라는 임시변수는 뽑아내게 될 코드 안에서만 사용되는 것을 볼 수 있습니다. 그렇기 때문에 그냥 이동 시키면 되겠지요

위에 보이는 노란 부분이 뽑아 낼 부분입니다. 저 중에 each는 노란 부분에서만 쓰이기 때문에 당연히 그냥 빼내는 메소드로 이동하면 되겠습니다. 하지만 문제는 outstanding인데 이 변수가 printDetails 메소드에서 사용되고 있습니다. 따라서 위의 코드에서 계산 부분의 코드를 뽑아내고 outstaning의 값을 리턴하도록 합니다.

이번에는 이클립스의 덕을 잘 못보겠더군요.

임시변수가 너무 많아 코드를 뽑아내기 어려울 때는 Replace Temp with Query를 사용하여 임시변수를 줄이고 어떻게 해봐도 여전히 난처할 때는 Replace Method with Method Object를 사용한다. 이 리팩토링은 임시변수가 얼마나 많든, 그리고 뭘 하든 상관하지 않는다.

알고리즘을 보다 명환한 것으로 바꾸고 싶을 때는, 메소드의 몸체를 새로운 알고리즘으로 바꾼다.

위 코드를 보시면 people이라는 문자열 배열안에 Don, John, Kent라는 이름이 있는지 확인하고 만약에 있다면 해당하는 이름을 반환하는 메소드 입니다. 이것을 좀더 명확하게 표현하자면 아래와 같이 변경할 수 있습니다.


동기

어떤 것을 할 때 여러가지 방법이 있다면 그 중에 쉬운 것이 있다면 그것을 선택할 것입니다. 알고리즘도 마찬가지로 여러가지 방법 중에 좀더 명확한 방법을 선택하여야 합니다. 이 작업을 할 때는 가능한 많이 메소드를 분해해 두어야 합니다. 크고 복잡한 알고리즘을 바꾸는 것은 어렵기 때문이죠.

절차

1. 대체 알고리즘을 준비한다. 적용하여 컴파일한다.
2. 알고리즘을 테스트한다. 만약 결과가 같다면 작업은 끝난 것이다.
3. 만약 결과가 같지 않다면, 테스트에서 비교하기 위해 예전의 알고리즘을 사용하여 디버깅한다.
• 예전 알고리즘과 새 알고리즘에 대해 각각의 테스트 케이스를 실행시키고 두 결과를 본다. 이것은 어떤 테스트 케이스가 어떻게 문제를 일으키는지 찾는 데에 도움을 줄 것이다.
  

긴 메소드(Long Method)

최적의 상태로 가장 오래 살아 남는 객체 프로그램은 메소드가 짧다. 인디렉션(indirection)의 이점은 모두 짧은 메소드에 의해 제공되는 것이다.

인디렉션이란?

닫기

닫기

원문에는 더 많은 내용이 나와있지만 간략히 요약하면 인디렉션이란 실제 값 자체가 아닌 그것을 참조하는 다른 이름을 사용하는 기능을 말한다는 것 같다. 이렇게 함으로써 프록시와 dynamic dispatch도 가능한 듯하다.

책의 82쪽에는 이런말이 있다.


프로그래밍 초창기에는 서브루틴을 호출 할 때 오버헤드가 있어서 짧은 메소드 사용을 꺼려 했다고 한다. 그러나 요즘엔 프로세스 내부 호출(in-process call)로 인런 오버헤드가 상당부분 제거됐다고 한다. 하지만 서브루틴이 무엇인지 보려면 일단 그 부분으로 가보야 하기 때문에 사람들에게는 여전히 오버헤드가 존재한다. 그 오버헤드를 줄이기 위해서는 메소드의 이름을 잘 지어야 한다.

대부분의 경우 메소드의 길이를 줄이기 위해서는 Extract Method를 사용한다. 메소드에 파라미터와 임시변수가 많으면 메소드를 추출하기가 어렵다.

• 임시변수를 줄이기 위해서는 Replace Temp with Query를 사용할 수 있고
• 긴 파라미터 리스트는 Introduce Parameter Object와 Preserve Whole Object로 짧게 할 수 있다.
• 그럼에도 여전히 임시변수와 파라미터가 많다면 Replace Method with Method Object를 사용한다.

뽑아낼 코드 덩어리 식별 방법으로는 주석을 찾는 것이 좋다. 그리고 조건문과 루프 또한 추출이 필요하다는 신호를 준다. 조건식을 다루지 위해서는 Decompose Conditional을 사용한다. 루프의 경우는 Extract Method에서 예제로 다루고 있다.