debugging - 重要でないバグは、開発者の気を散らさないように修正する必要がありますか？

Question

Joel Spolskyは、新しいコードを作成する前にすべてのバグを修正する必要があると考えていますが、多くの場所で開発者は非常に忙しく、一部のバグは価値があると見なされ、他のバグはそうではないと見なされます。ユニットテストもまた、あると便利なものとして扱われることがよくあります。

私は重要なアプリケーションで不思議なバグを追いかけてきましたが、その過程でいくつかのマイナーなバグを見つけました。私は元の作者にそれらについて言及しました、そして彼は「そうそう...私はこれらの3年前にQAが上げたのを覚えていますが、彼らはシャットダウンされました」のようなことを言いました。

一部の開発者は他の開発者のマルチタスクに優れていると思います。個人的には、一度に1つの作業を行うのが好きで0.1%、重要でないバグが深刻なバグと相互作用する可能性がある場合でも、最初に重要でないバグを修正することを強く望んでいます（プロセスも）そして後でそれについて考えないでください。

一方では、ビジネスアナリストが価値がないと見なしたことに時間を浪費することになります。一方、その1つのタスクだけに集中できれば、重要なバグをより早く修正できる可能性があります。

この議論をする前に、このような状況でのあなたの考えや経験は何であるかをお聞きしたいと思います。質問はコミュニティウィキとしてマークされています。ありがとう。

Answer 1

これは、「あなたとあなたのチームにとって最も効果的なものは何でも」のカテゴリに分類されるように思えます。スケジュールが非常に厳しく、バグを修正する時間がない場合は、とにかくそれを行うための正当な理由が必要です。

バグがあなたを苛立たせ、より大きな問題に集中するのを妨げる場合、それはそれを行うのに十分な理由かもしれませんが、大きなバグを修正する前に些細なバグを修正するのに1週間を費やしたため、出荷日を逃した理由を説明する必要があるかもしれませんバグ。

Answer 2

バグのないコードを出荷できると考えるのは良いことですが、実際には常に別のコードがあります。とはいえ、最も実用的なアプローチは、知っているものを重大度でランク付けし、時間とリソースが許す限り、重大度で優先順位を付けて修正することだと思います。

Answer 3

Joelの投稿は、「新しいコードを書く前にバグを修正しますか？」を明確にしています。哲学。

「「欠陥ゼロ」とは、いつでも、新しいコードを書く前にバグを排除することが最優先事項であることを意味します。」

この説明はもう少し明確にすることができますが、彼は完璧への期待があるという意味ではなく、プログラマーは完璧を目指して努力する必要があることを私は集めることができます。これは、プログラマーが製品をドアから出すためだけにメソッドの実装を故意に軽視してはならないことを意味します。「ゼロディフェクトマインドセット」の完全な定義は、以下を明確にするのに役立ちます。

「成功するチームのベストプラクティスまたは原則は、プロジェクトチームが、実行時に可能な限り最高の品質で作業を行うことを約束することを意味し、各チームメンバーは、望ましいレベルの品質の達成を支援する責任を個別に負います。欠陥ゼロの考え方は、展開されたソリューションが文字通り欠陥のない「完璧」でなければならないという意味ではありません。むしろ、それはチームが努力するための一貫した目標として完璧を確立します。」

あなたはあなたのチームに推薦をするつもりなので、この哲学はチーム哲学であることに注意してください。自分でこれに従おうとすると、チームが自分の主張を受け入れない場合に、高いレベルのフラストレーションにつながる可能性がありますが、自分で従おうとします。

Answer 4

コードを変更するたびに新しいバグが発生する可能性があることを忘れないでください。修正することが重要でないと思われる小さなバグを修正することで、誤って新しい重大なバグが発生する可能性があります。これは取る価値のあるリスクである場合もありますが、一部の重要なシステムでは、正当な理由がない限り、コードに触れてはなりません。したがって、どのようなシステムに取り組んでいるかが、この質問に答えるための重要な要素になる可能性があります。

Answer 5

非常に興味深い質問です。他の人が言ったように、それはチーム次第です。リソース、締め切り、個人的な信念などがこの質問に干渉します。

あなたの場合、上司や同僚とこの問題について話し合うのが最善の選択肢だと思います。自分だけに責任を負わないでください。