ソフトウェアが肥大化する原因は何ですか？[閉まっている]

今日、私はCreative Sound Blasterドライバーのクリーンインストールを実行することを決定しました。そのため、クリーンアップ手順全体を実行する必要がありました。そして、それは私にほぼ2時間かかった。

そして正直なところ、理由がわかりません！？そして、クリエイティブであるIMHOは、決して機能しない低品質のソフトウェアを生産する絶対的な1位ですが、肥大化の問題はそれらに限定されません。

キヤノンのデジタルカメラドライバーを搭載したPCには、あらゆる種類の接続と相互接続された約10のキヤノンエントリがあります。Visual Studioも主要な例です。フルインストールのエントリは約50ほどあります。その修復は、完全な操作でのみ可能です。そして、VS2k8からVS2k8SP1などにアップグレードするときに、OSのインストール全体を台無しにしてしまうことさえありました。結局のところ、5GBの空き容量は300Mbパッチには不十分でした...

したがって、これは本当に広範囲にわたる問題のようです。最近のほとんどすべてのアプリケーションには、通常、アンパッカー、複数のスパイウェアのような「友達」がインストールされており、ドライバーは通常、プリンターなどを含むすべてのものに対して約600Mbです。

しかし、なぜ？開発者のせいですか？このようなアプリケーションはサポートが悪夢であり、現在100％機能することはありません。私が知っているほとんどすべてのユーザーは、USBサムドライブ/プリンター/カメラ/サウンドカード/ブラウザーの必須ドライバーインストールとして得られるすべての膨張について非常に否定的です。

NullsoftのNSISが、Firefoxのインストールなど、私が知っていることから肥大化していない唯一のクリーンなセットアップシステムのようです。クリーンで、ほとんど問題なくxcopyベースのインストール。

それでは、なぜ人々は30層を超える相互接続に根ざしていない単純なセットアップとアプリケーションを使用していないのでしょうか。開発者が怠けているからでしょうか？codegenツールの使用？企業がユーザーが気に入るような重いアプリを強制しているからでしょうか？原因は何ですか？ソフトウェアがいつか基本に戻ることを期待していますか？新しいアプリケーションを最初から開始するときに膨張を回避するための手順は何ですか？

誰かが良いアイデアだと思った機能はたくさんあると思います。ただし、多くの人がすべて1つのアプリケーションにまとめられる個別のアイデアを持っている場合、これが非常に複雑になる可能性があります。大規模な企業向け製品の場合、製品の内容と、さまざまな観点から最適化する方法に責任を持つ製品マネージャーがいる場合、開発者を責めません。

これのもう1つの側面は、時間の大きな投資とは見なされないため、ほとんどの場合うまく管理されない可能性のある技術的な負債です。新しい機能やバグ修正は、すぐにビジネス価値がほとんどないように見えるリファクタリングやその他の借金タスクよりも意味があると思います。コードベースがかなり古い場合、開発者のチームがレガシーコードをクリーンアップするのに数週間かかるでしょうか？私の推測は頻繁ではないでしょう。

ストラテジーレターIV：ブロートウェアと80/20神話でジョエルを引用するには：

[...]ブロートウェアには多くの大きな理由があります。まず、プログラマーがコードの大きさを気にする必要がない場合は、より早く出荷できます。[...]ソフトウェアベンダーが出荷前に停止し、2か月かけてコードを圧縮して50％小さくすると、最終的なメリットはごくわずかになります。[...]しかし、新しいバージョンをさらに2か月待つことによる損失は認識でき、2か月の販売を放棄しなければならないソフトウェア会社の損失はさらに悪化します。

多くのソフトウェア開発者は、古い "80/20"ルールに魅了されています。そうです多くの意味を作るために：人々の80％は、機能の20％を使用します。つまり、実装する必要があるのは機能の20％だけであり、80％のコピーを販売できるということです。

残念ながら、同じ20％になることはありません。誰もが使用する機能は異なります。[...]

「ライト」製品のマーケティングを開始し、人々に「ほら、ライト、1MBだけ」と伝えると、彼らは非常に満足する傾向があり、重要な機能があるかどうか尋ねられますが、そうではありません。彼らはあなたの製品を購入しません。

そのかなりの部分は、製品の依存関係に関係しています。オペレーティングシステムには、あらゆる種類の標準ライブラリが多数付属しています。ただし、これらの標準ライブラリには、OSの進化を通じてさまざまなバージョンがあり、一般的なインストーラーは、ビルドされた特定のバージョンが実際にOSに存在するとは想定できません。

したがって、完全なインストーラーには、ターゲットコンピューター上の各依存関係の初期状態に関係なく、インストール後にすべてが確実に機能するように、すべての依存関係の正しいバージョンを含める必要があります。これは、Windows XPシステムに展開する必要がある.NETベースのアプリケーションなど、特定のタイプのアプリケーションにとって非常に大きな問題になる可能性があります。

最近まで、私が使用した1つのインストーラーシステムでは、最新バージョンをデプロイできるように、以前のすべての.NETバージョンをインストールする必要がありました。つまり、.NET 3.5アプリケーションでは、.NET 1、2、2.5、3のインストールバイナリが必要でした。 3.5の上に。この場合、インストーラーのみが肥大化します。

回避策の1つは、実際にはターゲットシステムに存在しないコンポーネントのみをダウンロードするWebインストーラーです。これは、サイズ/サイズが非常に大きくなる可能性があります。もちろん、インターネット接続が可能なシステムにインストールを制限します。

私はそれの多くがライブラリコードのレイヤーを重ねていることに関係していると思います。明らかに、ライブラリを使用するときは、ライブラリのすべてを使用するわけではないため、ライブラリを追加していくにつれて、過剰になります。

それと、典型的なコンピューターの処理能力/ストレージが年々安くなっている一方で、プログラマーによる1時間の作業のコストがますます高くなっているという事実と組み合わせると、この方法の方が実際にはコスト効率が高いことがわかります。

• 「Xを実行するために何かが必要です。別のプロジェクトで使用したため、ライブラリ$ BIGFATLIBDESIGNEDFORSOMETHINGELSEを使用しましょう。」
• 「このコード部分はもう必要ないと思いますが、何も壊れないようにするには、そのままにしてください」
• 単体テストがないか、十分でないため、
• リファクタリングなし
• 長年にわたって設定が保存されている追跡がないため、設定はどこにでもあります
• ...

それは絶望のサイクルの誰もが非難され得る悪循環です。絶望の1サイクルは、次のステップで構成されます。

1. ビジネスマンは肥大化した機能を求めています。
2. 開発者は、すべきでないことを知っていても、肥大化した機能を実装します。
3. 顧客は製品だけを欲しがっていて、愚かな機能は欲しくないにもかかわらず、肥大化した機能の代金を支払います。
4. ビジネスマンは、顧客が肥大化した機能を望んでいると信じています。
5. 手順1に移動して繰り返します。

どうやって止めるの？簡単な答えはありませんが、サイクルを停止するには、ステップの1つを破らなければならないことは明らかです。したがって、それはビジネス、開発者、または消費者のいずれかが革命的な行動をとることによってのみ破壊することができます。

1. エンジニアがモジュールを最適化しようとしましたが、いくつかの顧客の問題が発生しました。その後、彼のマネージャーはノーと言った。その後、エンジニアはトラブルが発生するまで「トラブル」を起こさないことにしました。
2. 複雑なシステムの場合、ベンダーはすでに多くのパッチを追加し、数千のバグを修正して、顧客の環境で安定させるようにしました。ソフトウェアの観点からは品質は良くありませんが、動作します。同じ量のバグを再度修正するためにそれを書き直したくはありません。
3. 下位互換性の理由から、市場で人気のない機能であっても、その機能を維持する必要があります。

その常に怠惰、それが膨張を引き起こすものです。（または、この主題に関する重要な記事である泥のビッグボール）

たとえば、私が作業している場所には、それでも十分に設計された「レガシー」C ++アプリケーションがあります。クライアントは、DBが機能するサーバーと通信するAPIと通信します。すべて賢明に行われました。最近、追加のモジュールが必要でしたが、それを正しく実装するのではなく、開発者がこれを.NETで実装することを決定しました。さらに悪いことに、APIを介したデータへのアクセスは非常に難しいと判断しました（しかし...）DB接続を行うことになります直接。このような混乱がどのように発生するかがわかります。（そして、「良い」を「迅速」に置くTAの同意を得てすべて）

このようなことも以前に見たことがあります。古い場所では、一部の開発者がデータをHTMLで記述してGUIに表示することをお勧めしたため、GUIの小さな部分がHTMLでした。したがって、1つの小さな部分が他の部分と異なる動作をします。

要するに、怠惰は悪く、一貫性は良好です（使用するテクノロジーに関係なく）。MFCやWinforms、WebGLのように、多くの異なるバックエンドアーキテクチャですべてを結び付けたアプリケーションよりも、すべてMFCのアプリケーションが欲しいです。