特定の種類のソフトウェアがある。それはオハイオ州の製造会社で給与計算を実行している。それはあなたが訪れたことがない都市で列車のスケジュールを設定している。それは2011年以来生産されており、3人のCTOと民間投資による買収を生き延びてきた。それをメンテナンスする人々は、古い船乗りが経験した船について話すようにそれについて話す。読んで現実で崩れない変更安全システムの設計図は、私たちがこれらのシステムをあまり学ばないことと、この業界で発表しているものの多くが逆のことであること——緑地プロジェクト、リライト、アンビックス映像の建築的同等物——を思い出させてくれました。退屈なソフトウェアが勝ち、私たちはほとんど理由を問いません.

存続バイアスは私たちが無視し続けている

会議スケジュールをいくつか見て、5年以上古いシステムに関する講演の数を数えてみてください。指がなくなる前にスロットがなくなります。業界は新しさに対して構造的な好みがあり、その好みが静かに若手エンジニアが良いアーキテクチャとは何かと思うものを歪めています。彼らは書かれているシステムから学びますが、それは現在主流で作られているものが不釣り合いに多く、つまり彼らはまだ失敗する時間が経っていないシステムから学んでいるということです。

時間をかけて失敗し、それでも改善しなかったシステムたちは、履歴書上では時代遅れに見える特徴を共有する傾向がある。彼らは古いデータベースを使用している。中間にモノリシスがあり、誰もそれを分割しようとしない。彼らのデプロイメントプロセスには、現在の正統派が受け入れがたいと考えるよりも多くの人間が関与している。そして彼らは動き続けている。面白い問題は、これらのシステムが「現在の基準で『良い』かどうか」ではない。面白い問題は、私たちが忘れっぽいことを彼らが理解しているということだ。

物理的な力としての変化

エンジニアたちは変化を抽象的に考える傾向がある——機能リクエスト、リファクタリング、移行だ。しかし変化はより構造に作用する物理的な力のように振る舞う。それは方向性、大きさ、頻度を持っている。小さく頻繁な変化を吸収するシステムは、稀で大きな変化を吸収するシステムと異なる振る舞いをする。同じように、日常の交通に対応する橋と地震に備える橋は異なる振る舞いをする。すべての変化を同等と扱うことで、チームは数百回の小さなデプロイを順調に処理していたアーキテクチャが単一の大きな移行で壊れるのを驚くことになる。

この枠組みは、その主題に関する最も役立つ長文書の中で何度も取り上げられます。IEEE Computer Societyが出版したシリーズの回復性工学は同じ観察を繰り返し言及しています：複雑なシステムの失敗モードはほとんどの場合、構成要素に関することではありません。それは構成要素間の結合に関することです。そして、結合は正に何人かが小さな修正をリリースするたびに、静かに、蓄積的に変化するものです。橋の類比は比喩ではありません。それは実際のメカニズムです.

古いコードベースが正しく理解していたこと

数年間、地域別の決済機関の財務決済処理システムを開発していました。その核心部分は私が運転免許を取る前に書かれたものです。最初の6ヶ月は触れるだけで恐ろしく、その後は毎月明確になるものでした。そのコードベースから学んだパターンは今でも私に残っており、それ以来私は遭遇したあらゆる長期間稼働しているシステムでそれを見ることがあります。

• 誰も足を踏み入れることのない境界。 linterやコードレビューで強制される境界線ではない。境界線は、それを越えると異なるチームが異なる建物で所有する異なるデータベースに書き込む必要があるという事実によって強制される。物理的な分離は誠実なアーキテクチャを生み出す
• 証言のように読むログ。 あらゆる重要な行動は、何をしようとしていたか、どのような入力を受け取っていたか、そして何を決定したかを記録しました。デバッグのために——責任のために。何か問題が6週間後に発生した時、あなたは結果だけでなく、その推論のプロセスを再構築することができました。
• 適切なコードに対する病的な恐怖。 上級エンジニアは、正しく、十分にテストされ、より高速なプルリクエストを定期的に却下していました。その理由は、2029年の午前2時にデバッグする人間が理解できないからです。彼らはほぼ常に正しいでした。
• 意図的に数ヶ月かかるマイグレーション。 数週間にわたって二重記述、さらに数週間にわたって二重読み取り、古いパスが最終的に削除されるまでの長い検証の尾。移行は退屈だった。それが要点だった。
• 共有可変状態へのアレルギー。 パフォーマンスのせいではない。並行処理の理論のせいでもない。共有可変状態が組織記憶の死因であるからだ。同じ行を触る二つのシステムは、結局のところ、その行が意味することについて意見が合わなくなるだろう.

変化が無料であると装うコスト

現代のツール群は変化を安価に感じさせるようになった。コンテナは数秒で起動する。機能フラグは何もしないコードをリリースし、後で有効にできる。インフラストラクチャはコードとして意味することで、単一のコマンドで環境を再現できる。これらはすべて現実的だが、実際に変化を安価にするものではない。変化をリリースする行為を安価にするだけだ。コストは後で、結果として生じたシステムについて考える人々の認知的負荷として現れる。

アメリカン・コンピューティング・マシン協会は、このに関する長いシリーズの実証的研究を発表しており、彼らのACM Queue アーカイブで集められた運用複雑性の資料は、システムが変化を蓄積する中でチームが実際に何が起こるのかについて書かれている中で最も根拠のある文章の一つです。何度も現れるパターンは、システムがどれか一つの悪い決断のために失敗するというものではなく、それぞれの決断が個別には合理的だったが、その決断の蓄積された重みがどのエンジニア一人でも頭の中に保持できるものを超え、チームはそれでもツールが何も問題ないように感じさせたためにリリースし続けたからです。

実践的な再定義

オリジナルの作者を超えて存続しているシステムから学ぶべきことは一つだけ：文脈なしでこのコードを引き継ぐ人にとって最適化することだ。先週書いたあなたのバージョンでもなく、デザインがまだ新鮮なまま次の四半期にメンテナンスを行うあなたのバージョンでもない。その不慣れな人。2028年に特定の機能がなぜ存在するのか、削除しても安全かどうかを理解しようとしている新しい雇われ人。あなたが選択するたびに、その人は贈り物か税金かとなる。生存可能なシステムは、ほとんどの選択が贈り物だったシステムだ。

これは遺留コードに対するロマンチックな見方ではありません。古いシステムには実際の問題があります——死んだパスを蓄積し、時代遅れの仮定をエンコードし、難しいことをより難しくします。しかし、緑地プロジェクトにはない唯一の利点があるのです。それは現実との接触を生き延びたということです。彼らは間違って、正されて、再び間違って、再び正されて、その修正の残りは、どのアーキテクチャ図でも捉えることができないような知恵のようです。仕事は、ほとんどの場合、その知恵を置き換えることではなく、それを拡張することです。

誰も教えてくれない規則

このコースはありません。認定証書もありません。システムが生き残るために採用できるフレームワークもありません。この学科はより感覚に近いものです——コミットする直前に、あなたが行っている変更がシステムが吸収できるものか、それとも静かに将来の重みとして蓄積されるものかを尋ねる習慣です。この感覚を持つエンジニアは、短期的には同僚よりもリリースが遅くなる傾向がありますが、長期的には劇的に速くなります。なぜなら、彼らは常に、自分が負っている債務に気づかなかったことを支払っているからです。

死にやまないシステムは運が良くない。それは将来を真剣に受け止めた人々によって作られたものであり、その職業はほとんど現在を真剣に受け止めることに報酬を与えるものではない。何か長く続くものを作りたいなら、退屈なソフトウェアを学びなさい。15年間稼働し続けているもののソースコードを読みなさい。何をしないのかに注意しなさい。どのファイルにもどれだけの自制心が埋め込まれているかに注意しなさい。その規律はコードベースにすでに座っており、誰かがそれを古いものでなく、代わりに置き換える必要があるものとしてではなく、規律として認識するのを待っているのだ。