リファクタリングの定義は，外部的な動作機能に影響を与えずにプログラムの内部構造を変更することだ。主にプログラムの非機能属性を改善し，結果としてコードの可読性と保守性を改善する目的で実施される。しかしリファクタリングの規模が大きくなると，経験を積んだアジャイリストさえ不安を感じる ことが少なくない。アジャイルのコミュニティで，大規模なリファクタリングを扱う方法をいくつか検討した。
先日のディスカッションでは Andreas から，大規模なリファクタリングを行う上で考えられる３つの方法の中でどれが最善だろうか，という質問があった。彼の示した方法は，
- ビッグバン - 最終目標としての構造を定義して，その終の棲家にコードを持ち込む。
- 分割と統治 - 大きな泥団子を２つに割る。これを最後まで繰り返す ...
- 絞殺- クラスを絞め殺す。
ほとんどの参加者が，ビッグバンでの成功はまずあり得ない，という点では合意した。Aaron Digulla 氏からは，自身がそのキャリアを通じて絞殺型のアプローチを使い続けている，という意見があった。これは質の悪いコードを徐々に変形させて，テストハーネスを張りめぐらせたぴかぴかの新しいコードにする，というアイデアに基づく戦略で，小さな部分から徐々に始めるため通常はリスクが小さくすむという利点がある。また David Hall，Shane MacLaughlin の両氏は，プログラムの修正部分すべてに関して十分なテストを書き，小さく「分割して統治」することの重要性を強調した。完全な書き直しを方法として主張する者もいたが，InfoQ が以前のポストで取り上げたように，それもまた別の意味でのチャレンジだ。
Sibylle Peter 氏と Sven Ehrke 氏は，自ら実践する「評価の実施と大規模リファクタリングのマスタプラン の立案」というアプローチについて説明してくれた。リファクタリングの各ステップを，氏らは次のような手順で行っている。
- 分析：望まれる結果とその達成方法の定義。
- 実施：リファクタリング技法を適用したコード編集の実行。
- 安定：実施結果の永続性を確保する手法の適用。
大規模なリファクタリングにおいて今，注目を集めているアプローチがある。それが ミカドメソッド(Mikado Method) だ。このミカドメソッドの歴史は，Daniel Brolund，Ola Ellnestam 両氏の行った仕事に関係している。名称はミカドゲームに由来するものだ。このメソッドによれば，
コードの修正は，ちょうどミカドゲームのようなものです。コードベースを変更しようとするとき，本当に意図したとおり修正が実行できることはまずありません。コードの移動やクラスの抽出などなど，事前に行わなければならないことが数多くあるものです。最初のひとつかみでミカドを拾い上げられることは滅多にないですよね！ほとんどの場合，ミカドをリファクタできるまであれこれ移動を続けて，目標に到達するために地道な努力をしなければならないのです。
ミカドのアプローチは，目標を念頭に置くことから始まる。次にリファクタリングが必要なすべてのコードベースに対して，最終目標を起点とした依存関係グラフを作成する。そのステップは，ゴールに到達するための当面の必要条件を見つけ出すことから始まる。次にその依存関係にあるものを見つける。この作業を，必要条件や依存関係を持たない末端 (leaf) に到達するまで続けるのだ。これが多くの場合，リファクタリングを始めるのに最適な出発点になる。依存性グラフが完成すれば，その末端からゴールに向けて一歩ずつ戻っていく，というのが基本的な考え方である。
このアプローチでは「取り消し(Undo)」の重要性が強調されている。チームは変更を捨てて最初に戻ることを恐れてはいけない，というのだ。また過度の分析作業に陥ることを避け，まずは取り付きやすいステップから始めてその結果を理解する，という方法が推奨されている。ミカドメソッドについては，それを取り上げた書籍 の初稿が現在公開されている。
要するに，大規模なリファクタリングは困難な作業ではあるが，重要なのは開始点を見出すこと，小さなステップで作業を進めていくこと，この２つである。