한빛출판네트워크

제공 : 한빛 네트워크
저자 : Marcelo Giorgi
역자 : 백기선
원문 : Refactoring in Eclipse 3.2

[이전 기사 보기] Eclipse 3.2를 활용한 리팩토링 - (1)

리팩토링 히스토리(Refactoring history)

유익한 정보 제공의 목적으로 Eclipse 3.2에서는 리팩토링 히스토리(History)를 보여주는 새로운 창을 제공해 줍니다. 리팩토링 히스토리는 리팩토링 기능과 관련된 행위들의 자세한 히스토그램을 보여줍니다. 이것은 우리가 인식하지 못한 코드 수정으로 인해 발생한 문제를 찾아내는데 도움을 줍니다.


[그림 4]

리팩터 스크립트(Refactor scripts)

새로운 버전의 Eclipse에 추가된 기능 중 하나로 Script Refactor가 있습니다. “script refactor”를 사용하여 어떤 workspace 에서도 원자적인 반영(연속적으로 모두 처리되거나 전부 처리하지 말아야 할 것)에 기반한 복잡한 리팩토링을 재사용 할 수 있습니다.


[그림 5]

[그림 5]에서 Refactor Script 마법사는 스크립트에 추가할 액션들을 선택할 수 있고 스크립트의 이름을 지정할 수 있는 화면을 보여줍니다.

이렇게 생성한 파일을 workspace에 적용하기 위해서는 Refactor → Apply Script... 를 선택한 뒤 적당한 파일을 선택하면 됩니다.

이것은 특정 저장소에 수정된 내용을 커밋할 필요 없이 견고한 리팩토링을 수행할 수 있기 때문에 매우 강력한 도구입니다. 따라서 일관성이 유지되지 않는 프로젝트에서는 다른 사람들이 변경을 동기화 해야 하기 때문에 추천하지 않습니다.

변수의 이름도 적당하게 바꿔주는 Rename Type

이제는 더 이상 클래스의 이름을 바꿀 때 예전 클래스 이름을 바탕으로 만든 레퍼런스 변수 이름에 관한 일관성을 걱정할 필요 없습니다.

public class Point {
	public double	x, y
	public class Point() {
…
	}
…
}

public class Cube {
	public Point point, point2, point3, point4;
	public class Cube() {
…
	}
…
}

예전 버전의 Eclipse 에서는 Point 클래스의 이름을 Vertex로 바꾸면 Cube 클래스는 다음과 같이 바뀝니다.

public class Cube {
	public Vertex point, point2, point3, point4;
	public class Cube() {
…
	}
…
}

객체가 참조하는 클래스가 무엇인지에 대한 즉각적인 단서를 제공하기 위해서는 인스턴스 변수의 이름이 클래스의 이름과 연관되는 것이 적절할 것입니다. 이러한 리팩토링을 Rename Type 마법사의 “Update similarly named variables and methods”를 사용하여 할 수 있습니다. 이것을 사용했을 때 결과는 다음과 같습니다.

public class Cube {
	public Vertex vertex, vertex2, vertex3, vertex4;
	public class Cube() {
…
	}
…
}

하위 패키지 이름 바꾸기

이전의Eclipse 버젼에서는 하위 패키지를 가지고 있는 패키지의 이름을 변경하면 하위 패키지는 변경이 되지 않았습니다. 예를 들어 [그림 6]과 [그림 7]을 보시면 uy.edu.vieg.graph 패키지를 uy.edu.vieg.treegraph 로 바꿨습니다. 하지만 uy.edu.vieg.graph 패키지의 하위 패키지인 uy.edu.vieg.graph.view는 변경되지 않았습니다.


[그림 6]


[그림 7]

예상하셨겠지만 Eclipse 3.2에서는 Rename Type 창에서 Rename subpackages 체크박스에 체크를 하면, [그림 8]에 보이는 것처럼 하위 패키지 명도 변경되게 할 수 있습니다.


[그림 8]

리팩토링 변화에 따른 JAR 파일 바꾸기(Migrate)

보통 프로젝트가 커지게 되면 서로 종속성을 가지는 조그만 하위 프로젝트로 나누게 됩니다. 그렇게 하기 위한 방법 중 하나로 프로젝트가 필요로 하는 관련된 정보들을 포함하는 JAR 파일을 사용하는 것입니다.

하지만 기능들을 리팩토링 하면 프로젝트 버전들 사이에 불일치가 발생하게 됩니다. 따라서 개발자는 전혀 모르게(transparent) 코드의 변화를 리팩토링 된 새 버전의 JAR 파일로 예전 버전의 JAR파일을 바꿔주는 Eclipse의 새 기능을 자세히 살펴 봐야 합니다.


[그림 9]

Navigator View 에서 File > Export를 선택하고 JAR Export 마법사 팝업에서 JAR 파일을 클릭합니다. 위에서 언급한 기능을 사용하려면 “Export refactoring for checked projects.” 를 반드시 체크해야 합니다(그림 9).

[그림 9] 마법사 화면에 보이는 녹색 링크 “Select refactorings…”를 사용하여 파일을 변경 할 때 적용할 리팩토링을 선택할 수 있습니다.


[그림 10]

생성한 JAR파일을 받아오기(import) 위해서는 타겟 프로젝트에 있는 예전 버전의 JAR파일을 선택하고 Build Path > Migrate JAR File…를 사용해야 합니다. JAR파일을 선택하지 않았다면 Refactor > Migrate JAR File…를 사용합니다.

결론

리팩토링은 소프트웨어 개발에서 매우 중요한 작업인데도 그것의 ROI(Return On Investment) 이득이 숨어있기 때문에 자주 경시됩니다. 언제 리팩토링이 필요한가는 절대적으로 여러분이 진행하고 있는 프로젝트의 구조와 기능에 달려있습니다. 하지만 언제 그리고 어디에 리팩토링이 필요한지를 알려주는 기술들이 있습니다. 그 예로 유지보수 하기 힘든 소스 코드를 쉽게 찾아주는 코드 메트릭스(code metrics) 같은 것이 있습니다. Java 기반의 IDE로 가장 널리 사용하고 있는 Eclipse는 3.2(코드명 Callisto)버전에 매우 유용한 리팩토링 기능을 포함하고 있습니다. 이 기능은 여러 개발자들이 리팩토링을 보다 쉽게 할 수 있도록 하는 매우 중요한 개선 사항입니다.

---

역자 백기선님은 AJN(http://agilejava.net)에서 자바 관련 스터디를 하고 있는 착하고 조용하며 점잖은 대학생입니다. 요즘은 특히 Spring과 Hibernate 같은 오픈소스 프레임워크를 공부하고 있습니다. 공부한 내용들은 블로그(http://whiteship.tistory.com)에 간단하게 정리하고 있으며 장래 희망은 행복한 개발자입니다.