のみほーだい!

アジャイル・プロセス（Ａｇｉｌｅ　Ｐｒｏｃｅｓｓ）の導入について

第４回　リファクタリングの考え方

リファクタリングとは？

プログラムの機能仕様を変えることなく内部構造を改善していく作業を指します。内部構造を変えるということは即、設計の見直しを意味します。その為、無計画に修正を行ったのでは逆にリスクが大きくなってしまうので注意が必要です。体系的な手順（ガイド）があるのでそれを守って行ないます。
　また、修正をすることにより以前動いていた機能が使えなく（デグレード）なったのでは意味がないので厳密なテスト体制をとり、全ての機能が従来どおり動いていることを保証しなければなりません。
　では何故リファクタリングなんて面倒なことをわざわざするのでしょうか。プログラムの保守（仕様変更・機能追加など）業務を担当していて元のプログラムのお粗末さに「これなら最初から作り直した方がずっと早いし、洗練されたものになる」と感じた経験のある人は多いのではないでしょうか。従来の方法論ではこのような設計の見直しを前提とするような考えは受け入れられませんでしたが、理想と現実のギャップは確実に存在するし、仕様変更など事前に予測不能なものを予め組み込んだ設計など不可能ですから、発想を変える必要があります。
　尚、どうせ見直すんだから最初の設計をいい加減にして良いと言っているのではないので念のため注意。
逆にリファクタリングの要点を理解し、それを意識して設計すれば、最初からある程度まともなものができます。

リファクタリングの利点は、

●ソフトウェア設計を向上させる 　→ 　コードの変更による設計の劣化を防ぐ ●コードを理解しやすくする 　→ 　要件定義の抜けの早期発見 ●細かい単位でテストできる 　→ 　バグの発見が容易になる ●無駄な（重複した）作業がなくなる 　→ 　ソフトウェア開発のスピードが一定に保たれる

という点にあります。

リファクタリングを行なうタイミング

リファクタリングは予めスケジュールに組み込んで定期的に行なう性質のものではなく、作業の区切り、言い換えれば次の作業に入る準備として定常的に行なっていきます。目安として次のタイミングで実施します。

・3度目の法則

作業をしていて以前似たようなことをしていたと気づいた時は、意識に留めたまま作業します。そして次に同じような作業が発生して3度目だと気づいたらリファクタリングを行ないます。

・機能追加時に行なう

機能追加が発生した時に、コードを修正する前にリファクタリングします。一番の理由は元のコードを理解するのに役立つことです。次に容易に機能追加できない構造を改善すれば、作業がずっと手早く簡単になります。

・バグ修正時に行なう

コードを理解するときには常にリファクタリングが有効な手段となります。言い換えればコードが不明瞭なため、バグが発見できなかったことを示しています。

・ソースレビュー時に行なう

ソースレビューを定期的に行なっているプロジェクトでは、その時にリファクタリングを行ないます。その為にレビューはできるだけ少人数で行なうのが有効です（制作者とレビュー担当の2人が対話形式で行なうのがベスト）。

リファクタリングをやってはいけない場合

既存のコードがあまりにお粗末で使い物にならない時は、リファクタリングするより最初から作り直した方が工数の削減になります。また、納期直前も避けます。この場合はリファクタリングの効果が出て生産性が向上するのが締め切り後になってしまい、間に合いません。

リファクタリングの問題点

前回までと同様に、安易に導入して怪我をしないように注意すべき点を述べておきます。

・DBの変更

ほとんどのビジネス系アプリケーションではDBの構造に強く依存しているため、DBの変更は多大の時間と危険を伴います。対処としてはオブジェクトモデルとDBを分離する中間層クラスを導入しアクセサの変更によってDBの変更を吸収してしまうことが考えられます。

・インタフェースの変更

リファクタリングには多くの場合、インタフェースの変更が発生します。それが既に公開されているものだった場合、全ての利用者に影響が出てしまいます。対処としては古いインタフェースの実装部分で新しいインタフェースを呼び出すようにします。また、Javaの場合だったらdeprecatedタグを使用して、利用者にそのインタフェースが既に古いものであると注意を喚起するのも手です。デザインパターンのfacadeパターンを使ってパッケージの機能を有効に使い、できるだけ公開するクラスを減らすのも有効です。