IntelliJコード検査（一般的にコード分析）は、さまざまな有用性のさまざまな問題を集める傾向があります。 Declaration Access Can Be Weakerのように、ヌルポインタ例外やその他の微妙な検査のような高いROIを実現するものもあります。良いIntelliJ検査プロファイルは何ですか、ROIは賢明ですか？
継続的な統合でコード検査を使用していますか？そのための良い検査プロファイルは何ですか？ （はい、これはチーム間で変わる可能性があることは分かっていますが、私はできるだけ偽陽性の少ない実際のバグを捕まえる良い基準から始めたいと思います）。
これは、プロジェクトで使用されているJava技術とプロジェクト自体に大きく依存しています。プロジェクトとは、用語として、「新しい、ユニークな作品など」と定義されます。この独自性は、IntelliJのコード検査などのプロジェクト管理ツールに適用されます。
たとえば、シリアライゼーション検査は、一般的な目的ではほとんど役に立ちませんが、重要な役割を果たし、分散型J2EEアプリケーションに多くの時間を費やします。 'Method never used'検査はプレーンなJavaプログラミングには適していますが、アプリケーションコンテナ（JSF、JPAなど）に必要なgetter/setterメソッドには迷惑です。
しかし、テクノロジを定義してそれに合わせて検査を調整しても、プロジェクト管理の定期的なレポート作成や問題分析などに応じて、検査プロファイルを継続的に変更することはありません。特に大きくて長持ちするプロジェクト。