リファクタリングとは、コードの外的振る舞いを変えずに内部構造を改善するというやり方でソフトウェアシステムを変更するプロセスのことだ。すでに書かれたコードを改善するという考え方は、ほとんどのアジャイルチームで高く評価されている。やはり、継続的改善はアジャイルチームが追い求めるものだ。だが、既存のコードを改善するのには時間もお金もかかる。それだけの価値はあるのだろうか？
リファクタリングには次のようなコストがかかる。
- リファクタリングするコスト
- 変更をテストするコスト
- テストやドキュメントを更新するコスト
ユニットテストやテストハーネスが基準以下だと、システムに新たなバグをもたらすリスクもある。XPプロジェクトできちんとしたユニットテストがあれば、こうしたリスクは低いだろう。一方、リファクタリングによってもたらされる利点もいくつかある。
- 新機能を追加してもシステム構造が破綻することがなくなる
- システムの理解が改善する
- テストしやすくなる
- バグが見つけやすくなり、バグを分離、修正しやすくなる
リファクタリングの決断に影響を及ぼすパラメータとは何だろうか？
リファクタリングの金銭的なメリットを示すのに複雑な数式はいらないとJohn Virgolino氏は言う。
複雑なビジネス分析をする必要はありません。簡単に考えましょう。リファクタリングにかかる時間に、1時間もしくは1日当たりの費用をかけるのです。$60000 給料 x 1.25 = $75000 直接コスト
$75000 コスト / 12か月 / 22作業日 = $297.61 （1日当たりのコスト）
さて、リファクタリングに要する日数 3日 x $297 = $891 リファクタリングコスト（これがあなたの投資になる）
次回のコード変更時、1回目のリファクタリングをせずに作業すると5日かかり（5 x $297 = $1485）、リファクタリングしたコードで作業すると1日かかる（1 x $297 = $297）とする。
$1485 - $297 = $1188 （節約できたコスト）- $891 （初期投資）= $297.00 全体で節約できたコスト
この時点ですでに投資の元はとれています。さらに節約するのはたやすいことで、別のプロダクト、プロジェクト、ドキュメント、請求可能な仕事に対する生産性向上にも利用できます。
Simon Johnson氏は同じように定量的な分析を行って、リファクタリングを正当化するにはリファクタリング後の生産性を一定の割合増加させる必要があると言う。Simon氏によると、
リファクタリングが銀行に預金するよりもすぐれた投資になるには、生産性を5-8%かそれ以上改善する必要があります。これはかなりの要求で、実際に達成できるかは疑わしいと思います。もし機会コストが「口座B」に示したよりもずっと高いのなら、新機能や欠陥削減手法といった別のものにお金をかけた方がよいでしょう。
コストの他にも、リファクタリングが実行可能な戦略になり得ない理由がある。
Mark Needham氏は締切の厳しいプロジェクト事例を引用しつつ、リファクタリングのジレンマについて述べている。そんな時にリファクタリングを始めても、チームは何らメリットを感じないだろう。Mark氏はこう言っている。リファクタリングにはいくつものメリットがあるが、将来コードのメンテナンスがやりやすくなるからといって納期を遅らせるというのはほとんど見たことがない。
John氏もまた、リファクタリングが許されないシナリオを紹介した。
一般的に言って、マネジメントにはリファクタリングすべきでない非常に理にかなった理由があるかもしれません。それはお金や時間とは無関係かもしれませんし、戦略的な決定であったり、あなたの知らない契約上の理由があるのかもしれません（例えば、政府系の仕事）。あなたが全体を把握しているのかも確かめておきましょう。私はこれまで、自分の時間を使ってリファクタリングするのだと言う人をたくさん見てきました。確かに、これは自分が作ったものに対する信念と愛情なのでしょうが、私はひとりでリファクタリングしたりはしません。ひとりでやって、他のチームメンバやプロジェクト全体に大損害を与えたプログラマを見たことがあります。
プロジェクトがあまりに短命でリファクタリングに投資できないこともあるとMark氏は言う。このようなプロジェクトのリファクタリングに投資するのは無駄だろう。
したがって、たとえリファクタリングするのに明確なメリットがあったとしても、リファクタリングするか否かは、その時々の状況でよく注意して決断する必要がある。大事なことはそのメリットをよく考えて、最高のビジネス価値を加えるよう努めることだ。