Agile India 2012という講演兼勉強会の場で、Daniel Brolund氏がMikadoメソッドについてのプレゼンテーションを行った。これは酷いレガシーコードをリファクタリングして新たなゴールを目指していかなければならないアジャイルチームのためのシンプルな手法の提案である。
レガシーアプリケーションに簡単な変更を加える場合、この変更関連の部分を壊す(コンパイルエラーや受け入れテストを失敗させる(もし受け入れテストがあれば!)など)ことから始めることが多い。これらを修正してまた他の部分を壊し、そしてもし手に負えなくなったら元に戻してもう一度やり直すということを繰り返すのである。
Mikadoメソッドはシンプルな解決策を提案する。各変更において、変更したことによってエラーになった依存部分を見つけたら、実際に変更する前にしなければならないことと共に、これらのエラーを表現するグラフを作成する。次に、変更を元に戻してグラフのリーフノードを探してそのエラーを修正し、別の問題の原因になるかどうか確認してみる。もしそうなっていれば、このプロセスを繰り返し、変更するために何が必要かを表すグラフを描いていく。そして完全に変更を元に戻し、別のリーフノードで同じことを行う。
コードを元に戻した時に、振り出しに戻ってしまったように感じるかもしれないがそうではない。実際には、初めよりもより多くの情報を手にしているのだ。また、コンパイルされていない大量のコードをかかえるのではなく、常にコンパイルされ(そしてテストがあればテストの通った!)コードを扱うことになり、IDEのリファクタリングツールを使うことが可能である。リーフノードの問題は毎回修正され、別のエラーにつながることはない。全てのリーフノードがグリーンになれば、その基のノードに取り掛かることができ、最終的には本来の変更を完了することができる。これはコードが徐々にチェックインされることを意味しており、別のブランチを作らずにメインブランチで直接作業を行うことができる。
巨大なアプリケーションだと変更するものが多すぎて、グラフが手に負えなくなると思うかもしれないが、Daniel氏によれば、グラフのサイズはコードのサイズに比例しないという。グラフの主目的はゴールを明確にすることである。一度に多くのことを試すのではなく、最初に決めたゴールへ向けて作業を行うのだ。
Daniel氏は、複数の顧客をサポートするためのリファクタリングが必要なシンプルなJavaアプリケーションを題材にしてデモを行った。続いて簡単なワークショップがあり、参加者は同じ事を行った。ほとんどの課題はGithubからダウンロードでき、またEブックも公開されている。またInfoQに以前投稿された大規模リファクタリングに関する記事に興味があればこちらを参照して欲しい。