リファクタリングと作業

テスト駆動開発はテストがパスするように実装して、テストがパスすればリファクタリングを行います。つまり、「Red Green Refactor」がマントラ（mantra）です。

書籍『Refactoring』が出版された当時（1999年）は、まだEclipseはまだ登場していなくて、リファクタリングを行うとうのは、「クリエイティブな活動」と「作業」の組み合わせでした。

どのようなリファクタリングを行うかを考えるのがクリエイティブな活動であり、人が行えるものです。たとえば、簡単なメソッド名の変更において、変更後の名前を考えるのがクリエイティブな活動です。その活動は、コンピュータは行ってくれません。そして、新たな名前に変更するというのが作業です。

Eclipseが登場する以前は、この作業を手作業で行わないとリファクタリングは終わりませんでした。しかし、幸いにこのような作業は、今日ではEclipseやNetBeansなどのIDEが行ってくれます。その分、人はクリエイティブな活動に集中できるのです。

しかし、ソフトウェアの開発組織において、UML（クラス図やシーケンス図等）を書いて、それからコーディングし、コードの修正ではUMLを必ず修正することをルール化している場合を考えてくみてください。コードのリファクタリングに伴ってUMLを修正するというのは、ほとんどの場合、作業です。そして、人は面倒な作業を嫌います。その結果、「UMLを変更するのが面倒なので、リファクタリングしない」という状況が起こりえます。

もし、このような状況になったとすると、テスト駆動開発を導入しても、「自動テストコードがあるにもかかわらず、リファクタリングが行われない」という状況になります。そして、リファクタリングというクリエイティブな活動をしないことで、コードが腐るのに加えて、担当者のリファクタリング能力（言い換えると良いコードを書く能力）も伸びないことになります。

コメント 1

リファクタリング UML図 書き直しで検索しました。
テストを書くためにはクラス図があると便利なのですが、リファクタリングしたらURL図は修正しないといけないですよね。
でもその修正が足かせとなるならばUML図は破棄すべきなのでしょうか・・・
by agileronin (2012-08-13 16:37)