「リファクタリングをしたい」となったときに、リーダーとして「これってGoサイン出していいんか...??」と迷った時の思考についてメモります。
Q&Aベースで思考を深めていく形をとります。
リファクタしたい箇所に仕様変更、機能追加の予定はある？
言いたいのは「やらなくていいなら、やらない」精神を忘れないようにしましょう、と言うこと。
我々が書いて市場に送り出したコードは、多かれ少なかれユーザに使われて価値を生み出しているはずです。
基本的にはその状態がベストなので、できることならそのままにしておきたい。
でも、このままだと将来の開発に悪い影響が出始める...そんな時に、初めてリファクタリングをしたくなるはずです。
そんな感じで、リファクタリングは必ず「今後の開発のための投資」になります。よって、追加開発/仕様変更の予定が全く無いなら、何もしない方がマシです。
「開発コストだけかかったけど、ユーザ目線だと何もかわってない」な状況が生まれ、お金（=エンジニアの給料）が無駄になります。
そもそもなんでリファクタしたくなったんだっけ？
リファクタする目的を洗い出します。
- コードが読みづらいから書き直したい
- これ以上修正するとバグを埋め込む可能性があるのでテストしやすくしたい
- そもそも使われない機能なので捨てたい（断捨離）
など色々あるはず。この辺りは定量的に測るのが難しいので、チーム内で会話しないといけません。
「あれ...このコード直したいと思ってるの俺だけ...???」みたいなこともあるので。
直すのにどれくらいかかる？
やるとしたらどれくらいかかるか見積もります。
「すでにある開発計画の中でシレッと直しておける」レベルなのか、「明らかに計画からはみ出るので外部に説明して計画を引き直さないといけない」のかを判断します。
デグレ検知するためのテストはある？
「すでに動いてるコードが動かなくなる可能性を限りなく減らしたい」ので、セーフティネットがあるか確認します。
無い場合は自動テストを先に書くか、結合テスト等でチェックしてもらうように調整が必要です。
良い感じでセーフティネットになってくれるテストの書き方についてはこちら↓
決断
上記で出た情報をもとに、
- デグレするリスクが許容できる
- 工数は納期に収まる（または調整できた）
- リファクタによるメリットがチームで共有できている
なら「GO！」です。