技術的負債：いつ負い、いつ返すか

すべての近道が負債ではない

現在のニーズに足る単純なコードは、汎用でなくても負債ではない。負債とは後でより多くのコストがかかる解決策を意識的に選ぶこと——分かれると知っている重複、先送りしたテスト、成長に耐えないデータ構造。

無知から書かれた悪いコードは負債ではなく、将来のバグだ。治療が異なるため、区別は重要だ。

負うのが得策なとき

機能が残るかどうかまだわからないとき。一ヶ月で削除されるかもしれないものに完璧なインフラを構築しても意味がない。

本物の時間の窓があるとき——ローンチ、顧客、規制。だが、何が先送りされたか、コードのどこか、戻る必要を強制するシグナルを記録する。

すべてを止めずに返す方法

「一ヶ月止まって整理する」はほとんど承認されない。機能するのは：進みながら返す——問題のある領域に触るたびに少し改善する。そして各作業サイクルの固定の割合を機能と同様にメンテナンスに割り当てる。

よく触れる場所での返済を優先する。二年間誰も開けていない醜いコードはあなたの問題ではない。