技術的負債は『なくす』のではなく『管理する』もの
すべての負債を解消するのは不可能です。本記事では編集部の視点で、現実的な負債管理を公開情報をもとに整理します。TDD 実践 もご参考に。
負債の4タイプ
(1) 意図的な負債：スピード優先で意識的に。(2) 無自覚な負債：知らずに溜まる。(3) 環境変化による負債：技術陳腐化。(4) 設計負債：アーキ自体の問題。(5) テスト負債：カバレッジ不足。タイプ別に対処が異なります。
可視化の方法
(1) FIXME/TODO/HACK コメントの集約。(2) 静的解析ツール：SonarQube/CodeClimate。(3) コードメトリクス：複雑度/依存数。(4) カバレッジ：弱い領域の特定。(5) 負債バックログ：チームで共有。アルゴリズム学習 もご参考に。
優先順位付け
(1) 影響範囲：何人に影響する負債か。(2) 変更頻度：触る回数が多い箇所優先。(3) 事故リスク：障害発生時の損失。(4) 新機能開発の阻害度。(5) 修正コスト：低コスト×高効果から。影響×頻度マトリクスが意思決定に有効です。
返済の仕組み化
(1) スプリント工数の20%を負債返済へ。(2) 『ボーイスカウト』ルール：触ったついでに少し改善。(3) 大規模リファクタは別枠：機能開発を止めて。(4) テスト追加と並行：将来の負債予防。(5) 四半期に1回見直し：負債バックログ更新。PDCA改善術 もご参考に。
意図的に負債を作る場面
(1) MVP 検証期：仮説検証優先。(2) 競合スピード対応：戦略的選択。(3) 不確実な要件：作り込まない。(4) 使い捨てコード：実験用。(5) 明示的に記録：あとで返す前提。無自覚負債と意識して区別します。
レガシーシステムへの対処
(1) Strangler Fig パターン：段階的に新システムへ移行。(2) Anti-Corruption Layer：境界で隔離。(3) Characterization Test：既存挙動の保存。(4) 機能凍結+並行開発。(5) 引退計画：何年で終了させるか。DDD 実践 もご参考に。
失敗しがちなパターン
(1) 機能開発に追われ放置。(2) 大規模リファクタを一気に：頓挫。(3) 負債の見える化なし。(4) マネジメントが返済を理解しない。(5) テスト不在のリファクタ：新たな負債を生む。対策は、(1)定期返済工数、(2)段階的、(3)バックログ、(4)ビジネス価値で説明、(5)テスト先行、です。