http://martinfowler.com/bliki/RefactoringCringely.html

Robert Cringely による最近の記事が、リファクタリングコミュニティの中でちょっとした騒ぎとなりました。彼はリファクタリングを批判していたのです。Phlip はリファクタリングメーリングリストでの反応をいつになく神妙にまとめていました。

”“……彼は読むつもりのない本にレビューを書く「懐疑論者」のようだ。

確かに、Cringely がどれほどリファクタリングを理解しているか定かではありませんでした。リファクタリングのキーポイントが「振舞いを変えずに処理を変更する」だということは理解しているようでしたが……。彼が言ったのは、リファクタリングが適切に使われていない点について強調しただけなのです。

リファクタリングの誤用のひとつ目は、これから変更しないコードをリファクタリングするというものです。リファクタリングの醍醐味は、いまあるコードの設計を改良することです。よく設計されたコードは変更がしやすいのです。つまり、将来変更するかもしれないコードをリファクタリングすればいいのです。安定したコードをリファクタリングすることに意味はありません。

もうひとつのリファクタリングの誤用は、彼の例にもあるように、他のチームのコードを調べて、リファクタリングまで行ってしまうというものです。これは単なる「サービス」であり、避けたほうがよいでしょう。プログラマは自分達のコードをリファクタリングしていればよいのです。他の人のコードにまで、リファクタリングガンを乱射する必要はありません。 XPチームではコードの共同所有を行っています。チーム内の誰もが、コードをリファクタリングすることが出来るのです。ですがこれも、「チームのコード」をリファクタリングするだけです。ひとつのチームが他のチームのコードをリファクタリングしまわる、なんていう理論を私が推奨しているわけがありません。

最後に彼は、リファクタリングがどんなコードの変化をもカバーしていることについて文句を言っています。他の点と同じように、彼には100%賛成です。リファクタリングが「再構築」の同義語として使われていることに対し、私もずっと不満を持っていました。リファクタリングとは、意味を保持したままコードを変化させる一連の小さなプロセスで、非常に限定されたものです。非常に特殊で規律あるプロセスなのです。コードを「再構築」する方法は、良かれ悪かれ、他にもあります。ただそれは、リファクタリングではありません。

なんだか全体的に Cringely の意見の大部分に賛成しているみたいですね。確かに賛成しています。メーリングリストのコメントについてもそうです。むかつくのは、Cringely が一時的な流行だけ捉えて、リファクタリングを誤った形で特徴づけていることなんです。必死だよな。

Cringelyと意見が違うのは、リファクタリングの80%が時間な無駄で、ソフトウェアマネージャはお金を節約するためにリファクタリングを中止しなければならないという点。リファクタリングのポイントは、設計を向上させ、変更しやすくする点です。よって、リファクタリングによって生産性は上がるのです。プログラマは、リファクタリングする価値があるかどうか判断しなくてはいけません。ただそれは、簡単に定量化できるものではありません。しかし、ひどい設計な上にパッチを取り入れてさらにひどくなっているコードに骨折り損して、時間を無駄にしているひとたちを何度も見てきました。リファクタリングはそういったデススパイラルから逃れる手段なのです。だからこそ、私はリファクタリングは価値ある技術だと思っているのです。