リファクタリングは、設計や実装を改善する。
「何でそれが前と同じ機能を持って動くと信じられるか」と言ったら、改善されたそれが前と同じだと回帰テストを行なって確認するしか無い。
もし、高速にリファクタリングしたいならば自動化する。
なので回帰テストを書く時間が許されないならリファクタリングは無理。
開発してそれっきりの案件なら回帰テストを書くのは難しいだろう。しかしプロダクト開発は、ずっとソレを機能改善しないといけない。
そんな案件ならば話は違う。
回帰テストを書かないとやっていけないし、自動化しないとコスト削減できない。
リファクタリングを実施するのも抵抗なく出来るだろう。
チェンジシナリオにリファクタリングを混ぜて仕舞えば楽だ。
兎に角。
リファクタリング案件ではまずテストを書いて正しい振る舞いを定義してからやる。
テストはシステムでもインテグレーションでもユニットでも単体でもリファクタリングしたいスケールに合わせて作る。
まずは何を作り直すか、そしたら、そのレベルの回帰テストを書く。そこからリファクタリングが始まる