実践レガシーコード改善

今やってるプロジェクトでレガシーコード改善ガイドを大いに参考にさせてもらって、レガシーコードじゃないけども、改善してみた。

今回の言語はPerl。
cronに登録するタイプのもので、ようはバッチだ。
DBの情報をぱちってきて、ごにょっとやって戻すなんて処理をしている。

さて、もちろん(最近w)私はレガシーコードなんて書かないので、テストはすでにある。
テストでもDBには接続する。(テスト用のDBに。)
レガシーコード改善ガイドによると、これは単体テストの定義から外れているのだが、まぁ良としよう。
※Railsのテストと同様の作りだと思ってもらえればよろしい。

今回の改善は、↑のテストを作るとき、とりあえずのテストを書きたいがための苦肉の策としてDB接続先情報をテスト用DBに直接変更してテストという、どうしようもないソースだったのを、何とかしたい。という欲求から始まった。

テストが動くことを確認してから、ソースのリファクタリングを始めた。

まずは、DB接続情報など、テストと本番で違うか書を洗い出した。
幸いこの洗い出しは、作成時に変更が必要であろうと私が予期していたため、1ヶ所に纏められていた。

次に、今あるソースの名前を変更した。
sample.pl→sample_process.pl

そして、sample.plを新しく作成する。
sample.plには、

require "sample_process.pl";

とだけ書いておく。

さて、これで再度テストを試してみる。
OK動く。

次に、sample_process.plから慎重に
DB接続情報などをsample.plに移動する。
同時にsample_process.plで、DB接続情報などを使用していた箇所をsample.plに移動したものを使用するように必要に応じて変更する。
たくさんあるなら、一つづつ慎重にやるべきだろう。

さて、これで再度テスト。
OK動く。

sample.plは完全にテスト用なので、
こいつをsample_testing.plにでも変更しておこう。
テスト側の呼び出しも変更だ。

sample_testing.plをまるっとコピーしてsample.plをまたしても作る。
sample.plの中身を本番用に書き換えれば完成。
とりあえず、sample.plをうごかして動かして接続先情報が間違っていないかを確認しよう。
動けば処理はテスト済みなので、バグが混入する確率は極めて低いだろう。

さて、こんな感じで、テスト環境が整った。
今回参考になったのは、

• 接合部

（今回は接合部が無かったので↓で作った）

• ラップメソッド

（今回はメソッドではなくファイル名を同名にすることで同様の効果を得た。 リファクタリング前も後も perl sample.pl で実行できる）

もし、テストが無い状況から始めなくてはならなくても「仕様化テスト」を作成すればこのリファクタリングは可能だろう。

まだ半分くらいしか読み進めていないが、超おすすめの一冊だ。