私はかなり長い間、100.000 行を超える Java コードを含むプロジェクトで静的コード分析を使用しています。私は Findbugs から始めましたが、最初は約 1500 の問題がありました。私は時間をかけて最も深刻な問題を修正し、PMD、Lint4J、JNorm、そして今では Enerjy などの追加ツールを使い始めました。
より重大な問題が修正されているため、重大度の低い問題が多数あります。これらの優先度の低い問題をどのように処理しますか?
また、ルールを無視または無効にした場合、それらを文書化しますか? 「何千もの優先度の低い問題を修正せずに放置しておく」ことについて、上司は何と言いますか? コードで（複数の）ツール固有のコメントを使用していますか、それとももっと良い方法がありますか?
静的分析は、多くの誤検知を生成することを意図していることに注意してください。これは、通常、偽陰性を回避するために支払う代償です。つまり、彼らは、実際に問題である何かが完全に問題ない (偽陰性)と言われるよりも、何かが疑わしいように見える (偽陽性) と誤って言われた方がましだと思い込んでいます。
したがって、一般に、多くのノイズを生成するすぐに使用できるデフォルトを受け入れるのではなく、これらのツールを構成する必要があります。
それらすべてを修正してみますか？
私が技術的な管理を行っているプロジェクトでは、私の標準的なやり方は、CI システムからのすべての新しい静的分析の欠陥をレビューする文化を奨励することです。特定の種類の欠陥を一定期間にわたって十分に修正することを拒否した場合、それは単なるノイズになるため、そのルールを無効にします。ときどき、無効になったルールを調べて、それらがまだ関連していることを確認します。
しかし、効果の低いルールをオフにすると、すべての欠陥が修正されます。何か問題があると思われる場合は、優先順位が他のやらなければならないことの優先順位を超えていない場合は、それを修正する必要があります。それを無視すると、チームの文化が損なわれ、間違ったメッセージが送られます。
また、ルールを無視または無効にした場合、それらを文書化しますか?
rules ファイルは私たちのプロジェクトの一部であるため、このコミットであれこれのルールが無効にされたという事実を文書化するには、コミット メッセージで十分です。
「何千もの優先度の低い問題を修正せずに放置しておく」ことについて、上司は何と言いますか?
何もない。彼らが私たちが何をしているのか、そしてその理由を理解していることを確認しますが、彼らは通常 (当然のことながら) 速度や全体的なプロジェクトの健全性など、より高いレベルの指標に焦点を当てています。
「何千もの優先度の低い問題を修正せずに放置しておく」ことについて、上司は何と言いますか?
私はマネージャーが優先順位を付けることを期待しています: あるタスクが優先度が高いか低いかを決定する (または言われる) ことと、優先度の低いタスクではなく優先度の高いタスクに人々が時間を費やすことに満足することです。
バグ追跡データベースの類推を見ると、報告されたバグのかなりの数は、おそらく決して到達しない優先度の低いバグです。確かに、それらは実際のバグであり、それらを修正したいと考えていますが、ほとんどのプログラマーは非常に現実的な制約の下で作業しており、すべての問題に対処する時間がありません。私は最近、静的解析の欠陥の特殊性について記事を書きました。
ただし、静的解析のバグに対処する際の重要な違いの 1 つは、通常、定期的に報告されるバグよりもはるかに簡単に対処できることです。したがって、修正する優先度の高い項目だけでなく、修正が最も簡単な項目も特定するために、欠陥をすばやくスキャンすると便利です。結局のところ、静的解析の欠陥は開発プロセスの非常に早い段階で検出され、問題のコードの特定の部分が非常に明確に綴られています。したがって、優先順位の低いもので、かなりの数の簡単にぶら下がっている果物を見つけることができます。
これを成功させるために使用されたさまざまな戦略には、次のものがあります。 * まず、分析が適切に調整されていることを確認します。静的解析は工場出荷時の設定で「すぐに使える」ものであり、おそらくすべてのコードを理解することはできません。自分で調整できない場合は、助けを求めてください (免責事項、私たちはその種の助けの一部を提供しています)。誤検知率を下げ、より多くの良いバグを見つけることができます。* ほとんどの場合、欠陥に優先順位を付ける特性を特定します (特定のカテゴリ、コードの特定の領域、静的分析ツールによって提供される組み込みの優先順位付けスコアなどである可能性があります)。* 重要なしきい値のレベルを決定し、場合によってはそれを受け入れ基準にします (例:
結論: 何に焦点を当てるかを選択し、必要なものを確認します。ビジネス要件によって問題が解決しない限り、すべてを修正しないでください。
会社で従うべきルールを決定し、残りを無効にします。これらのツールで設定できるルールの多くは主観的なスタイルの問題であり、無視しても問題ありません。会社のスタイル ガイドで一度従う規則を文書化する必要があります(その情報でコードが乱雑にならないようにします)。
静的分析ツールの推奨事項に基づいて古いコードを変更することはありません。そのコードはすでにテストされており、おそらく機能しています。他の理由でコードを変更する必要がある場合は、分析を実行し、推奨される変更を行います。
重要なのは、最終的に修正しないことにした場合でも、少なくともすべての問題を確認することです。その理由は、虫は惨めさのように仲間が大好きだからです。私は、findbugs が報告しなかったあらゆる種類の厄介なバグを何度も見つけました。しかし、それが報告した一見重要ではないものを見て、それらを見つけました。
個人的には、コード分析は便利ですが過大評価されていると思います。
Javaについては言えませんが、C#ではコード分析のようなものもあります。私はそれがあなたに物事をより良くするための多くの賢いアイデアを与えることに同意しますが、時々推奨事項はただ面倒です. 一部の提案は常識に基づいていませんが、スタイルの問題に過ぎません。コード分析でしばらく遊んだ後、使用をやめました。その理由は、たまたま多くの警告に同意できず、提案に従いたくなかったからです。
一般に、コード分析が示すことを実行することをお勧めします。しかし、ある時点まで。ルール定義を書く人の個人的なスタイルの問題と思われるものは、簡単に無視できます。ルールが古くなるまで、ルール 1、2、3 の例外を追加できます。次に、機能を無効にするだけです。