成熟したソフトウェアの大半は、全体が美しく設計されているわけでも、明らかに破綻しているわけでもない。 よく考えられた部分と、長年の拡張で生まれた複雑さや暗黙の依存関係が混在している。 Bryan Cantrillは、この状態を清潔なものと腐敗したものの中間にある「薄汚れた」ソフトウェアと分類する。
薄汚れたサブシステムは普段は安定して動くため、露骨に破綻したコードより危険を見落としやすい。 変更前まで動いていた事実は設計の健全さを保証せず、利用側や別のサブシステムが暗黙の前提を守り続けてきた結果かもしれない。 変更では、ロックの規則、新たに生まれる依存関係、インターフェースの新しい使い方、利用側が頼る前提を調べる必要がある。
既存のテストが通るだけでは、変更固有の壊れ方を調べたことにならない。 利用できる複数の環境で動かし、あり得る誤りを区別するテストを加え、自分の差分が間違っていると仮定して読み直す。 これはあり得る誤実装を区別するテストと本番環境まで含めた影響の検討を、対象に蓄積した暗黙の前提から設計する作業である。
すべての不具合を事前に発見できるという意味ではない。 分かっている検証方法を使い切ってから変更を統合し、それでも不具合を入れたときは他のサブシステムやレビュー担当者のせいにせず、次に変えるべき作業方法を探す。 慎重さは不具合を一度も起こさないことではなく、変更前の検証と変更後の学習に責任を持つことで表れる。
https://bcantrill.dtrace.org/2015/09/03/software-immaculate-fetid-and-grimy/