ユーザーが機能だと思ったバグをどう扱うか？
質問：
エンドユーザーが機能だと思ったバグに対処する適切な方法は何ですか？
詳細：
かなりの割合のユーザーが機能として期待している場合は、より安定させるために「未修正」または「修正済み」のままにしておくべきでしょうか？ただし、ごく一部のユーザーが機能であると期待している場合はどうなるでしょうか。0.1％または1％と言ってください。このバグは修正する必要があります。
理論的には、これはマイナーなバグ修正であるため、セマンティックバージョニングによって考慮される場合、PATCHと見なされる可能性があります：x.y.Z。ただし、下位互換性が失われるため（たとえ数人のユーザーであっても）、大幅な増加になるはずです：X.y.z。正しい？それが文書化されている限り、それはまだ（機能として意図されていなかったため）PATCHとしての資格がありますか？
編集：この特定のケースでは、他の開発者が使用する内部的に使用されるライブラリのAPIのバグです。
かなりの割合のユーザーが機能として期待している場合は、より安定させるために「未修正」または「修正済み」のままにしておくべきでしょうか？
バグは価値をもたらしますか？もしそうなら、それはより多くの機能です。 「バグ」は、付加価値のある「機能」となる場合があります。
個々の状況はそれぞれ異なるため、これを明確に答えることは困難です。
この特定のケースでは、他の開発者が使用する内部的に使用されるライブラリのAPIのバグです。
この場合、下位互換性に関する次の重大な変更の一部として修正を含めます。あなたすることはできませんほんとうにほとんどの環境で一貫してこれを行うだけで、おそらくこのためのスケジュール/タイムフレームがあります。
開発者として私が最後に対処したいのは、動作が不正確または一貫性のないAPIです。バグはこれと見なされます。
少なくとも、ある種の「現在のバージョンの既知のバグ」ドキュメント/ wikiを内部で作成してください。そうすることで、すべての内部ユーザーが機能がバグに似ていることを確実に知ることができます。うまくいけば、人々が機能としてバグを使用している領域をカバーする十分なテストができるので、バグをいつ、どこで、いつバグが修正されるかがわかります。
より安定させることをお勧めします。ユーザーは、ソフトウェアの機能の標準的なソースです。彼らがそれを望み、それに頼るようになったなら、私はそれをヤンクすることについて二度考えます。
この良い例は、ビデオゲーム「Tribes」の「スキー」メカニックです。もともとは、物理エンジンが丘でのジャンプをどのように処理するかに関するバグでしたが、結局はコアゲームのメカニズムの1つになりました。あなたはそれについてもう少し読むことができます ここ 、興味があれば。
バグはライブラリにあるため、次の方法を使用できます。
エラーのあるライブラリ関数のクローンを作成します。多くの場合、人々は
2これらの場合は関数名に変更しますが、その関数のインターフェースに適用したいその他の変更がある場合は、完全に異なる名前を付けることもできます。クローンのみのバグを修正します（そして、作業中に必要な他のすべてのインターフェース変更を実装します）。
元の関数を非推奨として宣言します。
今後のメジャーリリースで元の機能を削除します。
このアプローチは、インターフェイスが根本的に壊れている関数に特に役立ちます。ユーザーコードはすぐには壊れませんが、壊れたコードに依存している人には修正済みコードの使用に移行するよう警告します。そして、人々が警告に耳を傾けなくても、あなたが実際に壊れた機能を取り除くと、彼らはあなたを本当に非難することができません。
この特定のケースでは、他の開発者が使用する内部的に使用されるライブラリのAPIのバグです。
それらの他の開発者がその振る舞いを機能であると考えた場合、それらを使用し、その上にworking softwareをビルドした可能性があります。バグを修正すると、おそらく既存のコードが壊れてしまい、これはあなたのせいです。これにより、バグの修正はトレードオフになり、考慮する必要があります
たとえば、バグが修正されない場合、APIのユーザーがアプリケーションをクラッシュさせる危険性が高いため、バグを修正することは本当に重要ですか？それともAPIの一貫性についてですか？
または、既存のソフトウェアを安定させて、ライブラリに下位互換性を持たせる方が重要ですか？
質問への回答は必ずしも単純ではありません。APIの可能なユーザーの数、ソフトウェアを変更する必要のある潜在的な作業量、APIを変更すると中断するソフトウェアの量を考慮に入れる必要がありますを使用した場合に発生する可能性のあるリスクnot APIを修正します。
「次のメジャーリリースでの重大な変更のリスト」にバグ修正の変更を文書化したからといって、顧客が満足するわけではありません。これを行うと、APIをそのままにできなかった理由を説明する少なくともいくつかの箇条書きが必要になります。前だった。多くの場合、下位互換性を維持することは、バグを修正することよりも重要です。したがって、ユーザーベースとそのソフトウェアへの影響を見積もることができ、ユーザーが最新のライブラリリリースに更新しようとしたときに不当な努力をすることがないことが確実な場合にのみ、修正してください。そして、これを適切に見積もるのに十分な情報がない場合は、動作を変更しない方がよいでしょう。
（もちろん、後方互換性のないAPIの変更を行う場合、バージョン番号はこれを明確に表現する必要があり、「バグ修正」と名付けても関係ありません）。
それを受け入れる。それはあなたの製品全体を作ることができます。
GunZ：The Duel（オンラインゲーム）にはバグがあり、それを悪用して絶えず悪用することで、ゲームプレイ全体（K-Styleと呼ばれます。YouTubeで調べてください）のほとんどを変更することができます。それはゲーム全体をより挑戦的なものにしました。それはスキルを取り、それをただ素晴らしくて楽しいものにしました...モデレーターでさえ彼らのメインプレイスタイルとしてそれを公然と使用するほどとても楽しいものでした。
それがゲームを作ったものです。
私は何年もプレイしていませんでしたが、今日までゲーマーとして、これは私のお気に入りのゲームの1つです。バグ。
彼らは最終的にそれを修正しましたが、人々はそれをあまりにも嫌っていたので、開発者たちはそれを真剣にバグ修正しました。
だから私の答えはそれを安定させて維持することです（必要ならばリファクタリングしてください）。
その美しい物語が言われているので、直接的な利点がないものには同じ答えが当てはまるとは思いません。バグが利点をもたらすイベントを引き起こす場合、通常はバグを修正し、それが可能なことを達成する別の方法を見つける方が賢明です。範囲外の場合は、範囲外であるために除外することを検討するか、別のモジュール（おそらく小さなモジュール）を作成して導入します。基本的に： 単一責任の原則 に違反しないでください。