リファクタリングしてますか？

先日、書籍『リファクタリング』を読み直していることを書きました。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

• 作者: マーチン ファウラー
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2000/05
• メディア: 単行本

「リファクタリングの第一歩」（7頁）として、次のように述べられています。

リファクタリングを開始するとき、最初にすることは常に同じです。対象となるコードについてきちんとしたテスト群を作りあげることです。リファクタリングは非常に順序だっていて、新たなバグを生み出しにくくなっていますが、人間が作業する以上、間違いを犯す可能性があります。このためテストは大切で、きちっとした一連のテストを用意するべきなのです。

10年前に読んだ時に、私自身がきちんと理解していなかったのは、この点です※1。きちんとしたテスト群があり、それらを使用してコードをリファクタリングすることが、リファクタリングの基本なのです。しかし、そのためには、自動化されたテストが必要となります。いくらテスト群があっても、すべて手作業を実行しなければならなければ、役に立ちません。

単体テストが自動化されておらず、手作業で行われているような組み込みシステムでコードレビューを行うと、「時間があれば、後でリファクタリングします」とか「リファクタリングする工数がもらえれば、リファクタリングします」という発言が聞かれたりします。

私が10年前にきちんと理解していなかったように、これらの発言は、「リファクタリング」を「コードを書き直してプログラムの構造を良くし、コードをクリーンにする作業」とだけ理解していることを意味しています。自動化されたテスト群が必要であることは、抜け落ちていることになります。自動化されたテストがなければ、再度、手作業でテストを実行しなければならないという余分な作業が入るため、「後で」行うという発想になっています。

この場合、テストをまず自動化することを検討して、それを最初に実施してくださいと指導します。しかし、そのための工数が無駄に思えるらしく、なかなか素直にやってみますという返事にはならないことがあります。テストコードを書き直す作業ですので、与えられた仕事である機能を作りこむ作業が遅れるという恐れから抵抗されます。

このような抵抗に対して、William Opdykeは第13章「リファクタリング、再利用、現実」※2で「リファクタリングのオーバーヘッドを減らす」（389頁）と題して、次のように述べています。

「リファクタリングは余分な作業だ。自分は、売上に貢献する新たな機能を書くことで給与を得ているのだ」。これに対する私の答えをまとめると、次のようになります。

• 幾つかのツールや技法を使えば、リファクタリングは短時間で比較的苦痛もなく済ますことができます。
• 何人かのオブジェクト指向プログラマから報告されて経験によれば、リファクタリングのオーバーヘッドは、それによりプログラム開発における他のフェーズでの労力の減少とあき時間でまかなって余りあるのもです。
• 始めは、リファクタリングが多少扱いにくくて余分な作業項目であると映るかもしれません。しかし、ソフトウェア開発制度の一部になるにつれて、そういう感覚はなくなり、むしろ不可欠に感じるようになります。

実際、テスト駆動開発を行い、リファクタリングを開発プロセスの一部として常に行うようになると、「不可欠」になってきます。しかし、全く経験したことがない人に、テストの自動化とそれによるリファクタリングの可能性を説得するのは難しいと私自身も感じています。その点に関して、William Opdykeは続けて次のように述べています。

私の経験からは、リファクタリングが日常作業の一部になれば、余分な作業と感じることはなくなると思います。と言うのは簡単ですが、それを具体化するのは困難です。懐疑的な方に対して私が助言できるのは、ご自身で実行し判断していただくということだけです。ともかく、時間を割いてみてください。

とにかく、自分で実践して、経験してみることが重要だと思います。

※1 平成12年(2000年)に執筆した記事「リファクタリングの勧め」（Java PRESS, Vol.12）には、この点に全く言及していないことからも分かります。
※2　第13章は、Martin Folwerではなく、William Opdykeの寄稿となっています。