ピアコードレビュー中に欠陥を分類することの利点/欠点は何ですか

約3か月前に、私たちのエンジニアリンググループはレビューボードを展開し、すべてのピアコードレビューに使用しました。今日、私はそのプロセスに関与している人の1人と話し合ったところ、いくつかの機能が不足しているため、すでに代替品（おそらく何か商業用）を探していることがわかりました。

多くの人から明らかに要求される機能の1つは、各コードレビューコメントを分類/分類する機能です（つまり、スタイルの問題、コーディング規約、リソースリーク、ロジックエラー、クラッシュなど）。

コードレビューを定期的に実践するチームにとって、この分類は一般的な手法ですか？あなたはそれをしますか？過去にそれをしたことがありますか？良い/悪いですか？

一方で、これはチームにいくつかのより多くのメトリックを提供し、おそらく開発者をトレーニングする必要がある可能性があるより具体的な領域を示します（少なくともそれは議論のようです）。他のメリットはありますか？一方で、これは私の懸念ですが、コードレビュープロセスの速度がさらに遅くなるということです。チームリーダーとして、私はかなり多くのレビューを行い、コードのチャンクを強調表示し、コメントをハンマーで叩き、できるだけ早く進む機能が常に好きでした。私は個人的には試していませんが、そのコンボボックスを毎回展開し、適切なカテゴリをスクロール/検索すると、何かがあなたをつまらせているような気がします。また、これに関するメトリックを維持し始めた場合、

相対的なメリットとデメリットに関するご自身の質問にお答えいただいたと思います。

多くの場合、コードレビューは非常に骨の折れる作業になり、コードのレビューにかかる時間を増やすと、事態はさらに悪化します。私の見方では、レビュープロセスを非常に短くし、細かい点に過度に労力をかけたくないと考えています。したがって、重要なのは、チームにビジネス価値を提供するレビュープロセスの内容を決定することです。

スタイルの問題は、おそらく私が優先度の最も低いものとして置く項目の1つです。確かに、コードを整然と均一にフォーマットすることで理解が容易になりますが、スタイルの混乱により、コードのプロセスが非常に非効率になる可能性もあります。それでもスタイルの問題が気になる場合は、スタイル/フォーマットチェックツール（例：C＃のStyleCop）を使用すると、スタイル固有の問題を最後まで残して、スタイルに関連する意思決定プロセスを行うことができます。開発者の手から、より重要なもののために彼らの考えを解放します。選択した言語に対応する製品がない場合は、単純なパーサーを作成して、コードをすばやくスキャンし、そのような問題を見つけることができます。

メモリリークおよびその他のパフォーマンス固有の問題は、確認するためにレビュープロセス次第であってはなりません。もちろん、明らかに大きな問題の原因となるものを見つけた場合は指摘する必要がありますが、コード内の小さなメモリ/パフォーマンスの問題をすべて追跡することがコードレビューの目的ではありません。これが優れたプロファイリングツールの目的です。開発している言語に最適なツールを見つけることができれば、1ペニーを費やす価値があります。

ロジックの問題はせいぜい問題であり、これらは、コードをレビューするときに、多くの貴重な時間を本当に吸い込む可能性があるものです。これをすべてコードレビューに任せるのではなく、単体テストを使用する必要があります。はい、テストでも間違っている可能性がありますが、最初にテストを開発し、SRPとDRYプリンシパルに固執し、容赦なくリファクタリングし、仕様を検証する手段としてユニットテストを定義すると、最終的にははるかに少ないロジック関連の問題。コードの作成後にテストを行うと、発生する可能性のあるロジックの問題に対処する可能性が低くなり、コードの特定の経路をテストすることを忘れる可能性が高くなります。

それで、ここで提案したようにすべてを行う場合、コードレビューで何をする必要がありますか？簡単な答えは、コードレビューがかなり単純なプロセスになり、特定の要件がテストでどのように取得され、解決された問題にそれらのテストがどのように適用されたかをコーダーがレビュー担当者に説明することです。最も重要なビジネス価値を測定できる場所であり、特にそのコードを後で維持する必要がある場合は、コードをより的確に確認し、テストをより徹底的に分析する傾向があります。テストコードのレビューをさらに簡単にするには、仕様がコードでテストの実行方法についてのほぼ平易な英語の説明としてコードにキャプチャされるため、優れたBehavior Drivenテストフレームワークを使用すると、レビューを大幅に簡略化できます。テストをサポートするすべてのコードに対して詳細なチェックが実行されます。BDDフレームワークがテストをプレーンテキストのストーリー/機能ステートメントで一覧表示する素晴らしいテキストレポートを作成する場合、プロセスはさらに簡単になります。これらはすべて、従来のコードレビューと同じくらい価値のある非常に効率的なプロセスになりますが、はるかに迅速に、より焦点を絞った方法で実行できるため、些細なことや二重チェックの行き詰まりを回避するのに役立ちます。それはしばしばあなたをどこにも導きません。この無駄のないアプローチは、テストとコーディングに費やす時間を増やし、管理プロセスに費やす時間を短縮します。しかし、より迅速かつより集中的に実施できるため、どこにも行かないことが多い些細な問題や再確認に悩まされることを回避できます。この無駄のないアプローチは、テストとコーディングに費やす時間を増やし、管理プロセスに費やす時間を短縮します。しかし、より迅速かつより集中的に実施できるため、どこにも行かないことが多い些細な問題や再確認に悩まされることを回避できます。この無駄のないアプローチは、テストとコーディングに費やす時間を増やし、管理プロセスに費やす時間を短縮します。

では、それらのメトリックについてはどうでしょうか？すべての問題が単に「バグ」として扱われる場合、本当に心配する必要がある唯一の測定基準は、リリースの前後に発生するバグの数、および特定されたバグが特定の方向に傾向があるかどうかです。半端な問題追跡システムを使用している場合でも、これらの情報はすべて手元にあり、レビュープロセスでそれらを特定する必要があるかどうかを心配する必要はありません。結局のところ、チームはソフトウェアを書くことで得意なことをしたいと考えています。管理上の問題に多くの時間を費やして、会社の1人か2人の個人にしか関心のないものを提供することがよくあります。

...一方で、これは私の懸念ですが、コードレビュープロセスの速度が遅くなるということです...

レビューを軽量にしたい場合は、調査、修正、発見された欠陥のテストなどの作業に労力を費やす必要はありません。

• これを処理する単純な（ご希望の場合は馬鹿げた）オプションは、それをドロップして、テスターが自分でバグを見つけて報告するまで待ちます。このアプローチの主な欠点は、ソースコードで簡単に確認できる問題の中には、ブラックボックステストで発見するのに多大な労力を要する場合があることです。
   
  多くの場合、スレッドの問題とメモリリークはこのカテゴリに分類されます。コードを見て検出するのに1分かかるデータ競合は、何ヶ月もそこに座って、醜い頭を育てる前にすべてのテストに合格するかもしれません。

上記の理由で、私は決して使用せず、上記のようなオプションはお勧めしません。

• 別のオプションは、重い作業をデキューすることです。レビュー担当者が別の場所で作業キューを処理するという意味です。このオプションは、私が使用しているものであり、非常に快適です。
   
  アプローチは非常に簡単です。見つかった問題に対処するのにかなりの労力がかかると思われる場合は、「コードレビュー<レビューID / URL>で指摘された問題を調査して対処する」のようなタイトルでチケットを課題追跡に作成し、続行します自由形式でコメントを作成するコードを通じて。開いたチケットごとに実行される処理に時間を費やしません。これは、チームの作業キューに入り、優先順位が付けられ、日常的な方法で処理されるためです。
   
  そうすることで、1）レビュープロセスを可能な限り軽量化し、2）発見された問題を忘れないようにします。

コードストライカーを探しているようです。モード、レベル、タイプの両方で問題を分類する機能があります。

コードレビューを定期的に実践するチームにとって、この分類は一般的な手法ですか？

さて、上のツールを使っているので、やらなくてはいけません。それに関して私が目にする問題は、非常に多くのオプションがあるため、すべてを正しく行うことが難しい場合があることです。

コメントがより重要であるため、問題の分類はコードレビューにほとんど価値を提供しません。実際、上記のツールではコメントごとに4つのフィールドを設定する必要があるため、煩雑になりました。

後でレビューの要約を確認すると、その分布には固有の分布があるように見えます。人々は同じ間違いを何度もしない傾向があります。

単純なメジャー/マイナーおよび根本原因（要件/設計/実装）を使用してレビューをコーディングします。アイテムの数を減らすことで、粒度が細かくなりすぎずに、使用可能なメトリックが得られます。選択肢が少なすぎるため、カテゴリについての議論はほとんどありません。

私たちのレビュー追跡は古くからありますが、20年以上進化してきました。「選択」のツールはExcelなので、もう面倒です。正式なコードレビューを少なくするために、Gerritに切り替えています（「The Process」以外は、開発者のニーズにより適しているため、コメントを追加して続行します。「メトリック」のキャプチャではありません。

私は個人的にはメトリックが過大評価されていると思います-レビューはコードの改善に関するものであり、いくつかに参加した人に尋ねると、メトリックと同じことを教えてくれます。ただし、メトリックは議論することはできません。それらは必要に応じて便利に操作することもでき、管理は賢明ではありません（私は時には皮肉屋のビット/ロットです）。