発見してパッチを適用したバグを記録する必要がありますか？

これは一般的な状況だと思います：いくつかのコードをテストし、バグを発見し、それを修正し、バグ修正をリポジトリにコミットします。多くの人がこのプロジェクトに取り組んでいると仮定して、まずバグレポートを作成し、自分に割り当てて、コミットメッセージで参照する必要があります（たとえば、「バグ#XYZを修正します。バグはXおよびYによるものです。 Q and R "）？または、バグレポートをスキップして、「BのときにAを引き起こしたバグを修正しました。バグはXおよびYによるものでした。QおよびRで修正しました」などのメッセージでコミットできます。

より良いプラクティスと考えられるものは何ですか？

バグレポートの対象者によって異なります。

開発者が内部でしか見ない場合、何を修正する必要があるかを知るために、気にしないでください。その時点でのノイズです。

とにかくログに記録する理由の包括的なリスト：

• リリースノートには、修正されたバグに関する情報（このバグが満たすしきい値まで）が含まれます-特に、このバグによって公開された脆弱性がある場合
• 経営陣は、「バグ修正に費やされた時間」/「検出されたバグ数」などの概念を望んでいます。
• 顧客は、バグトラッカーの現在の状態を確認できます（問題が既知であるかどうかを確認するためなど）。
• テスターは、テストする必要がある変更に関する情報を取得します。

製品がバグを含んでリリースされたかどうかによって異なります。

見つかったバグとともにリリースされている場合は、バグレポートを作成します。多くの場合、リリースサイクルは長くなる可能性があり、修正済みのバグを新しい問題として報告することは望ましくありません。

あなたのバグがまだ出荷されていない場合、私は同じ道をたどりません。これで、バグがまだリリースされていないために作成できないバグを再作成しようとして、本質的に時間を浪費することになります。

顧客から報告された可能性があるバグの場合は、これを行う必要があります。最悪の場合：あなたはバグを修正しますが、誰も知りません。お客様がバグを報告します。同僚はバグを修正しようとしますが、それをまったく再現することはできません（すでに修正しているため）。そのため、バグの記録が必要です。

また、コードレビューを行う場合にも役立ちます。コードレビューでは、通常、特定のタスクのためにコードを作成してからレビューします。その場合は、バグ修正を分離しておくとよいでしょう。タスクリストに何かを入れてからすべての作業を行う必要がある場合があります。

これはいくつかの要因に依存します。

Pieter BとCalethの両方が、その答えの一部を挙げています。

• バグは公式リリースの一部ですか？
• それらに費やされたバグ/時間の数は特に追跡されていますか？

多くの場合、認証の要件に裏打ちされた内部手順に従うこともできます。特定の証明書では、コードのすべての変更が課題トラッカーのレコードに追跡可能であることが必須です。

さらに、些細に見えるバグ修正でさえ、最初に現れたほど些細で無害ではない場合があります。関係のない問題の配信にこのようなバグ修正を静かにバンドルし、後でバグ修正に問題があることが判明した場合、これにより、隔離または元に戻すことはもちろん、追跡するのがはるかに難しくなります。

この質問に答えられるのは、プロジェクトリーダーまたは「チケットプロセス」を担当する人だけです。

しかし、別の方法で聞いてみましょう：なぜパッチを当てたバグを記録しないのですか？

私が見る唯一の推測可能な理由は、バグレポートを提出し、それに対してコミットし、それを閉じるための努力が、バグを修正する時間よりも桁違いに大きいということです。

この場合、問題はバグの修正がそれほど簡単ではないということではなく、事務処理に時間がかかりすぎることです。本当にすべきではありません。私にとって、Jiraチケットを作成するためのオーバーヘッドはを押してcから、短い1行の要約を入力し、を押すことEnterです。説明は、問題番号とともにコミットメッセージにカットアンドペーストできるため、オーバーヘッドではありません。最後に. c <Enter>、問題は解決しました。つまり、オーバーヘッドは5キーになります。

あなたのことは知りませんが、小さなプロジェクトでもこの方法ですべてのバグ修正を記録するためのポリシーにするのには十分ではありません。

利点は明らかです。Jiraのようなチケットシステムを簡単に操作できる人はかなりいますが、ソースコードは使用できません。チケットシステムから生成されたレポートもありますが、ソースからは生成されません。あなたは間違いなくそこにあなたのバグ修正を望みます。例えば、プロセスの問題などについての洞察を提供することができる小さな1行のバグ修正の着実な流入のように、可能な開発について学びます。たとえば、このような小さなバグ修正を頻繁に行う必要があるのはなぜですか（それが頻繁に発生すると仮定して）。テストが十分ではないということはありますか？バグ修正はドメインの変更、またはコードエラーですか？等。

私が従うルールは、作業中のセクションがまだリリースされておらず、まだ実行されておらず、ユーザーも見たことがない場合は、表示される小さなバグをすべて修正して先に進みます。ソフトウェアがリリースされ、実稼働状態になり、一部のユーザーがそれを確認すると、表示されるすべてのバグがバグレポートを取得してレビューされます。

バグだと思うのは、他の誰かの機能であることがわかりました。それらのバグをレビューせずにバグを修正することで、バグを修正する代わりに作成することができます。バグを修正するためにどの行を変更するか、およびバグの修正方法に関する計画をバグレポートに入力します。

要約すると、このモジュールが実際に稼働したことがない場合は、表示されるすべてのバグをすばやく修正し、仕様に従ってください。モジュールが既に実稼働中の場合は、修正する前にすべてのバグをバグレポートとして報告し、確認してください。

はい。

バグレポートを作成する価値がある状況を明らかにするいくつかの回答がすでにあります。いくつかの答え。そしてそれらは異なります。

唯一の答えは、誰も知らないということです。異なる人々は、異なる時間に、問題について異なる意見を持ちます。

そのため、バグに遭遇した場合、次の2つの解決策があります。

• バグレポートを開く価値があるかどうかを熟考し、同僚の意見を聞いてみてください...その後、場合によっては、誰かがそれについて尋ねているので後悔していることを後悔します。それらを指すだけです
• レポートを作成するだけです

レポートの作成はより高速で、そうでない場合は...自動化します。

自動化する方法は？トラッカーがスクリプトをサポートしていることを前提として、呼び出すことができ、コミットメッセージ（タイトルと本文）を使用してバグレポートを送信し、追跡に関連付けられたコミットリビジョンと共に「実装済み」としてすぐに閉じるスクリプトを作成します。

私は他の答えがすべて良い経験則を提供し、この点にいくつかのタッチさえ提供することに同意するつもりです、しかし、私はここに本当に確実な答えがあるだけだと思います。

上司に聞いてください。あなたのグループがどのように構成されているかに応じて、マネージャーまたはプロジェクトリードまたはスクラムマスターなどを担当します。

良い練習と悪い練習の多くの異なるシステムがありますが、あなたがチームのために正しいことをしていることを知る唯一の方法は尋ねることです。

1分間の廊下での会話に沿って何かができます。「ちょっと（ボス）、ほんの数分しかかからないマイナーなバグを修正したら、チケットを作る価値があるのか​​、それともコミットメッセージで言及するだけですか？ 」そして、あなたは確かに知っているでしょう。その方法があなたのチームとあなたのマネージャーを悩ますなら、世界のすべての良い習慣は役に立たない。