テストの無い古いコードを、どう安全に直しますか

いまの動きを固定するテスト

テストの無いコードは、何が正しい動きなのか、書いた人にしか分かりません。そこで、正しさを決めるのではなく、「この入力のとき、今はこう返る」をそのまま記録するテストを書きます。仕様を確かめるテストではなく、変えてしまったことに気づくためのテストです。

おかしな動きを見つけても、ここではまだ直しません。テストに「今はこう返る」と書き、気になる点として別に残します。直すのは、動きを変えないための作業が終わってからです。動きを変える作業と、動きを変えない作業を、同じ一歩に混ぜないのが大事です。

差し込める所を作る

古いコードは、DB や時刻、外の API を中で直接呼んでいて、テストで動かせないことがよくあります。そこで、その呼び出しだけを引数や別の関数に出し、テストのときは差し替えられるようにします。この差し込める所を作る変更は、テストが無い状態で行うので、道具の機能で名前を変える、関数を切り出す、のような機械的な変更だけにとどめます。

小さく変えて毎回確かめる

一歩ずつの変更は、1 つのコミットで 1 つのことにします。名前を変えたら回す、関数を切り出したら回す、です。テストが落ちたら、直前の一歩を戻せば済みます。

AI に直させるときも同じです。いまの動きを固定するテストを先に置き、変更は小さく区切って、テストが通ったものだけを取り込みます。

書き直すか、置き換えるか

全部を一度に書き直すと、古いコードに隠れていた例外の扱いを落とし、終わるまで何も出せません。そこで、新しい作りを横に置き、入口で機能ごとに新しい側へ流れを移していく進め方を選びます。古いほうは、使われなくなった所から消していきます。

ただし、小さくて、使う人も少なく、動きがはっきりしているなら、書き直したほうが早いこともあります。どちらにするかは、壊したときの影響の大きさと、いまの動きをどれだけ把握できているかで決めます。

話すときは、自分が触った古いコードで、どのテストを先に書き、どの順で直したかの例を 1 つ用意します。話す例は架空の例で構いません。