リファクタリングとは？　- リファクタリングのジレンマ -

プログラムの機能やふるまいをかえずに、読みやすくしたり、共通化部分を集約したり、修正が容易になるようにソフトウェアを変更することをリファクタリングと呼びます。拡張、改変に伴う改版（リリース）を多く重ねたソフトウェアには避けて通れない作業です。

リファクタリングには、ソフトウェアを理解しやすくしたり、保守に伴う改変、確認作業が減ったりするメリットがありますが、リファクタリングによる欠陥混入が絶対起きないともいえません。共通化してはいけない部分を誤って共通化してしまったり、改変時に欠陥を混入してしまうからです。これがリファクタリングのジレンマです。

ソースコードのレベルでは、プログラムが意図どおり実行されることを確認するためのテスト用プログラムを書き、リファクタリングの前後でテスト用プログラムの実行結果がかわらないことを確認することでデグレードをある程度防ぐことができます（テスト用プログラムにも欠陥が混入する可能性があるので）。しかしながら、長年にわたって保守しているソースコードに対して新たにテスト用プログラムを書くコストやテスト用プログラムを網羅的に書くコストが非常に大きくなるため、現実的には困難であったり、コストに見合わなかったりする場合もあります。また、テスト用プログラム自身にもリファクタリングが必要になります。私自身も業務でテスト用プログラムを書きながらプログラムを書いたことがありますが、完全に固定（枯れて）されていたり、仕様変更がない部分や入出力が少ないパターンに集約できる場合には大きな効果を発しますが、変更される可能性が大きい部分や入出力のバリエーションが大きい部分にはなじみにくいというのが私の感触です。

長く開発を続けていたり、派生開発をしていたり、規模が大きいソフトウェアでは、リファクタリングによるメリット（理解容易性/保守性の向上）とリスク（デグレードの危険性）のジレンマに陥ることが特に多くなります。デグレードが与える損害が大きいソフトウェアの場合、なかなかリファクタリングに踏み切れず改版を重ねることが多いため、ソフトウェアが複雑になっていきます。欠陥により、損害賠償を請求されるようなシステム（ソフトウェア）の場合、リファクタリングの重要性は理解できても、既にちゃんと動いている部分への副作用を考えるとなかなか踏み切れないでしょう。心情的には、リファクタリングには賛成、でも、自分が担当しているときはちょっと．．．となるのではないでしょうか。

改変のタイミングをはかるための大まかな指標が必要と感じています。費用対効果に関する調査もまだまだ足りていないのではないかと。開発/保守する立場ならリファクタリングに対する費用対効果はあると考えるでしょう。しかし、それが発注の立場になっても同じかというと、なかなか微妙でリファクタリングのジレンマを強めているように思います。