리팩토링(Refactoring)(リファクタリング)에 대해

リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。いくつかのリファクタリング手法の総称としても使われる。十分に確立された技術とはいえず、「リファクタリング」の語にも厳密な定義があるわけではない。

리팩토링 (refactoring)은 컴퓨터 프로그래밍 에서 프로그램 외부에서 본 동작을 바꾸지 않고 소스 코드 의 내부 구조를 정리하는 것을 말한다.

 

リファクタリング登場の経緯と目的

리팩토링의 등장 경위와 목적

  

リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手を触れるべきではないと言われていた。下手に手を加えて動作が変わってしまうと、それに伴って関連する部分にも修正が加えられ、やがて修正はプロジェクト全体に波及し対処しきれなくなるかも知れない。またソフトウェアテストを十分に行い正常な動作が確認されたとしても、そのプログラムをわずかでも改変すれば、バグ (欠陥) が見つかったときに改変があったプログラムを疑わなければならない。

しかし、プログラムには必ず変更があり、プログラムはどうしてもつぎはぎだらけになることは避けられない。仕様が開発開始時から確定していることは少なく、開発をしている間にもソフトウェアに対する要求は日々変わり続けており、ソフトウェアには常に仕様変更に対応できる柔軟さが求められる。また、いくら厳密に設計しても実際に動作させないと分からない部分も多く、完璧な設計を行うことは不可能である。変更が必要になったときに、二度と手を触れられないほど煩雑になったソースコードを修正することは困難で、プログラマにも非常に勇気が要求される作業になる。

そこで、Smalltalkプログラマなどの間で、常日頃からプログラムを整理し仕様変更にも対応できる整理されたプログラムを書いていく考え方が生まれた。この過程では、ウォード・カニンガム、ケント・ベック、ラルフ・ジョンソン（GoFの一人）などの人々が大きな役割を果たした。この手法がリファクタリングと呼ばれている。またリファクタリングはプログラムの全容を捉えるためにも効果的である。バグが見つかったときも、ソースコードが整理されているので修正しやすい。プログラマとしても、普段から修正しているコードにまた手を入れるだけなので、修正にも積極的になれる。また設計者も設計ミスによる心残りをなくすことができる。設計の代用にもなる、とする意見もあり、事前設計を非常に簡素化する役目も持つ。

リファクタリングはオブジェクト指向設計と深くかかわっている。リファクタリングのほとんどはオブジェクト指向の性質に沿ったものであり、オブジェクト指向のコードの再利用性を最大限に引き出すことができる。オブジェクト指向プログラミングを行える言語であれば、プログラミング言語の種類にかかわらずリファクタリングを適用できる。

リファクタリングを行うことで、開発が停滞してしまうのではないか、という心配をされることも多い。リファクタリングを行っている間は、何の機能追加も行われない。しかしたいていの場合は、設計が向上することで機能追加やバグフィックスをしやすくなり、開発のスピードは安定するばかりか、速くなることもある。

리팩토링이 등장하기 전에는 일단 정상적인 작동한 프로그램은 다시 손대서는 안되는 것으로 알려져 있었다. 어설프게 손을 대어 작동이 바뀌어 버리면, 이에 따라 다른 관련 부분에도 수정을 가해야해 결국 수정은 프로젝트 전체에 영향을 미치게 되어 그에 대해 대처할 수 없게 될지도 모른다. 또한 소프트웨어 테스트를 충분히 하여 정상적인 작동이 확인 된 경우에도 프로그램을 조금이라도 변경한다가 버그(결함)이 발생할 수도 있다.

그러나 프로그램에는 반드시 변화가 있고 프로그램은 어떻게 짜던 이리저리 수정되는 것은 불가피하다. 사양이 개발 시작부터 이미 확정된 프로젝트는 현실적으로 매우 적고, 개발을 하고 있는 동안에도 소프트웨어에 대한 요구사항은 계속해서 변화하고 있으며, 소프트웨어는 항상 사양 변경에 대응할 수 있는 유연성이 요구된다. 또한 아무리 엄격하게 디자인해서 실제로 작동시키지 않으면 모르는 부분도 많고, 완벽한 설계를 실시하는 것은 불가능하다. 변화가 필요할 때 다시 손을 대지 못할 정도로 복잡하게 된 소스 코드를 수정하는 것은 곤란하고, 프로그래머도 매우 용기가 요구되는 작업이다.

그래서 Smalltalk 프로그래머 사이에서 평소부터 프로그램을 정리하며, 사양 변경에도 대응할 수 있는 정리된 프로그램을 써가는 생각이 하게되었다. 이 과정에서는 워드 커닝햄 , 켄트 벡 , 랄프 존슨 ( GoF 의 한 명) 등의 사람들이 큰 역할을 했다. 이 기술을 리팩토링이라고 한다. 또한 리팩토링은 프로그램의 전체를 파악하기에도 효과적이다. 버그가 발견 된 경우에도 소스 코드가 정리되어 있기 때문에 수정하기 쉽다. 또한 설계자도 설계 오류로 인한 아쉬움을 없앨 수 있다. 설계의 한 종류로 보는 것이 어떻냐는 의견도 있을 정도로 사전 설계를 매우 단순화하는 역할도 가진다.

리팩토링은 객체 지향 설계와 깊이 관련되어있다. 리팩토링의 대부분은 객체 지향의 성격에 따른 것이며, 객체 지향 코드 재사용 성을 극대화 할 수 있다. 객체 지향 프로그래밍을 할 수 있는 언어라면 프로그래밍 언어의 종류에 관계없이 리팩토링을 적용 할 수 있다.

리팩토링을 실시하는 것으로, 개발이 정체되어 버리는 것은 아닌가하는 걱정을 하는 경우도 많다. 리팩토링을 수행하는 동안은 아무런 기능 추가도 행해지지 않는다. 그러나 대부분의 경우는 설계가 향상하는 것으로 기능 추가 및 버그 수정을 쉽고, 개발 속도가 안정 될 뿐만 아니라, 오히려 개발속도가 더 빨라질 수도 있다.

 

主なリファクタリング

주된 리팩토링의 요소

 

∙ メソッドを抽出する

長すぎるメソッドは再利用性が低い。メソッドを抽出、細分化することで再利用性が高まり、呼び出し側メソッドの記述も読みやすくなる。処理の重複も減る。

∙ 메소드 추출

너무 긴 메소드는 재사용 성이 낮다. 메소드를 추출, 세분화함으로써 재사용성을 높이고, 호출 메소드의 설명도 읽기 쉽게 된다. 메소드 처리의 중복도 줄어든다.

 

∙ 双方向関連を単方向へ変更する

不要な参照は管理のための手間を増やし、オブジェクトの破棄を失敗させる。不要になった関連は消す。

∙ 양방향 연관을 단방향으로 변경

불필요한 참조는 관리를 위한 시간을 늘리고, 객체의 파기를 실패시킨다. 불필요하게 된 관련(참조)은 끈다.

 

∙ クラスの抽出

大きくなりすぎたクラスを分割する。クラスを小さくすることで、そのクラスの役目を明確にできる。

∙ 클래스 추출

너무 커질 클래스를 분할한다. 클래스를 작게 하는 것으로 그 클래스의 역할을 명확하게 할 수 있다.

 

switch文をポリモーフィズムに置き換える

switch文をポリモーフィズムに置き換えることで、新たな条件が追加されても分岐部分には変更の必要がなくなる。

∙ switch 문을 다형성으로 교체

switch 문을 다형성을 대체하면 새로운 조건이 추가 되어도 분기 부분에는 변경의 필요가 없어진다.

 

∙ メンバの移動

フィールドやメソッドが不適切なクラスにある場合、他のクラスとの余計な関連が増える。メンバを移動し、クラスの責任を整理する。

∙ 멤버의 이동

필드나 메소드가 잘못된 클래스의 경우 다른 클래스와의 불필요한 관련이 늘어난다. 멤버를 이동하고 클래스의 책임을 정리한다.

 

∙ 継承を委譲に置き換える

継承では基底クラスのすべてのメンバを、サブクラスに許さなければならない。基底クラスの一部だけの機能を利用する場合は、継承の代わりに委譲を使う。

∙ 상속을 위임로 대체

상속은 기본 클래스의 모든 멤버를 서브 클래스로 허용해야한다. 기본 클래스의 일부만 기능을 사용할 경우 상속 대신 위임을 사용한다.

 

∙ ダウンキャストをカプセル化する

ダウンキャストは互換性のない型に変換してしまう可能性があるが、それをコンパイル時に察知することは出来ない。総称型（テンプレート）がない言語では、カプセル化してクライアント側にダウンキャストの手間を減らすようにする。コレクションクラスなどでは特に必要。

∙ 다운 캐스트를 캡슐화 한다.

다운 캐스트는 호환되지 않는 형식으로 변환 할 가능성이 있지만, 그것을 컴파일 시에 감지 할 수 없다. 템플릿이 없는 언어에서는 캡슐화하여 클라이언트 측에 다운 캐스트의 수고를 줄일 수 있도록 한다. 컬렉션 클래스 등이 특히 필요하다.

 

∙ コンストラクタをFactory Methodに置き換える

コンストラクタはそのクラスのオブジェクトを返すことしか出来ない。Factory Methodの導入によって柔軟なインスタンス化が可能になる。

∙ 생성자를 Factory Method로 대체한다.

생성자는 클래스의 객체를 반환 밖에 할 수 없다. Factory Method의 도입에 따라 유연한 인스턴스화가 가능하게 된다.

  

∙ 引数オブジェクトの導入

たびたび一緒に受け渡しされる複数の値は、オブジェクトとしてまとめたほうが分かりやすい。

∙ 인수 오브젝트의 도입

빈번히 함께 사용되는 값은 오브젝트로 정리하는 것이 구분하기 쉽다.

 

∙ クラス・メソッド・属性の名称を変更する

クラス名・メソッド名・属性名は、そのクラスやメソッドの役割を正確に説明したものにする必要がある。名称が不正確なものであったり、曖昧なものである時は名称の変更が行なわれる。しばしば、当初は適切であった名称も、他のリファクタリング実行後に適切で無くなることがある。このときは、続けて名称変更のリファクタリングも行なわれる（⇒命名規則 (プログラミング)）。

∙ 클래스 메소드 속성의 이름을 변경

클래스 명 · 메소드 명 · 속성의 이름은 그 클래스나 메소드의 역할을 정확하게 설명하는 것으로 할 필요가 있다. 명칭이 잘못된 것이거나 애매한 것일 경우에는 명칭을 변경한다.