冗長なソースコードを削除したり、さまざまな機能や役割を詰め込みすぎた1つの部品を、それぞれが単一の役割だけを担う、より小さな複数の部品に分割、整理したりする作業がリファクタリングの例だ。

　設計から公開までの小規模なサイクルを素早く繰り返すことで、質の高いアプリケーションを継続的に提供することを目指す手法「エクストリームプログラミング」は、継続的なリファクタリングに重きを置いている。理論上、リファクタリングを重ねるたびにソースコードは洗練されることになる。

　リファクタリング後のソースコードは、他の開発者が容易に理解できる状態であることが望ましい。これによって、修正の影響が怖くて誰も変更したがらないような複雑なソースコードを、皆が安心して自力で更新できる見通しの良いソースコードに変えることができる。

リファクタリングのメリット

メリット1．開発者の判断で進めてよい場合がある

　リライトのような大規模なソースコードの変更にはチームの合意が必要になる。これに対して、リファクタリングのような小規模の修正であれば、より少ない関係者との合意で済むことが一般的だ。開発者の判断で進められる場合もある。

メリット2．アーキテクチャを選ばない

　モノリシック（巨大な一枚岩的）な構成から大規模な分散システムまで、どのようなアーキテクチャでもリファクタリングは可能だ。

メリット3．リソースを効率的に活用できる

　リライトの場合、古いアプリケーションの保守と新しいアプリケーションの開発が並行して進むため、人員や予算などのリソースが二重で必要にになる。一方のリファクタリングは、現在稼働している単一のコードベース（ソースコード群）を直接改善する。このような進め方は、新機能の開発と並行して、効率的にソースコードの改善を進めることを可能にする。

メリット3．費用を抑えやすい

　リファクタリングはコードベース全体ではなく、必要な部分に限定して修正を進められる。作業範囲を絞って段階的に修正できるため、一度に大きな費用がかかりにくい。

リファクタリングのデメリット

デメリット1．効果が限定的

　リファクタリングはソースコードの一部を改善できるが、根本的なアーキテクチャの問題は解決できない。「Visual Basic 6.0」（1998年公開）のような古いプログラミング言語で書かれたソースコードは、リファクタリング後も実装言語はVisual Basic 6.0のままだ。

デメリット2．新機能の追加には直結しない

　リファクタリングは現状のアーキテクチャやソースコードを維持、改善する手法だ。そのため、リファクタリング自体がアプリケーションに新機能をもたらすわけではない。

デメリット3．スキルが求められる

　開発者個人のスキル、変更することに対する勇気に加え、チーム全体で規律ある開発をすることがリファクタリングには必要だ。複雑なリファクタリングパターンになじみがない開発者は、作業への着手をためらう可能性がある。

　リファクタリングの目的は、「外部から見た動作を変えずに、内部の構造を改善する」ことにある。機能などの要素単位で動作を検証する「単体テスト」は、この点を保証してくれるテスト手段だ。単体テストを実施できる体制が整っていなければ、開発者は時として、リファクタリングによって意図せずにアプリケーションの機能を変更してしまう可能性におびえることになる。これが、リファクタリング経験が浅い開発者が、「リファクタリングはリスクがある、開発の阻害要因だ」と考えがちな原因だ。

デメリット4．ソースコードの構成要素が増える可能性がある

　リファクタリングは、1つの巨大で複雑な機能を、より小さな単一の役割を持つ部品群に分割していく作業だ。各部品の役割を明確かつシンプルにすることで、アプリケーション全体としての見通しが良くなる。一方で、この作業は結果として、ファイルや関数（機能）を増やしてしまう場合がある。

　アプリケーションのアーキテクチャ自体に問題がある場合、ソースコードをきれいにするだけでは限界がある。そうなれば抜本的な解決策、つまりリライトを検討すべき時期だ。

　次回はリライトのメリットとデメリットを紹介した上で、どちらの手法が適切なのかを見極めるポイントを解説する。