バグが5年以上前の場合、それは機能ですか？[閉まっている]

詳細の追加を許可します：私は多くのコーダー、テスター、QAアナリスト、製品所有者などがいる施設で働いています。

私たちは、10年以上にわたって、くだらない（かなり機能的ではあるが）ソフトウェアを販売することができました。多くの機能があり、製品は競争力がありますが、そこには深刻なバグがあり、何千もの「ペーパーカット」があります-クライアントが慣れるのに少し面倒です。

コンピューターが私たちの生活を楽にするのに役立たないなら、私たちはそれらを使うべきではないと固く信じているからです。私は同僚に自信を持っています。彼らは賢く、能力があり、それを行うことに焦点が当てられているときに物事を改善することができます。

しかし、古い機能を閉じたり忘れたりすることなくバグを報告することは困難です。「昔のように機能しました」が典型的な答えです。また、QAがリグレッションを行うとき、彼らは、正しくないように見えるものと同じくらい異なるものを探す傾向があります。したがって、古い問題の修正はバグとして書き出すことができます。なぜなら、「それは私の時間よりも前からそうでした」からです。

私の若いコーダーは考えています：このおかしなことを書き直してください！営業に近い機会があったクライアントとして、私はこのアプローチに疑問の余地を与えたいと思います。

あなたの意見/経験にも興味があります。リスク、費用対効果、およびその他の非技術的要因を考慮してみてください。

あなたの痛みが分かります。

しかし、それがバグであるという理由だけで何かを修正するだけでは十分な理由にはなりません。

あなたの修正が他のコードを壊さないことを確認する必要があります（あなただけでなく、あなたのコードを使用するクライアントのコード）。修正プログラムをプッシュし、これがすべての顧客システムを壊すと、非常に不満を持つ顧客がいることになります。

古いシステムを置き換えるために新しいコードが書かれた有名な例がたくさんあります。ユーザーがそのバグに依存していたために、古いシステムにバグの機能を明示的に追加する必要があった場所（名前は付けませんが、グーグルで検索できると確信しています）。

回帰テストは基本的に、顧客が何を期待するかをテストするものです。回帰テストを削除する前に、誰かを傷つけないことを確認してください（これはほとんど不可能です）。あなたがバグを修正することができる場合と、これは回帰テストを破壊しない、それは本当の修正です。

バグの修正を決定する際に考慮すべきいくつかのこと...決して包括的ではありません。

• それは重要ですか（システムがクラッシュします）？...明らかに修正されます
• 顧客はしばしばそれについて不平を言っていますか？これは、コードで何かが壊れているなどのバグである可能性があります。または、機能がユーザーフレンドリーではない、または異なる動作を期待するなどの要件バグである可能性があります。
• ビジネスの観点から、バグを修正するか、新しい機能を実装する方が有益ですか？
• バグはアーキテクチャの大幅な変更を必要としますか、それとも他のサブシステムに大きく依存しているシステムの一部にありますか？これはテスト時間に大きな影響を与え、バグを検証するために必要なテスト範囲を複雑にしますか？それが本当に古い場合、コードのバグのあるセクションを変更することで、システムに他に何が影響するかを正確に理解するのは難しい場合があります。
• バグのあるシステムのために潜在的な顧客を失っていますか

バグを定義します。「仕様は日付でソートされているが、トランザクション量でソートされている」とは必ずしもコードのバグではありません。それは文書化されていない変更かもしれません-いつかどこかで誰かが並べ替え順序を変更するように頼みましたが、仕様、要件、マニュアル（UIのボタンとラベルさえ）は一致するように変更されず、誰も気にしませんでした。表示して「日付」に戻すと混乱が発生し、UI、仕様、マニュアルなどを更新すると、基本的に「壊れたウィンドウ理論」を除いて時間が無駄になります」

明らかにバグです。このボタンをクリックすると、爆発します。または、月曜日にこのボタンをクリックすると、爆発します。誰かが理由を理解するために時間をかけるようにあなたに任せない限り、あなたは多くの努力を調査に費やすことができます。そして、理由がわかれば、変更できない可能性があります。それは、ユーザーまたは管理者にとってより重要な何かを台無しにするからです。

「だらしない」-メモリリーク、明らかに最適化、インデント、命名規則が必要なコードが必要なコード-あなたが他に何もすることがないときに、または自分の時間にemを修正するのは非常に魅力的です。ただし、これらの「修正」は、ソース管理の歴史をほとんどまたはまったく利益を台無しにします。「生産で使用しているバイナリが失われたコードから構築されたため、そのモジュールをコンパイルすることはありません。そして、あなたが「修正」している「間違い」をしている人々をひどく混乱させることができます。

上司と一対一で対応することをお勧めします。何があなたを悩ませているのかを説明してください-それはコーディングスタイルですか、ユーザーを悩ませる必要があると確信していること、不正確な数、矛盾、または災害が起こるのを待っていますか？次に、方向を尋ねて（これが重要です）それを取る。

古いバグを修正したい場合は、既存の機能を壊さないように注意する必要があります。単体テストがある場合、これは簡単ですが、会社とソフトウェアの暗黙の年齢を考えると、それらは存在しません。副作用を最小限に抑えながら、バグを適切にリファクタリングして修正する方法について説明しているため、Martin Fowlerによるリファクタリングの本を読むことをお勧めします。また、通常の時間に古いバグを経験しても問題ないことを確認することをお勧めします。彼らはあなたが時間外にそれを行う場合にのみこれを行うことができます。

また、バグが機能になった場合、つまり何かを提供するためにクライアントによって実際に使用される場合、その動作が必要なときに適切な代替を提供するようにしてください（またはバグではなく機能として文書化してください）。