バグを修正しますか、それともお客様がバグを見つけるのを待ちますか？
他の人がバグを見つけたら修正するのでしょうか、それとも、クラッシュ/データ損失/人が死ぬまで待ってから修正しますか？
例1
Customer customer = null;
...
customer.Save();
コードは明らかに間違っており、回避策はありません-null参照でメソッドを呼び出しています。 Saveがインスタンスデータにアクセスしないため、クラッシュしません。つまり、静的関数を呼び出すようなものです。しかし、小さな変更がどこかにあると、突然、クラッシュしないコードが壊れて、クラッシュし始めます。
しかし、コードを修正することも考えられないではありません。
Customer customer = null;
...
customer = new Customer();
try
...
customer.Save();
...
finally
customer.Free();
end;
クラッシュする可能性があります導入;完全なカバレッジのユニットテスト、および手動のユーザーテストでは発見されなかったもの。
例2
float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);
物理学を知っている人々は、それがRであることになっていることを認識するでしょう2 分母に。
コードは間違っています、それは完全に間違っています。速度を過大評価すると、レトロロケットの発射が早すぎて、宇宙船のすべての乗員が死亡します。
しかし、速度を過大評価していることで別の問題が隠されている可能性もあります。シャトルの移動速度が速すぎると、エアバッグが展開できなくなります。コードを突然修正した場合：
float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);
これで速度が正確になり、エアバッグが予期しないときに突然展開します。
例3
文字列に無効な文字が含まれているかどうかを確認している最近の例を次に示します。
if (StrPos(Address, "PO BOX") >= 0)
{
//Do something
}
Do somethingブランチにバグがあることが判明した場合はどうなりますか？明らかに正しくないコードを修正する：
if (StrPos("PO BOX", Address) >= 0)
{
//Do something
}
コードを修正しますが、バグが発生します。
私の見方では、2つの可能性があります。
- コードを修正し、それを壊したことで非難される
- コードがクラッシュするのを待ち、バグがあると非難される
あなたは政治的に何をしますか？
例4-今日の現実のバグ
オブジェクトを作成していますが、間違ったコンストラクタを呼び出しています。
Customer customer = new Customer();
「パラメーターなし」コンストラクターは、実際には継承チェーンの後方からのパラメーター化されたコンストラクターであることがわかります。
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
後続のすべてのコンストラクタをバイパスするため、これを呼び出すのは誤りです。
オブジェクトの系統を変更して、このような危険なコンストラクターを公開しないようにすることもできますが、コードを次のように変更する必要があります。
Customer customer = new Customer(depends);
しかし、私はこの変更が何も壊さないことを保証することはできません。上記の例1のように、おそらく誰かが、どこか、何らかの方法で、難解な状況の下で、構築されたCustomerが無効であり、ジャンクでいっぱいであることに依存しています。
おそらくCustomerオブジェクトが適切にに構築されたため、以前は実行できなかったコードを実行できるようになり、クラッシュする可能性があります。
私はあなたの妻の人生をそれに賭けることはできません。
そして、私はここから火曜日までそれをテストすることができます、私は回帰を導入しなかったあなたの娘の人生を誓うことができません。
私は：
- コードを修正して、それを壊したことで非難されますか？または
- バグを残して、顧客が見つけたときに非難されますか？
これは状況、バグ、顧客、および会社に大きく依存します。実装の修正と潜在的に新しいバグの導入との間には、常に考慮すべきトレードオフがあります。
私が何をすべきかを決定するための一般的なガイドラインを与えるとすれば、それはこのようなものになると思います：
- 選択した追跡システムに欠陥を記録します。必要に応じて、経営者や同僚と話し合います。
- それが潜在的に悲惨な結果を伴う欠陥である場合（例＃2など）、権限のある人に通知されるまで実行、悲鳴を上げ、上下にジャンプし、バグ修正に関連するリスクを軽減する適切な行動方針を決定します。これにより、リリース日が押し戻されたり、命が救われたり、ウィンドウが洗浄されたりする場合があります。
- それが重大な欠陥ではない場合、または回避策が存在する場合は、修正のリスクが修正の利点よりも重要かどうかを評価します。状況によっては、100％必要ではないのに修正や再テストに時間を費やしていないことがわかっているので、お客様から提示されるのを待つ方が良いでしょう。
ご注意ください。これは、リリースの近くにいる場合にのみ適用されます。完全な開発モードの場合は、欠陥をログに記録して、追跡して修正し、完了したと見なします。修正して確認するのに30分以上かかる場合は、マネージャーまたはチームリーダーに連絡して、不具合が現在のリリースサイクルに収まるか、または後で予定するかを確認します。
お客様は常にバグを発見します。顧客からバグを隠すことはありません。結局、あなたが導入するバグは常にあなたに戻ってきます。それらを修正しないことは、単に悪い専門的な習慣です。専門家はこれを行いません。
顧客がバグを見つけると、会社は個人の開発者ではなく、見た目が悪くなります。これは会社にとってははるかに悪いことなので、変更を加える必要があります。他のバグの導入を恐れてこの変更を行うかどうか本当にわからない場合は、より上級の開発者、プロジェクトテクニカルリード、またはそのような変更について決定を下し、その後の結果を処理する立場にある誰かに相談してください。
バグを修正
私たちはここで専門家です。クラッシュまたは不正な動作を引き起こすコードの失敗したパスを見つけた場合は、修正する必要があります。チームの手順によっては、欠陥を提出し、おそらく回帰テストを作成し、出荷サイクルの適切なタイミングで修正をチェックインする必要があります。優先度の低いバグの場合は、マイルストーンの最初の方で修正をチェックインすることは常に良いタイミングです。なぜなら、リグレッションを引き起こしても、マイルストーンのリリースサイクルには影響しないからです。
これを、パフォーマンスのバグに関連しないリファクタリングやパフォーマンスの改善と混同しないでください。
「小さなバグ修正」の個別のリポジトリを保持し、マイルストーンの最初に簡単にマージできる分散型ソース管理システムは、ここで非常に役立ちます。
お客様の意見は？
これが私がこのプレイアウトを想像する方法です：
お客様：xを実行するとクラッシュします。
プログラマ：そうそう！しばらく前に見たのを覚えています。まだ大したことではないと思ったので、そのままにしておきました。
お客様：[鈍いオブジェクトに到達]
はい。バグを修正します。顧客を悪化させる経験から救い、緊急事態になる前に修正することができます。
そして、もしあなたのフィックスが実際にクラッシュを引き起こすかもしれないと思うなら、あなたはまだフィックスをまだ見つけていません。
あなたが与えたすべての例は、共通のスレッドを持っているようです。完全に理解していないバグを修正したいようです。あなたがそれぞれに意図しない結果をもたらす可能性があることに気付いたからです。
それはおそらく大きな間違いだと思います ベンローリーは書いていますあなたが理解していないバグを修正しないでください。この有名な例では、Debianチームは、分析ツールの結果を追跡したときに、DebianおよびUbuntuなどの派生物のOpenSSLの暗号化を破りました。
コードを調べて欠陥があると思われる場合は、顧客が確認できる方法で欠陥を再現できることを確認してください。できない場合は、リソースを費やして他の何かを修正しないでください。
できるだけ早く技術的負債を削ぎ落とし始めます。
あなたの例は間違いなくレガシーコードのようになり、たくさんの技術的負債と変化への恐怖があると思います（ところで、これは批判でも判断でもありません）。チーム全体が、あなたがこの技術的負債を抱えていることを認めなければなりません（そのため、あなただけがそれを非難されません）。そして、あなたはそれをどう処理するかを決めることができます。
例1では、Save()がインスタンスデータにアクセスしない場合、どの顧客データを正確に保存しますか？修正とテストを開始します。
例2では、速度計算機をテストでカバーし、すべての主要な例で正しい結果が計算されることを確認するのは簡単です。
例3では、死んだコードを復活させる危険があります。そのコードを完全に削除する必要がありますか？その場合のブール条件の意図は何ですか？文字列に無効な文字が含まれていないことを確認するためですか？または、「PO BOX」が含まれていることを確認するには？そのような質問に取り組むのが早ければ早いほど、より良いです。
このような問題をいくつか修正したら、チームで一種の回顧的/事後分析を行います。将来、欠陥注入率を低減できるように、この経験から学ぶことが重要です。
あなたはすでに良い答えを持っています。何かがクラッシュするのではないかと恐れる問題について追加します。
まず、理想的な状況では、ソフトウェアはモジュール化されており、正しく設計されており、懸念事項が適切に分離されています。この場合、関連するすべてのコードを制御でき、予期せぬ事態が発生しないため、行った変更によって何かが破壊される可能性はほとんどありません。
残念ながら、理想的な状況は架空のものです。カップリングがどの程度緩んでいるかに関係なく、カップリングが存在するため、他のものが破損する可能性があります。
これに対する解決策は2つあります。
- コードをできる限り構造化します。
- コードが十分に分離されていて、他に何も壊れないことがわかっている場合は、修正します。
コードを適切に構造化することは、コード全体を新しいアーキテクチャ設計に書き直すことによって行われない。むしろ、テストによって導かれるrefactoringはここであなたの友達です。このステップでは、機能を変更しません。
2番目のステップは、バグを修正することです。
いくつかの点が関連しています：
- このプロセスにはバージョン管理が絶対に必要です。
- リファクタリング手順とバグ修正手順は、別々のコミットとしてバージョン管理にコミットされているため、それぞれに明確に定義された履歴機能があります。
- 別のバグを作成する可能性に固執しないでください。何も実行されません。むしろ、コードを改善することを考えてください。言い換えれば、バグを減らすのではなく増やすことを知っているのでなければ、それを行うべきです。
- 最後の点に関連して：未来を予測しようとしないでください。人間は予測が非常に得意であると考える傾向があります。実際には、予測力は短期です。したがって、漠然とした未定義の将来のバグについて心配する必要はありません。これは [〜＃〜] yagni [〜＃〜] の背後にある原理でもあります。
- バグの世界でバージョン管理に対応するツールは、バグトラッカーです。それも必要になります。
- あなたは2つの理由でバグを修正する必要があります。顧客を満足させるため。そして、あなたの開発を進めることができるようにするために。例3（物理的なもの）を使用するには：プログラムがこのような壊れた方程式で顧客を満足させる場合、このバグを軽減するために誤って開発されたソフトウェアの他の多くの部分があります（たとえば、エアバッグの展開）。このソフトウェアにバージョン2（または1.1）が必要な場合、この障害のあるコードに基づいて正しいコードを開発することがますます難しくなります。その後、あなたは大きな書き直しに向かっているか、大きな失敗に向かっています。どちらも避けるべきです。
これらはすでにいくつかのポイントを超えているので、ここで止めます。
まず、バグの定義を考慮する必要があります。
- 読み取ったコードが正しいと思われるコードと一致しない
- ソフトウェアがタスクを適切に実行しない
あなたは＃1に焦点を合わせているようですが、＃2は座るのに最適な場所です。もちろん、プログラマーはコードをright（＃1）にしたいと思っていますが、人々はそれをwork（＃2）に支払っています。
誤って新しいバグを導入する可能性があるコードベースに対して実行することもしないことも、＃2の現在のソフトウェアの見方とは無関係です。ただし、＃1は自分自身またはその後のメンテナンスプログラマにとって重要です。決定が難しい場合もありますが、＃2と＃1が競合する場合は、＃2の方が明らかに重要であることを知っておく必要があります。
どちらでもない。 3番目の方法があります。「問題のあるコード」が実際にビジネスの観点から問題を引き起こしていることを証明する方法を見つけます。見つけたものをBA/QAまたは少なくとも上司に確認します。次に、全員が問題に気付いたときに修正を計画します。
あなたが言及したケースでは、有効なバグ以外に考えられるシナリオがもっとあります：
- あなたが見ているコードはいくつかのデッドコードです。それはおそらくysolikが言ったようにです：顧客は常にバグを見つけます。そうでない場合は、コードが実行されない可能性があります。
- 明らかなエラーに目的があるWTFの状況がありました。 （私たちは生産コードについて話していますが、何かが起こった可能性がありますよね？）
- ビジネス/顧客は問題をすでに知っていましたが、修正の必要性を感じていません。
- 多分もっと...
上記のいずれの場合でも、私がマネージャーである場合、開発者が彼/彼女の判断を使用して「エラー」を修正することを望みません。エラーを適切に修正することでほとんどの場合は問題が解決する可能性がありますが、エラーが発生した場合は、意図した以上のトラブルが発生する可能性があります。
I：
- コードを修正して、それを壊したことで非難されますか？または
- バグを残して、顧客がそれを見つけたときに非難されますか？
バグを修正し、単体テストを開始し、テストが成功したら修正をチェックインします。
（または、単体テストに非常に長い時間がかかる場合は、最初に修正をチェックインし、コミットが壊れたためにCIツールがメールを送信するかどうかを待ちます。）
クラッシュ/データ損失のバグの場合は修正してください。既知のデータ損失バグのあるプログラムを出荷することは実に悪意があり、言い訳のできないことです。
バグが表面的なものであるか重大でない場合（回避できる場合）は、それを文書化し、回避策を提供する必要があります。理想的には修正する必要がありますが、現在のリリースで修正するにはコストがかかりすぎる場合があります。
大きなソフトウェアプロジェクトごとに、ReadMeに「既知の問題」セクションがあり、通常は次のように正確にリストされています。既知のバグ。
バグを知り、それらを伝えないことは、ほんのわずかな/表面的なバグの場合のみ許容されます。
修正してテストしてください。さらに多くのバグを見つけるのが怖いという理由だけで既知のバグを保持することにした場合、プログラムは時限爆弾の刻々と変化する地雷原になり、思ったより早く修復不能になるでしょう。
あなたはマスターであり、コードは従属であるため、それが間違っているとわかったときに、それを変更することを恐れないかもしれません。コードへの恐怖（「どこかで壊すことで報復する可能性がある」）は受け入れられません。
正しい行動は、バグを無視することでも、その場で「修正」することでもありません。あなたがあなたの質問で特定したまさにその理由のために。
最初にコードを理解してみてください。表示されているコードにある程度の年齢があり、「バグ」に誰も気付いていない場合は、その理由が考えられます。この理由を見つけてください。これは、決定を下す前に私が見ておきたいことです。
履歴：バージョン管理ソフトウェアを使用して、質問に答えます。コードに触れたのは誰ですか？彼らは何を変えましたか？そして、どのコミットメッセージでそれをチェックインしましたか？コードがそのように見える理由を推測できますか？
使用：欠陥のあるコードを使用するコードは何ですか？そしてどうやって？コードは死んでいますか？問題のある動作に依存する他のコードはありますか？
作成者：上記の情報を使用してもすぐに結論に到達できない場合は、コードの作成者に（少なくともそれが可能であれば）、コードがどのように見えるのか尋ねてください。通常、「Oups、それは修正する必要があります！」または「いいえ！変更しないでください!!!それはそのように必要です！」直ちに。
明らかにクラッシャーまたは何かwrongがある場合は、修正する必要があります。仕様に曖昧な点がある場合、つまり「よくお客様に可能性があるこれを期待しているが、それはそのように見える可能性があるバグである」または問題と思われる場合仕様では、「これを実行するように求められましたが、それはうんざりします」のように、何をすべきかを見つける必要があります。壁を越えてコードを投げて顧客のフィードバックを待つのは悪いことです。製品マネージャがある場合はそれを尋ねるか、製品を展開する前に顧客に尋ねるかもしれません。
「その問題については知っており、将来のリリースで修正する」とは、「その問題については知っているが、対処するのを避けるほど十分に気にしない」ことと同義であることを覚えておいてください。