ソフトウェアに既知のバグが残っているのはなぜですか？[閉まっている]

多くの場合、大規模なプロジェクトでは、バグトラッカーがバグでいっぱいの状態でソフトウェアがリリースされているようです。機能のリクエストを理解できるようになりましたが、多数のバグがまだ解決されていない、レビューされていない、または完了していないのに、リリースはまだプッシュされています。

どうして？なぜオープンソースプロジェクトまたは一般的なプロジェクトが既知のバグとともにリリースされるのですか？バグトラッカーに未解決のバグが0になるまで待たなかったのはなぜですか？

以下を含むさまざまな理由：

1. 会社は、特定の時間にリリースするユーザーベースにコミットしました
2. バグはミッションクリティカルではなく、重大なものでもありませんでした
3. 新機能の開発は、より重要であると見なされました（正しくかどうか）

これは、プログラミングの知識が「完全」ではないのに、なぜプログラマーとして働くのかを尋ねるようなものです。ほとんどの複雑なプロジェクトでは、非常に多くのバグが発生します。新しい機能を追加しながらそれらに対処することは、困難で複雑な作業です。

バグのあるソフトウェアは、ソフトウェアがまったくないよりも優れているためです。
同じ理由で：

• 運輸会社は、常に遅れがありますが、スケジュールを立てるのは面倒です。
• 製薬会社は、既知の（およびほとんどが文書化された）副作用を伴う医薬品を販売しています。
• 世界中の学校がニュートン物理学を教えていますが、限界が知られています。

既知の欠陥を持つソリューションを持つことは、ソリューションがない、または未知の欠陥を持つソリューションを持つよりもはるかに優れています。
私のお気に入りのIDEには多くの新しい機能がありますが、安定とはほど遠いです。ただ言ってみましょう：私は、20回ごとに手で何かをしなければならないことを好みます。

または、ヴォルテールの言葉でそれを言うには：「ル・ミエスト・エヌ・レミネ・デュ・ビエン」。

最終的には、無料のオープンソースソフトウェアであっても、それはビジネス上の決定です。存在する欠陥の影響が少ないため、リリースし、ソフトウェアをユーザーの手に渡して、フィードバックを取得する方がよい点があります（機能要求や、見つかっていない欠陥の新しいバグレポートが含まれますが、これらに限定されません）テスト中）。この決定は、競合他社の間でソフトウェアの市場で牽引力を獲得する必要性によって推進されます。ソフトウェアに影響を与えたい場合は、競合他社を打ち負かして新機能やコンセプトを市場に出す必要があります。

結局、費用対利益の分析になります。各バグ修正には、それに関連するコスト上の価値があります（修正にかかる工数、リリースX日前により多くのコード変更を行うリスク...）。同時に、各バグ修正は、より多くの機能、使いやすさなどの点で明らかに付加価値をもたらします。

したがって、これはリリースを行うときにすべての開発チームが直面する問題です：1）バグ#iはコストと付加価値を考えると修正する価値があり、2）i = 0からNまでのすべての未解決のバグについて繰り返す

リリースされていないソフトウェア製品は誰にとっても価値がないことに留意してください。200の未解決のバグがあるが、機能の90％が機能しているソフトウェア製品は、リリース時に機能することに満足しているすべての人々に価値があります。

私は、バグがゼロでリリースされた製品でどの会社にも行ったことがないので、それは完全に正常だと思います。ある時点で、損失を削減し、何が機能するかを利用します。そうしないと、何もリリースされません。

大規模なプロジェクトでは、バグの発見を止めることはありません。すべてのバグが修正され、修正が回帰テストされるまで待たなければならない場合、リリースすることはありません。

また、すべてのバグが内部にあるわけではないことに注意してください。すべてのプログラムは他のソフトウェアの複雑なウェブの一部であり、他の場所での変更はソフトウェアの「バグ」として現れる可能性があります。世界を止めることはできません。

多くの良い答えに加えて、時には新製品を市場に出す競争があります。15％（またはその他の数）の重大ではない欠陥が開いていても市場シェアの大部分を獲得できると思う場合、競合他社に勝つために製品をリリースする価値があります。

これらのバグは非常に小さなものです。市販のソフトウェアを出荷し、ディスクなどに押し付ける必要があることを忘れないでください。これらのリリース日を満たすことは財政的に重大な意味があり、いくつかの小さな問題を遅らせることは経済的な意味ではありません。他の理由で市場に出る必要は言うまでもありません。

潜在的な答え：

• 誰もがバグに遭遇することはほとんどありません。
• バグの回避策があります。
• ソフトウェアはいつかリリースする必要があり、完全性は達成されそうにありません。

理想的には、ほとんどの開発者はアプリケーションのバグをゼロにしたいと思っていると思います。残念なことに、このようなユートピアの状態が許されない場合があります。

ユーザーベースが新しい機能を要求し、追加された機能のために同じかそれ以上のバグを喜んで受け入れてくれるからだと信じたい。

経営陣が関与している場合、さまざまな理由で期限を満たす必要があります-広告スケジュール、追加のスタッフの空き状況の問題、「この機能を最初に備えなければならない」という考え方。

おそらく開発者が怠けているために、私の心は楽観的ではありませんか？

また、オープンソースコミュニティでは、通常、「誰」がどのバグ/機能/問題リクエストを引き受けたいと考えていることを忘れないでください。おそらく、背後にあるより大きな問題のために存在する問題に対処したい人はいないでしょう。

最も単純なプログラムによるテスト：

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

バグ、時間/スペース/メモリ、またはセキュリティ/ユーザビリティを修正するかどうかにかかわらず、すべては常にトレードオフです。行われたトレードオフの計算について考えてください。あなたはそれに反対するかもしれませんが、あなたがそれを理解していないなら、あなたは問題を抱えています。

また、これらの計算を鐘型曲線で考えてください。一部の人々は、どちらかの側に本当に悪い計算をするでしょう。曲線の一端については、Duke Nukem Foreverをご覧ください。