バグを修正するか、顧客がバグを見つけるのを待ちますか?


35

他の人はバグを見つけたときに修正しますか、それともクラッシュ/データ損失/人が死ぬまで修正を待つのですか?

例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オブジェクトは、以前は実行されなかったコードを実行できるようになり、クラッシュするようになりました。

あなたの妻の人生に賭けることはできません。

そして、私はここから火曜日までそれをテストすることができます、私は回帰を導入しなかったあなたの娘の人生を誓うことができません。

私は:

  • コードを修正し、それを破ったと非難される?または
  • バグを残して、顧客がそれを見つけたときに非難される?

33
何かを壊す可能性があるために何かを変更したくない場合、コードの他の部分で何が起こるかを見るために自分自身を資格がないと考えている場合、ここで何をしていますか?書こうとしているコード行が間違っている可能性があるため、キーボードを麻痺させていますか?
デビッドソーンリー

3
確かによく研究された質問
ムハンマドアルカウリ

2
「Do Something」は、多くの場合、作成した他の関数またはライブラリからの関数の呼び出しです。いずれの場合も、コードはユニットテストされている必要があります。手順自体もユニットテストされており、非常に低いものを修正するときに新しいバグが導入される可能性があります...ブリッジを構築する場合、ブリッジの上を歩く人を死なせるのではなく、最初に小規模でテストします。バグが心配のときに単体テストを実行していない場合、それは間違っています。いずれにせよ、それを修正するのは非難されるので、修正する代わりにそれを防ぐことができ、まったく非難されることはありません。
タマラウィスマン

2
「それを修正する前に人々が死ぬまで待ってください」!聖なる牛、私は真剣にこれに対する唯一の答えは...そこにあると思います
クリス・ナイト

3
あなたが言ったことの1つについて具体的にコメントとして:あなたはコードの他のどこかで、彼らが難解な振る舞いに依存しているかどうかわからない:そう?誰かが明らかに不正なスコープルールをコードのハッキングとして悪用している場合、そのコードは間違っています。良いOOPはそのバグを防いでいたでしょうが、悪い慣習を使用して問題を悪化させ、さらなる悪用のためにそれを開いたままにして、システムをずっと不安定にしてしまうので修正しません。バグを修正し、テストが問題をキャッチすることを望み、もしそうでない場合はさらにバグを修正します。製品の長期安定性は重要な指標です。
CodexArcanum

回答:


34

これは、状況、バグ、顧客、および会社に大きく依存します。実装を修正することと、新しいバグを導入する可能性との間には、常にトレードオフがあります。

何をすべきかを判断するための一般的なガイドラインを提供する場合、次のようになります。

  1. 選択した追跡システムの欠陥を記録します。必要に応じて、管理者や同僚と話し合います。
  2. 悲惨な結果を招く可能性のある欠陥(例#2など)の場合は、実行、叫び、ジャンプして上下に権限のある人物に通知し、バグ修正に関連するリスクを軽減する適切なアクションを決定します。これにより、リリース日が押し戻されたり、命を救ったり、窓を洗ったりする場合があります。
  3. それが非破壊的な欠陥である場合、または回避策が存在する場合、それを修正するリスクが修正の利益を上回るかどうかを評価します。状況によっては、顧客がそれを提示するのを待つ方が良いでしょう。なぜなら、100%必要ではないときに物事の修正/再テストに時間を費やしていないことがわかっているからです。

気を付けてください、これはリリースに近いときにのみ適用されます。完全な開発モードの場合は、欠陥をログに記録して、追跡して修正し、完了したことを確認できるようにします。修正と検証に30分以上かかる場合は、マネージャー/チームリーダーに行って、欠陥が現在のリリースサイクルに収まるか、後で予定されるかを確認します。


本当です。そのため、(一部の)企業には技術マネージャー、バグクロールなどがあります。物事に優先順位を付けるためです。私はイニシアチブをとらないと言っているわけではありません-まったくそうではありません-しかし、あなたは良い判断をしなければなりません。間違ったタイミングで間違ったイニシアチブをとることは「ゆるい大砲であること」と呼ばれ、会社を殺す可能性があります。また、特定のバグの重要性は会社によって異なります。一部のプログラムでは、ダイアログボックスのタイプミスは、将来のリリースで修正される低優先度の化粧品のバグであり、他のプログラムでは停船中の緊急事態です。
ボブマーフィー

6
欠陥を記録する場合は+1。その他の欠陥が優先...かかる場合があります
SHug

35

顧客は常にバグを見つけます。顧客からバグを隠すことはありません。最後に紹介するバグは、常にあなたに戻ってきます。それらを修正しないことは、単に悪い専門的な習慣です。専門家はこれを行いません。

顧客がバグを見つけたとき、会社は見た目が悪く、個々の開発者ではありません。これは会社にとって非常に悪いことなので、変更を行う必要がある場合があります。他のバグの導入を恐れてこの変更を行うことについて本当に確信がない場合は、より上級の開発者、プロジェクトの技術リーダー、またはそのような変更について決定を下し、結果を処理する立場にある他の人に相談してください。


2
それは悲しい真実です。テストしたプロジェクトを狂ったように提供しなければなりませんでしたが、それでも顧客は3分以内にそれをクラッシュさせることができました。
オリバーワイラー

4
@Helperメソッド:もしあなたが正気な人々のようにそれをテストしたなら、それはもっと良かったでしょう。
ビンコヴサロビッチ

@Helperメソッド:より深刻なことですが、実際に3分だった場合、これはテスターが顧客が期待する実際のユースケースを知らなかったように見えます。
ビンコヴサロビッチ

8
@Helperメソッド:テストに関与する顧客を取得します(assumimng customer == client)。開発者がコードを記述してテストすることは、開発者がソフトウェアを同じ方法で使用しないという問題です。開発者は優しいです。それは彼らの仕事です-彼らのアート:顧客はパニオの猿のようにそれを叩きます 可能であれば、テストの努力を分担して責任を分担してください。これはすべての環境に当てはまるわけではありませんが、顧問ではなくチームとして顧客と協力することで、より良いソフトウェアを生み出すことができます。
ブライアンチャンドリー

えー、もっと悪い?(フィラー)
Hello71

24

バグを修正する

私たちはここの専門家です。クラッシュまたは不正な動作を引き起こすコード内の失敗したパスを見つけた場合は、修正する必要があります。チームの手順によっては、欠陥を提出し、おそらく回帰テストを作成し、出荷サイクルの適切なタイミングで修正をチェックインする必要があります。優先度の低いバグの場合は、マイルストーンの開始付近で修正プログラムをチェックインすることをお勧めします。これは、リグレッションが発生してもマイルストーンのリリースサイクルに影響しないためです。

これを、リファクタリングやパフォーマンスのバグに関係しないパフォーマンスの改善と混同しないでください。

「小さなバグ修正」の別個のリポジトリを保持し、マイルストーンの開始時に簡単にマージできる分散ソース管理システムは、ここで大きな助けになります。


4
+1。修理する。修正が他の何かを壊した場合、その別の何かがとにかく壊れていた-それも修正する。テストでこれらの中断が検出されない場合、テストは中断されています。同様に修正してください。何かを壊すことを恐れてコードを変更することを恐れることはできません。その道は完全に台無しにしかなりません。
トムアンダーソン

21

顧客は何と言いますか?

これがこのプレイアウトをどのように想像するかです:

顧客: xを実行するとクラッシュします。

プログラマー:そうそう!しばらく前に見たのを覚えています。まだ大したことではないと思ったので、そのままにしておきました。

顧客: [鈍いオブジェクトのリーチ]

はい。バグを修正します。顧客を不快な経験から救い、緊急事態になる前にそれを修正することができます。

そして、もしあなたの修正が実際にクラッシュを引き起こすかもしれないと思うなら、あなたは実際にまだ修正を見つけていません。


8

あなたが与えたすべての例は、共通のスレッドを持っているようです。完全に理解していないバグを修正したいようです。あなたがそれぞれの意図しない結果の可能性に注意するので、私はそれを言います。

おそらく大きな間違いだと思いますベンローリーが書いている ように、あなたが理解していないバグを修正しないのです。この有名な例では、Debianチームは分析ツールの結果を追跡したときに、DebianおよびUbuntuなどの派生物のOpenSSLの暗号化を破りました。

コードを見ることで欠陥があると思われる場合は、顧客が見える方法で欠陥を再現できることを確認してください。他の何かを修正するためにリソースを費やさない理由がありません。


7

できるだけ早くあなたの技術的負債を削ぎ始めてください

あなたの例は間違いなくレガシーコードのように見え、多くの技術的負債を抱えており、変化の恐れがあると感じています(ところで、これは批判や判断ではありません)。チーム全体が、この技術的負債を抱えていることを認めなければならず(したがって、あなただけがそれを責められることはありません)、その後、あなたはどう対処するかを決めることができます。

例1では、Save()インスタンスデータにアクセスしない場合、どの顧客データが正確に保存されますか?その修正とテストを開始します。

例2では、​​速度計算機をテストで簡単にカバーし、すべての主要な例で正しい結果を計算するようにします。

例3では、デッドコードを復活させる危険があります。そのコードを完全に削除する必要がありますか?その場合のブール条件の意図は何ですか?文字列に無効な文字が含まれないようにするためですか?または、「PO BOX」が含まれていることを確認しますか?そのような質問にすぐに対処し始めるほど、より良い結果が得られます。

このような問題をいくつか修正したら、チームと振り返り/事後分析を行います。将来的に欠陥注入率を減らすことができるように、経験から学ぶことが重要です。


5

すでに良い答えがあります。何かがクラッシュすることを恐れるという問題について何かを追加します。

第一に、理想的な状況では、ソフトウェアはモジュール式であり、正しく設計されており、懸念事項が適切に分離されています。この場合、関連するすべてのコードを制御できるようになり、隠された驚きがないため、変更によって何かが壊れることはほとんどありません。

残念ながら、理想的な状況は架空のものです。カップリングがゆるい程度に関係なく、カップリングがあり、そのため他の何かを壊す可能性があります。

これに対する解決策は2つあります。

  1. コードを可能な限り構造化してください。
  2. コードが十分に分離されて、他に何も壊れないことがわかったら、修正します。

コード全体を新しいアーキテクチャ設計に書き換えても、コードを適切に構造化することはできません。むしろ、テストに導かれたリファクタリングはあなたの友人です。この手順では、機能を変更しません。

2番目のステップは、バグを修正することです。

関連するいくつかのポイント:

  1. このプロセスにはバージョン管理が絶対に必要です。
  2. リファクタリング手順とバグ修正手順は、個別のコミットとしてバージョン管理により適切にコミットされるため、それぞれに明確に定義された履歴機能があります。
  3. 別のバグを作成する可能性に固執しないでください。何もしません。むしろ、コードを改善することを考えてください。言い換えれば、バグを減らすのではなく増やしていることを知らない限り、それを行うべきです。
  4. 最後の点に関連して、未来を予測しようとしないでください。人間は予測が非常に得意であると考えるように偏っています。実際には、予測力は短期的です。漠然とした未定義の将来のバグについて心配する必要はありません。これもYAGNIの背後にある原則です。
  5. バグの世界のバージョン管理に対応するツールは、バグトラッカーです。それも必要になります。
  6. 2つの理由でバグを修正する必要があります。顧客を満足させるためです。そして、あなたの開発を進めることができるように。例3(物理学1)を使用するには:プログラムがこのような壊れた方程式で顧客を満足させる場合、このバグを緩和するために誤って開発されたソフトウェアの他の多くの部分があります(エアバッグの展開など)。このソフトウェアにバージョン2(または1.1)が必要な場合、この欠陥のあるコードに基づいて正しいコードを開発することはますます困難になるでしょう。その後、大規模な書き直し、または大失敗に向かっています。どちらも避けるべきです。

これらはすでにいくつかのポイントを超えているので、ここでやめると思います。


3

まず、バグの定義を考慮する必要があります。

  1. 読み取られたコードは、あなたが正しいと思うものと一致しません
  2. ソフトウェアがタスクを適切に実行しない

あなたは#1に焦点を合わせているように見えます。#2が座るのに最適な場所です。確かに、私たちのプログラマーは自分のコードが正しいことを望んでいますが(#1)、人々はそれが機能するために私たちにお金を払っています(#2)。

誤って新しいバグを導入する可能性のあるコードベースに対して行うこともしないことも、#2の現在のソフトウェアの見方とは無関係です。ただし、#1は自分自身または後続のメンテナンスプログラマにとって重要です。決定するのが難しい場合もありますが、2番目と1番目が競合する場合は、2番目の方が明らかに重要であることを知っておく必要があります。


2

どちらでもない。3番目の方法があります:「問題のあるコード」が実際にビジネスの観点から問題を引き起こしていることを証明する方法を見つけてください。あなたがBA / QAまたは少なくともあなたの上司に見つけたことを確認してください。その後、全員が問題を認識したときに修正を計画します。

あなたが言及した場合には、有効なバグ以外の可能なシナリオがあります:

  1. あなたが見ているコードはいくつかのデッドコードです。ysolikが言ったように、顧客は常にバグを見つけるからです。そうでない場合、コードは実行されない可能性があります。
  2. 明らかなエラーに目的があるWTFの状況がありました。(私たちは生産コードについて話している、何かが起こる可能性がありますよね?)
  3. ビジネス/顧客はすでに問題を知っていましたが、修正の必要性を感じません。
  4. おそらくもっとある...

上記のいずれの場合でも、私がマネージャーである場合、開発者が自分の判断を使用して、「エラー」を修正することは望ましくありません。エラーを適切に修正することは、ほとんどの場合に役立ちますが、間違った場合、その意図よりも多くの問題を引き起こす可能性があります。


1
自分の判断を使わない開発者だけを雇いたいなら、本当に平凡なものがたくさんあります。あなたは彼らの能力にいくらか自信がある実際の良い人を雇うのに苦労するでしょう。
デビッドソーンリー

1
@David:私の意見を不適切な程度に広げないでください。開発者は間違いなく判断を必要としますが、境界があるはずです。この場合、開発者は自分の判断を使用して潜在的なバグを検出し、それに対処するためのさらなる手順を実行します。
コーディズム

2

私は:

  • コードを修正し、それを破ったと非難される?または
  • バグを残して、顧客がそれを見つけたときに非難されますか?

バグを修正し、単体テストを開始し、成功したら修正をチェックインします。

(または、ユニットテストに非常に長い時間がかかる場合は、最初に修正をチェックインし、コミットが何かを壊したためにCIツールがメールを送信するかどうかを待ちます。)


1
または、ゲートチェックインを使用する場合は、セットアップして、破損したコードを実際にチェックインしないようにします。
アダムリア

3
長い時間をかけて見掛け倒しのコードをコミットする言い訳にはなりません。
トビー

@Toby:誰が言い訳について話していたのですか?私は現在、半ダースの開発者でさえない小さなチームで働いています。プロジェクトの単体テストには1時間かかります。私たちのポリシーは、あなたがしていることに関係があると思われるテストを実行し、チェックインし、CIに関連性のない何かを壊したかどうかを確認させることです。これは大きなチームでは機能しませんが、小さなチームでは多くの時間を節約できます。
sbi

1

クラッシュ/データ損失のバグの場合は修正してください。既知のデータ損失バグを含むプログラムを出荷することは、実に悪意があり、弁解の余地がありません。

バグが表面的または重大ではない(回避できる)場合は、文書化して回避策を提供する必要があります。理想的には修正する必要がありますが、現在のリリースで修正するには高すぎる場合があります。

すべての大規模なソフトウェアプロジェクトには、ReadMeに「既知の問題」セクションがあり、通常それが正確にリストされていることに注意してください。既知のバグ。

バグを知っており、それらを伝えないことは、本当にマイナーな/コスメティックなバグに対してのみ受け入れられます。


1

修正して、テストしてもらいます。より多くのバグを見つけることを恐れているという理由だけで既知のバグを保持することにした場合、プログラムは時限爆弾のカチカチ音をたてる地雷原になり、思ったより早く修復不能になります。

あなたがマスターであり、コードが部下であるため、間違っているとわかったときに変更することを恐れないかもしれません。コードへの恐怖(「他の場所を壊すことで報復する可能性がある」)は、単に受け入れられません。


0

明らかにクラッシャー、または何か間違っている場合は、修正する必要があります。仕様にあいまいさがある場合、つまり「お客様これを期待しているかもしれませんが、バグである可能性あります」または「これを行うように依頼された」などの仕様に問題がある場合しかし、それはあなたが何をすべきかを見つける必要があります。壁を越えてコードを投げて顧客からのフィードバックを待つのは悪いことです。もしあれば、製品マネージャーに依頼するか、製品を展開する前に顧客に依頼してください。

「その問題について知っており、将来のリリースで修正する」ということは、「その問題については知っているが、それを回避するほどあなたのことを気にかけない」ことと同義であることを忘れないでください。


0

正しい行動方針は、バグを無視することでも、その場でバグを「修正する」ことでもありません。質問で特定したまさにその理由のため。

最初にコードを理解するようにしてください。表示されているコードにある程度の年齢があり、「バグ」にまだ誰も気付いていない場合は、おそらくその理由があります。この理由を見つけてください。決定を下す前に私が見たいことは次のとおりです。

  • 履歴:バージョン管理ソフトウェアを使用して、質問に答えてください:コードに触れたのは誰ですか?彼らは何を変えましたか?そして、どのコミットメッセージでチェックインしましたか?コードがそのように見える理由を推測できますか?

  • 使用:どのコードが障害のあるコードを使用していますか?そしてどうやって?コードは死んでいますか?障害のある動作に依存する他のコードはありますか?

  • 作成者:上記の情報を使用してもすぐに結論に到達できない場合は、コードの作成者に(少なくとも可能であれば)コードがそのように見える理由を尋ねてください。通常、「おっと、修正する必要があります!」または「いいえ!変更しないでください!!!そのように必要です!」直ちに。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.