ユーザーが機能だと思ったバグをどのように処理しますか？

質問：

エンドユーザーが機能だと思ったバグに対処する適切な方法は何ですか？

精緻化：

かなりの割合のユーザーが機能として期待している場合、より安定させるために「未修正」または「修正済み」のままにしておくべきだと思いますか？ただし、ユーザーのごく一部が0.1％または1％などの機能であると期待している場合は、このバグを修正する必要があります。

理論的には、これはマイナーなバグ修正であるため、セマンティックバージョニングで考慮されるようにPATCHとして認定できます：xyZ それが文書化されている限り、（機能として意図されていないので）PATCHとしてまだ資格がありますか？

編集：この特定のケースでは、他の開発者が使用する内部使用ライブラリのAPIのバグです。

かなりの割合のユーザーが機能として期待している場合、より安定させるために「未修正」または「修正済み」のままにしておくべきだと思いますか？

バグは価値を高めますか？もしそうなら、それは機能の詳細です。時々、「バグ」が付加価値の「機能」になることがあります。

個々の状況はそれぞれ異なるため、これを最終的に答えることは困難です。

この特定のケースでは、他の開発者が使用する内部使用ライブラリのAPIのバグです。

この場合、後方互換性に関する次の重大な変更の一部として修正を含めます。ほとんどの環境でこれを一貫して行うことはできません。これにはおそらくスケジュール/時間枠があります。

開発者として最後に対処したいのは、動作が正しくないか一貫性のないAPIです。バグはこれと見なされます。

少なくとも、何らかの「現在のバージョンの既知のバグ」ドキュメント/ wikiを内部で作成し、すべての内部ユーザーが機能がバグのようなものであることを確認できるようにします。バグを機能として使用している領域をカバーする十分なテストがあれば、バグを修正したとき/いつ/どこで問題が発生するかを確認できます。

より安定させることをお勧めします。ユーザーは、ソフトウェアが行うことの標準的なソースです。彼らがそれを望み、それに依存するようになったなら、私はそれをヤンクすることについて二度考えます。

これの良い例は、ビデオゲーム「部族」の「スキー」メカニックです。もともとは、物理エンジンが丘でのジャンプを処理する方法のバグでしたが、最終的にコアゲームメカニクスの1つになりました。興味があれば、ここでそれについてもう少し読むことができます。

バグはライブラリにあるため、次の方法を使用できます。

1. エラーのあるライブラリ関数のクローンを作成します。多くの場合2、これらのケースでは関数名にa を追加するだけですが、その関数のインターフェースに適用したい他の変更がある場合、完全に異なる名前を付けることもできます。

2. クローンのみのバグを修正します（そして、あなたがそれにいる間、あなたが望む他のすべてのインターフェースの変更を実装します）。

3. 非推奨として元の関数を宣言します。

4. 今後のメジャーリリースで元の機能を削除します。

このアプローチは、インターフェイスが根本的に破損している関数に特に役立ちます。ユーザーコードをすぐに破損することはありませんが、固定コードの使用に移行するために破損したコードに依存しているユーザーには正当な警告を与えます。そして、たとえ人々が警告に注意を払わなくても、壊れた機能を実際に削除してしまえば、彼らはあなたを非難することはできません。

この特定のケースでは、他の開発者が使用する内部使用ライブラリのAPIのバグです。

他の開発者がこの動作を機能だと考えた場合、おそらくそれを使用し、その上に動作するソフトウェアを構築している可能性があります。バグを修正すると既存のコードが壊れる可能性があり、そのせいであなたを責めます。これにより、バグの修正がトレードオフになります。

• たとえば、バグが修正されていない場合、APIのユーザーがアプリケーションをクラッシュさせる可能性が高いため、バグを修正することは本当に重要ですか？それとも、APIの一貫性についてですか？

• または、既存のソフトウェアを安定させ、ライブラリの下位互換性を維持することがより重要ですか？

質問への答えは必ずしも単純ではありません。APIの可能なユーザーの数、ソフトウェアを変更する必要のある潜在的な作業量、APIを変更すると破損するソフトウェアの量を考慮する必要があります。 、しかしあなたがそうする場合に起こるかもしれないことのリスク、APIを修正ないあります。

バグ修正の変更を「次のメジャーリリースの重大な変更のリスト」に文書化するだけでは、顧客を満足させることはできません。これを行う場合、APIをそのままにしてはいけないという理由が少なくともあるはずです前だった。多くの場合、後方互換性を維持することは、バグを修正するよりも重要です。そのため、ユーザーベースとそのソフトウェアへの影響を推定でき、ユーザーが最新のライブラリリリースに更新しようとしたときに不当な努力をしないと確信している場合にのみ修正してください。そして、これについて適切な推定を行うのに十分な情報がない場合は、おそらく動作を変更しない方が良いでしょう。

（そして、はい、後方互換性のないAPIの変更を行う場合、バージョン番号はこれを明確に表現する必要があり、「バグ修正」と名付けるかどうかは関係ありません）。

それを受け入れます。それはあなたの製品全体を作ることができます。

GunZ：The Duel（オンラインゲーム）には、ゲームプレイ全体（Kスタイルと呼ばれる、YouTubeで調べてください）全体を変更するために悪用し、常に悪用できるバグがありました。ゲーム全体をより困難なものにしました。それはスキルを必要とし、驚くほど楽しいものになりました。とても楽しかったので、モデレーターでさえも、それをメインのプレイスタイルとして公然と使用していました。
それがゲームを作った理由です。
私は何年もプレイしていませんでしたが、今日まで、ゲーマーとして、それは非常にスキルベースでとても楽しいので、これはすべての時間の私のお気に入りのゲームの1つです。

彼らは最終的にそれを修正しましたが、人々はそれを嫌い、開発者は真剣にバグを取り戻しました。

したがって、私の答えは安定化と維持です（必要に応じてリファクタリング）。

言われているその美しい物語、私は同じ答えが直接の利点を持たないものに当てはまるとは思わない。バグが利点をもたらすイベントを引き起こす場合、通常はバグを修正し、可能な限り何でも達成する別の方法を見つける方が賢明です。範囲外の場合は、範囲外にあるためだけに除外することを検討するか、別のモジュール（おそらく小さなモジュール）を作成して導入します。基本的に、単一の責任原則に違反しないでください。