プロジェクトのサイズにより、展開がより危険になりますか？
先日、上司とこの点について議論していました。彼は、コードベースが大きいほど、展開がリスクが高いと主張しています。
私はこれは真実ではないと主張しましたが、彼がそう思うかもしれない理由はわかります。私の経験では、堅実な原則に従って適切なテストを行っている場合、コードベースのサイズは重要ではありません。
数千の可動部品があるにもかかわらず、私は現代の自動車の例とそれらがどれほど信頼できるかを挙げようとしました。これは、各作品がその仕事を行い、その仕事だけを行い、それがうまくいくからです。
私は頭がおかしいのでしょうか、それとも、一部の人々が受け入れるのに苦労している直観に反するものの1つにすぎませんか？
典型的なソフトウェア製品のサイズが何年にもわたって大きくなると、バグが隠れたり、より複雑で予期しない相互作用が発生したりする可能性のある場所が間違いなく増えます。これが上司の正解です。
一方、品質の低下に対する対策には、しばしばさらにコードの形で
自動テスト、
自動展開、
より多くの製品内検証、
構成管理の改善
コードジェネレーター
冗長機能
追加のセキュリティ層
等々。また、コードレビュー、手動テスト、ドキュメントなどのプロセス改善も必要です。
したがって、展開のリスク（それが何であれ）は、コードベースのサイズにある程度依存しますが、それだけではありません-特定の機能に必要なコードと全体的な品質を高く保つための他の対策をサポートする。
「確かな原則に従い、優れたテストを行う」-あなたが書いたように-良い出発点ですが、長期的には十分ではありません。システムに含まれる機能が多いほど、品質保証および品質管理のすべての既知の手段を適用することが重要になります。
つまり、あなたが説明した2つの視点にはどちらもある程度の真実が含まれていますが、どちらも私を単純化しすぎているように見えます。
特定のモジュールに重大なバグがある可能性が1％あるとします。システムが機能するために両方が機能しなければならない2つのモジュールがある場合、システム障害の可能性は1.99％です。そのようなモジュールが3つある場合、システムが失敗する可能性は2.97％です。これが基本的な信頼性エンジニアリングです。
単純化しすぎましたが、主なポイントは、システムの信頼性は個々の重要なコンポーネントの信頼性よりも悪く、追加の重要なコンポーネントごとに悪化することです。システムの信頼性を高めたい場合は、1つのコンポーネントの障害がシステム全体に影響を与えないように特別に設計する必要があります。たとえば、物理的に別のマシンで冗長サービスを実行することによって。
例は貧弱です
現代の車は複雑ですが、レゴが複雑な構造を作ることができるのと同じ理由で非常に信頼できます。
どちらも4Dインタラクションに制限されています。
もちろん、次のようないくつかの原則があります。
- 明確に定義されたインターフェース
- 大量生産
- コンポーネントの品質保証
それをソフトウェアコードと比較してください。 3番目、400番目、およびおそらく2001- 69876の間のすべての行は、変数Aに影響を与える可能性があり、次に影響を与えます...
次元性は心を揺さぶる。
ここで、コードを記述して数十次元に制限し、明確に定義されたインターフェース、大量生産、品質保証などのその他の原則を実装すると、実際に車に見られる信頼性のレベルにアプローチできます。
実際、これらのシステムは、飛行機の航空電子機器などに存在します。これらは明確に定義されたインターフェースを備えたモジュール式であり、各モジュール自体が冗長であり、各複製は競合するチームによって個別に生成され、すべてのコンポーネントとアセンブリで品質保証がスローされます。
危険
上司は、コードベースが大きいほどリスクが高いと想定するのが正しいです。その余分な行により、ソフトウェアの次元が高くなる可能性があるからです。次元が高いほど、結果スペースが大きくなり、品質を保証する必要があります。
世界には非常に多くの時間しかないので、その結果スペースのほんの多くしか検証できません。検証された領域に日常の操作が留まる可能性が低いため、その差が大きいほどコードベースのリスクが高くなります。
適切なエンジニアリング手法を適用すると、内部の次元を減らし、結果として結果スペースのサイズを減らすことができるという点で正しいです。また、結果スペースの領域をより確実かつタイムリーに検証できます。
最も信頼できるコードは、存在しないコードであることにも同意できると思います。
2つの他の点では等しいプログラムでは、大きいプログラムほど明らかにリスクが高くなります。
しかし、同じようにプログラムされたプログラムが2つあるのはいつですか。
あなたが主張しようとしているのは、あなたの大きなプログラムは平均的なプログラムよりも賢く作成されており、それに比例した量のブーブーが欠けているということです。
これはおそらくマネージャーにとって説得力のある議論ではありません。展開、変更、バグ、ロールバックなどを記録してリスクを測定することを主張することをお勧めします