ソフトウェアが死にかけている兆候は何ですか?
開発者は、ソフトウェアの一部が死に至るのを防ぐための早期警告をどのように見つけますか?
ユーザーの観点からは、非常に明確だと思います。効率的に使用できないものは、廃棄されます。
これとは別に、ソフトウェアはそのコードのために死ぬ可能性があります-アーキテクチャ、コーディングスタイル、コードベースのサイズ、コードベースの編成、およびプログラマーの品質。
ソフトウェアが死んでいく兆候に耳を傾け、是正措置を講じる方法を知りたいです。兆候に耳を傾ける開発者がいなかったため、有名なソフトウェアの例はありませんか? 瀕死のソフトウェアが救われた例はありますか?
次のいずれかは、システムが絶滅危惧種のリストに載っていることを明確に示しています。
プロジェクトの重要性を維持する方法:
死から復活したソフトウェア ライブラリでは、まずObjective-Cにリボンを渡さなければなりません。
気難しい Windows ジョークをここに挿入します。
実際にはいくつかの兆候があります。
これらはすべて、コードのエントロピーが高いこと、つまり信号対雑音比が低いことを示唆しています。
これを攻撃する方法はいくつかあります。おそらく最も効果的な方法は、欠陥率の高いモジュールを特定することです。欠陥はパレート分布に従う傾向があります。つまり、モジュールの 20% が欠陥の 80% を占めます。これらのモジュールのテスト フレームワークを構築し、きれいなページからそれらを再実装し、適切なテストを構築して (必要に応じて単体テスト フレームワークなどを使用して)、それらをシステム全体に戻します。
あなたが心に留めているように見える内部の「技術的な理由」でソフトウェアが死ぬことは比較的まれだと思います。例が思いつきません。たぶん Delphi (死んでいるわけではありませんが、ひどく病んでいるだけです)。
ソフトウェアが死ぬことははるかに一般的であるように思われます。
最初の 2 つの点は、多くの場合、部分的に品質の問題 (市場の変化に対応するのが遅すぎてコストがかかる) のせいですが、後者はそうではありません。
重大なバグはすぐには修正されません。ユーザーの 10% に影響するバグがある新しいバージョンを出荷するとします。すぐに修正して修正版を出荷しないと、これらのユーザーはプログラムを完全に使用できなくなり、代替品を探すことになります。遅延した修正バージョンを最終的に出荷すると、それらはなくなります。
開発者が、ソフトウェアに触れたりサポートしたりしない言い訳をしているとき。
重要な唯一の尺度は、上で参照した「ユーザーの視点」から派生したものです。
最も可能性の高い候補は次のとおり
です。1. サポート リクエストが増加し、
2. 売上が減少します。