不要なコードの削除

「リファクタリング」で紹介されているリファクタリングの中に、不要なコードを削除するテクって書いてあったっけ？インライン化は載っているけど、削除を目的にしたものはないと思うんです。
実際、何度もリリースを重ねたシステムって、どこかに不要なコードが残っていたりします。それを削除するだけでシステムへの見通しはずいぶん変わることもあるはず！というわけで思いつきを書きます。

依存性の検出

ある変数名、メソッド名、クラス名、ファイル名や、HTMLのidやclassなどは、単純にソースコードをgrepしただけでは削除可能かどうかは判断できません。なぜならリフレクションで動的にそれらを取得することもあれば、メタプログラミングやアスペクトの適用、DOM オブジェクトの生成などなど・・・により動的に追加されることもあるためです。Ajaxによって動的に表示するページを変更するURLが動的になっている場合も同様です。

ソースコードを読んで判断

一つのファイルやクラス、メソッド、変数などに着目して関係する箇所をgrepなどを駆使してトレースする方法です。一番地道で比較的時間がかかりますが、ソースコードの理解に繋がる可能性があります。また適用範囲が広いことも特徴です。

自動テストによる試行錯誤

自動テストが完備されている場合、削除できそうな個所を削除して、テストを実行、テストがパスするならコミットします。ただし、現実的にはテストが完備されていることを確認するのは非常に難しいため、この方法のみで削除可能かどうかを判断するのは危険だと思います。

拡張による自動トレース

ライブラリなどを拡張して、ファイル、クラスのロードなどを行う処理をフックしてどのファイルやクラスがロードされたのか、あるいはどのメソッドが呼び出されたのかを記録できるようにした上で、システムのすべての処理を実行することで、使用されるファイルやクラス、メソッドなどを記録できます。それらを元に削除可能かどうかを判断します。このような拡張を行うライブラリなどがある場合は非常に有用ですが、全ての処理を実行することを確認することが難しいかも知れません。

現実的対応

結局どれも一長一短があるため、これらを組み合わせて使用することが最も現実的だと思います。
またこのような作業は完璧主義者が不要なコードを完全に取り除こうとして、プロジェクトが必要とする簡潔さ以上の作業を行ってしまう傾向があります。なぜ不要なコードを削除するのかを十分共有してからチームとして本当に不要なコードを削除するタスクが必要なのかを考えるべきだと思います。

また、日常からコードが不要になったら積極的に削除する習慣をつけるべきです。特にソースコードをSubversionなどのツールを使っているのなら、元に戻せることが担保されているのですから。