すべてのソフトウェアプロジェクトは、複雑さの予算を管理することを伴います。
複雑さの予算は、次のように定義できます。
アプリケーション全体にわたる複雑さの明示的または暗黙的な割り当て
ここでの「複雑さ」は、（形式的ではなく）主観的に定義されており、スチュワートの言葉で言うと、「見ればわかる」ということです。
または、ソフトウェア開発に特化して言うと、「感じればわかる」です。
アプリケーションアーキテクトの主な仕事の1つは、プロジェクトの複雑さの予算を管理することです。
複雑さの腹立たしい側面は、それに対処しようとする試みが、実際にはより多くの複雑さを加える可能性があることです。
この良い例は、私が以前働いていた会社で、プロジェクトの複雑さが増大しているのを管理するためにOSGiをシステムに追加したときのことです。これは合理的なアプローチのように思えました。洗練されたモジュールシステムを提供し、新しく採用されたアーキテクトによって推奨され、さらに「OSGiとは」のページにも次のように書かれています。
OSGiは、開発のほぼすべての側面で複雑さを大幅に軽減します。コードの記述とテストが容易になり、再利用性が向上し、ビルドシステムが大幅に簡素化され、デプロイメントがより管理しやすくなり、バグが早期に検出され、ランタイムは実行中の内容に関する非常に優れた洞察を提供します。
気に入らないことはありますか？
残念ながら、そのプロジェクトにOSGiを追加したことは、事実上プロジェクト全体を停止させてしまいました。最も優秀なエンジニアの何人かが1年以上通常アプリケーション開発から外され、完了したときには、コードベースは開始時よりもさらに扱いづらくなっていました。すでにぐらついていた機能のベロシティは、崩壊しました。
これはOSGiが普遍的に悪いと言っているのではありません。しかし、この場合、開発チームの生産性を向上させるのではなく、事実上終わらせてしまいました。
優れたソフトウェアアーキテクトとは、プロジェクトのソフトウェア予算を効果的に、明示的または暗黙的に管理する人です。
私の感覚では、確固たる証拠があるわけではありませんが、スチュワート的なアプリケーションの複雑さは、アプリケーションの規模とともにほぼ幾何級数的に増大します。経験豊富な開発者による適切な分解は、この曲線がある程度の間は抑制することができます。
しかし、それはどこかに、複雑さの壁が潜んでいるという事実を変えるものではありません。
そして、注意を怠ると、その壁に正面から衝突し、開発速度が停止してしまうでしょう。
私はこれを何度も経験しました。ある日、私が携わっていたシステムの開発が、説明できない理由で、「大規模だが管理可能」という状態から「これは対応できない」という状態に変わってしまったのです。
複雑さの予算を管理するためのツールをいくつか紹介します。
残念ながら、経験から、スチュワート的な複雑さを管理することは主観的な取り組みであり、才能と経験のある多くの開発者が、特定の意思決定ポイントで適切な行動方針について意見が異なることが示されています。
それにもかかわらず、ソフトウェアプロジェクトで複雑さの予算という概念を明確にすることで、これらの会話はより生産的になり、最終的にはより良いソフトウェア成果につながる可能性があります。
ほとんどすべての成熟したアプリケーションは複雑です。
新しいコードベースが「複雑」であると感じることは、すべてを分解したり、積極的なリファクタリングを行う言い訳にはなりません。常にチェスタートンの柵を念頭に置く必要があります。
アプリケーションが正常に（あるいは合理的にでも）機能している場合、複雑さの予算が適切に（少なくとも合理的に）管理されていたと想定する必要があります。
そして、既存の大規模アプリケーションの複雑さに対処しようとする大規模な試みは、残念なことに、頻繁に失敗したり、残念ながら状況を悪化させたりすることを常に覚えておく必要があります。