静的分析をコードレビューと統合する必要がありますか？
さまざまな静的分析ツールを統合し、結果をStashやレビューボードなどのコードレビューツール内のファイルにコメントとして追加したいと思います。
私はそのようなツールを書くことの実現可能性を探っています、私はpylintとpep8を使ってpythonのために働くプロトタイプを持っています。しかし、まだコードレビューツールと統合していません。
さらに、CPPCheckのようなもの、またはコンソールに実行/出力できる静的分析ツールを介して、C++などの他の言語のサポートを追加するのは比較的簡単です。
統合する必要がありますか？それとも、それらのツールの結果のためのより良い場所はありますか？
リストするツールはコードレビューとは何の関係もありません。レビュー担当者がより有用な主題に集中できるようにするためのものです。
コードレビューは、自動化できない重要なもののためのものです：別のコードがよりよく一致するときにデザインパターンを使用する、明確なコードを過剰に文書化する、または不明確なコードを文書化する、コードを短くして読みやすくすることができる言語機能を使用していません。これらはすべて、マシンにとって「賢すぎる」ものです。プログラムは、どんなに洗練されていても、特定のコンテキストで抽象ファクトリパターンを適用するのが良いかどうかを判断できません。そのため、コードレビューは人、多くの場合経験豊富な開発者によって行われます。
コードレビュー中に言及される主題もしばしば主観的です。ある開発者は、この特定の方法を2つに分割する必要があると言います。同じように経験を積んだ別の人は、この方法は問題なく、正確に1つのことを行うと考えます。あるレビューアは、gotoステートメントがひどいことに気付くでしょう。彼の同僚は、この特定のケースでは、gotoは問題なく、コードが読みにくくなることなく削除できないことに気付くかもしれません。
一方、スタイルツールは、純粋に客観的で、基本的で、時にはばかげたルールの自動化の原型です。 273行目が長すぎます。大文字を忘れてしまいました。そしてここに、不足しているスペースがあります。そしてここで、1行ではなく2行の空の行を見つけました。ブーイング。
コードレビュー中にそのために誰かの時間を無駄にしないでください。プロジェクトにスタイルガイドがある場合は、スタイルチェッカー（pep8など）を使用しますが、pre-commitフックを介して自動的に実行します。スペースが足りませんか？コミットしません、サー。空の行に空白が含まれていますか？コードをバージョン管理する場合は、削除してください。
実際には：
ルールは客観的でわかりやすいので、コードレビュー中に議論することは何もありません。空の行に空白があります。だからそれを削除します。コードレビュー中にそれについて何を伝えたいですか？
さらに悪いことに、それは建設的な議論につながる可能性があります。率直に言って、2つのスペースが4つよりも優れていることを誰もが知っているので、コードレビューは好みのスタイルのメリットについて議論する機会になるでしょう。そして今、コードレビューは「コードスタイルを変更し、コードベース全体を4つではなく2つのスペースを使用するように書き直す必要があるか」に焦点を当てています。これは絶対に避けてください。
残りの部分（マシンには複雑すぎるもの）はコードレビュー用であり、レビュー担当者は実際に重要なことに集中できます。
自動化されたチェックは、スタイルチェック、コンパイル、テスト、静的分析、または正式な証明であり、まあ、自動化されている必要があります。継続的インテグレーションプロセスのどこにあるべきかは別のテーマです。スタイルチェックなどの短くて速いチェックは、コードベース内の非準拠コードを回避するために、事前コミットフックに直接置くことができます。静的分析などの長いチェックは、通常、ビルド中に実行されます。
次のようなテーマがある場合は覚えておいてください。
- 正直な答えはありません。答えは個人的な経験と知識に基づいた推測に基づいています。
- 結果は非バイナリになります。「まあ、Aでもかまいませんが、ここではBを受け入れることができます。一方、Cは少し問題があるように見えますが、これがそうであれば、優れた解決策になります」スタイルの回答、
- 最も洗練されたアプリケーションでも自動化できない可能性があります。
- 別のコンテキストに簡単に移植することはできません。
- コードの品質、読みやすさ、表現力、保守性に重点を置いています。
コードレビューはそれにとって良い場所かもしれません。一方、件名が次の場合：
- 純粋に客観的であり、曖昧さはありません。
- 多くの場合、メトリックに基づいて、バイナリ回答になります。
- 自動化できます（場合によっては多くの作業と研究が必要になります）、
- 同じグループ内のすべての状況に適用され、
- コードの品質、読みやすさ、表現力、保守性に重点を置いています。
事前コミットフックまたはビルドは、コードレビューよりもはるかに優れた場所です。
さらに読む：
この答えは2つの仮定に基づいています。まず、スタイルチェッカー以上の静的分析ツールを使用しています（ [〜＃〜] pmd [〜＃〜] および/または FindBugs の代わりに- Checkstyle など）。次に、ツールは、検出されたエラーと、特定のプロセスまたは製品のエラーの重大度に関して適切に構成されています。
はい、エラーを見つけるように設計された静的分析ツールは、コードレビュープロセスの一部である必要があります。より一般的には、他の開発者が使用するブランチにコードをコミットする前に、静的分析ツールを実行し、コードレビューの一部として結果をレビューする必要があります。
コードレビューの前に、開発者は静的分析ツールによって検出された問題を実行して修正し、結果をレビューして重要な結果を修正する必要があります。次に、残りのエラーを生成するために、コードに対して再実行する必要があります。このリストは、コードレビューの一部である必要があります。これにより、人間のコードレビュー担当者は、見つけられない問題に集中したり、ツールによってフラグが付けられたコードの領域に特別な注意を払ったりすることができます（誤検知を再確認します）。
理想的には、プロジェクトの開始以来、ツールを使用しています。ただし、そうでない場合で、多数の調査結果がある場合は、これらを確認して破棄する必要があります。これは、コードレビューの一部としては実行されません。この時点で、ビルドまたは継続的インテグレーションプロセスのツール部分の実行を行い、ビルドごとにエラーの数を減らす必要があります。開発者は、この情報を使用して、リファクタリングまたは開発中に 触れたコードを見つけたよりも良い状態のままにする を支援する必要があります。もちろん、コードレビュー中にリストを使用することは、コードが以前よりも優れていることを確認するために修正する必要がある潜在的な問題を特定するのにも役立ちます。