リファクタリング-プログラムの体質改善テクニック

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

動作しているコードは触るなというのは人情ですが、リファクタリングとは既存のコードを外部の振る舞いを保ちながら、ソースコードをきれいにすること。昨日は完璧に美しいクラス階層であったとしても、今日の仕様変更で簡単に汚れてしまう。拡張性を持たせて設計したところは実はちっとも拡張されることはなく、当初の予定外ところばかりが拡張され、その場しのぎの応急処置のコードが散らばってしまう。大事なことは昨日の設計判断の誤りを認め、現状に合わせてクラス設計を逐次変更すること。
重要なことは、いきなりすべてをキレイにしようとしないこと。例えば新しい機能を追加しようと思ったときに、追加しやすいように既存コードを変更して整理する、共通部分をメソッドとしてくくりだすなど。完璧な設計などないのだから、やる前よりも少しでもキレイになればよしとするというのが大事。
んで、機能追加とリファクタリングは明確に区別して行うこと。一緒にやるとバグの元。リファクタリングをする場合にも、常にコンパイルとテストが通るようにステップを細分化する。例えば、メソッドを別のクラスに移動する場合は、いきなりカットアンドペーストするんじゃんくて、コピーで両方のクラスに同じメソッドを作ってから、旧クラスから新クラスへ委譲するように書き換えて、そのあと旧クラスの方のメソッドを削除するなど、一気に変更せず小さなステップを繰り返す。まー、そーゆーかんじのテクニックを本書では列挙してある。
リファクタリングすべき箇所はコメントで処理を説明してるところとかが怪しい。分かりにくいからコメントがあるわけで、コメントなしでわかるように書き換えるか、メソッド抽出でひとつの塊として括りだせばメソッド名がコメントのように読める。適切な名前の付け方が一番大事で難しい。
ここからは、個人的な話。リファクタリングを行うためには外部の振る舞いを保っていることを保証するために、テストケースが必要になるのだけど、商用のビジネスロジックならあって当然、でも研究のシミュレータにそんなものないわけで、てか、ルーチング部分とかアルゴリズムは定義できるが、出力がどうなるかなんてデータほり込んで最適化問題解かないとわからないとかいう仕様なので。パケットスイッチング部分とかは仕様が明確だけれども、テストするためにネットワーク構築してパケット流して準備すべきモックが多すぎて現実的に無理。で、そんな場合にどうやってリファクタリングしようかというわけで、出力結果はテキストベースで出してるので、片っ端から統計値やログ情報など内部データを出力しまくります。んで、その出力をテキストファイルに保存しておいて、ソースコードを編集後、もう一回実行してその出力結果と期待する結果の差分をdiffコマンドでチェックし、1文字も違いがないことを確認するということで対処してます。すべての考えうる実行パスをチェックするのは無理ですが、まぁあるサンプルにおいて詳細な結果が完全に一致していればよしとしようというかんじで妥協。