【要約】テスト・コミット・リバート（TCR）：Rubyのレガシーコードに立ち向かうための過激で実用的なワークフロー [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がテストのないレガシーコードを修正する際、既存機能への影響が不明で、デグレのリスクが極めて高い状況に直面する。
- ・テストコードが不在のため、修正の安全性を担保できない。
- ・ロジックが複雑化しており、手動確認では網羅性が不足する。
- ・修正による副作用の特定が困難で、開発の心理的負荷が増大する。
// Approach
開発者は、Kent Beckが提唱したTCRを用い、常に「Green（テスト成功）」の状態を維持するワークフローを採用する。
- ・保存をトリガーに「テスト実行、成功ならコミット、失敗ならリバート」を自動化する。
- ・テストの枠組みを先に作成し、アサーションを1行ずつ追加して保存を繰り返す。
- ・VS Codeの「runonsave」等のプラグインを利用し、シェルスクリプトで制御する。
// Result
開発者は、テストケースを段階的に積み上げることで、コードへの理解を深め、安全なリファクタリングを実現する。
- ・テストカバレッジが自然に向上し、コードの仕様が明確化される。
- ・失敗したコードが即座に消去され、試行錯誤のコストが最小化される。
- ・大量のWIPコミットは、最終的にsquashして履歴を整理できる。
Senior Engineer Insight
> TCRは、開発者の「失敗への恐怖」を仕組みで解決する優れた手法だ。ただし、実戦投入にはテスト実行速度が鍵となる。テストが数分かかる環境では、保存ごとの実行は開発体験を損なう。高速なユニットテストが前提だ。また、Git履歴が汚れるため、squashの運用を徹底せよ。レガシーコードの解体には極めて有効な「鉈」となる。