コードの品質はどこまで悪くなれるのか、限界はない

放置されたコードベースには「沈みゆく船」という比喩がよく使われる。それは最終的な終わり、つまり水が甲板に達して全員が船を見捨てる時点があることを示唆する。しかし、それは誤解を招く。ザック・ケイズ氏がエッセイ There's No Limit to How Bad Code Can Get で論じるように、物理的な船とは異なり、ソフトウェアシステムには構造的な限界が本来存在しない。複雑さを無限に追加し続けることはできるが、崩壊はしない。ただ遅くなり、変更が難しくなり、作業が苦痛になるだけだ。

アマゾンでの実例

ケイズ氏は、アマゾンの注文処理チームでの10年前の経験について述べている。システムの核となる機能（データベースへの書き込みや他のサービスへの呼び出し）は、24人のエンジニアで保守可能なはずだった。しかし、組織には数百人がいた。エンジニアが去るにつれ、組織的な知識は侵食され、コードには「お化け屋敷」が残った。ビジネスルールは文書化されていないことが多く、システムはチームの境界をまたがり、トレーシングを不可能にしていた。

数年ごとに、新しいシニア採用者がアーキテクチャの再構築を試みた。それはいつも失敗した。システムは完全に理解するには複雑すぎ、昇進サイクルが短期であるため、不完全な情報で修正が設計された。結果として、アーキテクチャに新しいレイヤーが継ぎ足され、人員は増え続け、サイクルが繰り返された。

比喩が崩れる理由

著者の重要な洞察：ビジネスは沈むかもしれないが、ソフトウェア自体は沈まない。コードは常に悪化しうる。常に別の間接層、別のパフォーマンス劣化がある。しかし皮肉なことに、コードがある種の「底」に達する前に、ビジネスが死ぬことが多い。

レガシーシステムを扱う開発者にとって、「沈みゆく船」は誤った安心感を与えるという教訓が得られる。魔法のようにリセットされるようなポイントはない。もしそのようなシステムにいるなら、船が沈むのを待っているのではなく、変更のコストが現状維持のコストを上回ると誰かが判断するのを待っているのだ。

全エッセイを読むと、大規模組織における技術的負債の仕組みについてより深い考察が得られる。