些細な修正を記録する必要がありますか？

私は2つのコードショップにいます。また、プログラマの数が1人以上の場合にバグトラッカーが役立つことは理解していますが、バグ、変更、修正を記録することは些細なことの価値があると確信していません。簡単なバグを見つけたら、それを理解し、修正し、テストを実行します。そして、私はそれをログに記録する必要があることに気付きました。

理論的には、バグのロギングはバグを見つけてから修正するまでのどこかで行う必要があることを知っていますが、修正する方がロギングするよりも速い場合、ドラッグのように見えます。大規模なコードショップでは、上司は誰が何をしているのかに注意を払い、他の人が何を言っているのかを知ってうれしいです。

すでに修正したものを説明し、すぐにそれらを閉じます。私は誰もがこの閉じられたバグを再び見るのではないかと疑っています。プロセス脂肪を削減する時ですか？

システムに加えたすべての変更を記録する必要があります。イベント後にログを記録しても何も問題はありません-バグレポートを変更番号にリンクしている限り。

その後、何か問題が発生した場合は、バグを追跡し、変更を加えた理由を確認できます。

ほとんどの場合、あなたは正しいですし、誰も二度とこれらを見ることはありませんが、何かがうまくいかない場合、100分の1でこの情報は非常に貴重です-特に問題が6か月後に現れる場合。

更新

明らかに、まだ新しい機能を開発していて、機能の一部にバグを発見した場合、終了したと思ったので、それを別の変更として記録する必要はありません。これらの場合、主要な機能を要求するアイテムに対してログを記録します。

機能を備えたシステムがQAや顧客に渡された後、そしてそれは私が上記で概説した何をする必要があります。

ソース管理ツールを使用する場合は、コミットの説明で修正したバグを説明できます。これは通常、非常に小さな些細なバグ修正に十分なドキュメントです。

さらに、FogBugzやKilnなど、ソース管理やリポジトリと完全に統合されたバグ/機能トラッカーを使用すると、グローバル検索ツールを使用してこれらのバグ修正を見つけ、どのようなコード変更を行ったかを確認できます簡単に。

さらに、プログラミングパートナーにコードレビューを割り当てて、あなたが行った些細な修正をレビューできるようにしますが、私は...

メトリックの観点から、それはまだ有用かもしれません。

この情報は、上司にいくつかのことを示すために使用できます。

• より多くの開発者が必要です
• プロセスの他の何かが壊れている（なぜ多くのバグ？他の人がほとんどのバグを生成する）ので、多すぎるバグがあるかもしれません。たぶんこれを引き起こす何かがありますか？リリースが早すぎますか？十分なテストが行​​われていますか？
• あなたが取り組んでいるものの良いリストが来ますボーナス時間。

言っていることは、それはあなたが話しているバグがどれほど小さいかに依存します。たとえば、新しいコードを追加しているときに見つけた1つのライナーは、おそらくログに記録しても意味がありません。

私は、サイズに関係なく、すべての変更を記録しようとします。自分または他の誰か（将来または現在）がいつ戻って、その変更が他の何かの原因であるかどうかを確認する必要があるかどうかはわかりません。

追跡は重要ですが、別のシナリオも検討してください：レビューの時期が来たら。それは正式に直接行われるか、上司がバグトラッカーからレポートを取得することで非公式に行われます。

それらがあなたの数字を後押しする「仕掛け」と考えてください。結局のところ、それらはあなたが修正したバグであり、たとえ些細な修正であっても、修正したことを認識すべきです。

それらを記録します。

これに答えるには、あなたがプロセスのどこにいるかに本当に依存します。

これらは、新しいプロジェクトまたは設計中の新しい機能セットに適用できます。

初期設計 初期設計時に作成したコードにバグが見つかった場合、そのバグトラックを作成する必要はありません。後で問題が見つかった場合に簡単にそれを解くことができるように、変更に対して別のコミットをお勧めします。

テスト中

コードは通常、単体テスト中に未熟であると考えられているため、別のグループによって実行されない限り、ノーと言います。単体テストがバグトラッカーとは異なるグループによって行われる場合、テスト手順を形式化する良い方法です。

CSCIテストは依存します。別のグループによって行われますか？その場合は、はい（上記を参照）。これはリリース前のテストの最後のステップですか？そうです、この時点であなたのソフトウェアは成熟したとみなされるべきだからです。メトリックに興味がある場合は、この時点でバグの追跡を開始することも良いでしょう。

より高いレベルのテストでは、バグ追跡を使用する必要があります。これらの時点で、ソフトウェアは成熟していると見なされるべきであり、バグの追跡が重要です。

リリース

リリースされたコードのバグを常に追跡する必要があります。これは説明責任にとって重要です。

ニーズに合わせてプロセスを合理化することも重要です。巨大なバグ追跡システムが本当に必要ですか？2人のチームにとって、すべてのフィールドは本当に重要ですか？

おそらく、外部にリリースされた古いバージョンのソフトウェアで、他の誰かがバグに遭遇する可能性はありますか？その場合、バグと修正の両方をログに記録しておくと便利です。

他の人は、バグを修正するよりもログに記録するのに時間がかかる場合、ロギングする価値がないと示唆しています。関連する期間は、バグの発見から修正までではなく、バグが導入されてから修正がリリースされるまでの期間であることをお勧めします。

変更とリリースの履歴が、バグがその日の目を見たことがないことを示している場合、ソース管理にチェックインするときに修正を記録するだけで十分です。

これはこの質問にかなり近いですが、これは簡単な修正に焦点を当てているため、重複しているかどうかはわかりません。

Jon Arid Torresdalによるバグを追跡しない理由 -代わりに修正してください。

1. 開発中：機能のバグが発生しました。ビルドを壊すテストケースを追加し、機能に対する修正をチェックインします。

2. リリース後：動作を文書化します。更新のリリースを計画している場合は、1に進んでください。そのリリースを担当していない場合は、プライベートブランチにtest + fixを隠しておいてください。

コードがリリースされた後、他の優先順位があり、バグの修正は簡単ですが、継続的な展開を行わない限り、修正の配布自体は経済的ではない場合があります。

どれほど些細なことかによって、私はこの尺度を使用します：

それがかかる場合は長く、それがためにかかったよりも、それをログに記録する修正することを、それがない価値がそれのロギング。