フィーチャー膨らみのようなものはありますか？

表現ソフトウェア/機能の膨張に遭遇しましたが、これは本当のことですか、それともパフォーマンスの問題、メモリとディスクのフットプリント、ユーザーエクスペリエンス、オンデマンドインストールなどについて話すべきでしょうか？ここで何が欠けていますか？

私の経験では、機能の膨張は直接的な問題ではなく、問題の根本的な原因であるため、個別に考えると便利です。

元の質問にリストされているエンドユーザーの潜在的な問題に加えて、機能の膨張は、かなりのメンテナンスコストを伴う可能性があります。新しい機能を追加するときは、その機能の開発コストだけでなく、製品の寿命にわたって維持することも重要です。よく言われる経験則では、機能に費やされる時間は20％の開発と80％のメンテナンスですが、現実の世界では、機能の複雑さと他の機能との相互作用の度合いによって大きく異なります。

これには2つの意味があります。

まず、技術的な欠点ではなく、ユーザーエクスペリエンスについてです。不要な機能により、ユーザーがアプリケーションを理解することが困難になります。ユーザーはアプリケーションが複雑すぎると認識し、基本的なことを行う方法がわかりません。

2つ目は、あまり使用されない機能が多すぎると、メモリとディスクのフットプリントの点でソフトウェアが肥大化することです。そのため、多くのアプリケーションでは、代わりにプラグインがあり、実際に使用する場合にのみインストールできます。

非常によく似た用語は「機能クリープ」です。vartecの答えは「機能拡張」のより良い説明ですが、「機能クリープ」の意味も知っておく必要があります。

基本的に、プロジェクトが進化するにつれ、多くの機能がプロジェクトに追加される傾向があります。変更と拡大を続けるプロジェクトを完了することは不可能であるため、これは深刻な計画上の問題になります。

「機能膨張」がユーザーエクスペリエンスの問題の詳細を暗示する場合、「機能クリープ」はスケジューリングの問題の詳細です。

ソフトウェアの膨張と機能の膨張は2つの異なるものだと思います。

特定の機能は少ないコードで実装できるため、原因ではなく機能ではなくソフトウェアが原因です。開発者は、要求されていない機能を追加しないように常に注意を払う必要があります。

ユーザーの要求の数を一気に飛び越えたくなります。確かに、利用可能な開発リソースに対して多くのことを尋ねることはできますが、プログラマーはしばしば独自の機能を追加します。開発者はバズーカを蚊狩りに連れて行く傾向があります。

1990年代の終わり頃、Microsoft Excelには「国際的な」通貨記号をフォーマットされた数値に追加するための少なくとも3つ、そして私は4つの相互に互換性のない方法があり、それぞれが独自の個別のUIでアクセスしていました。

つまり、そうです、「機能の肥大化」は確かに存在します。