Что такое хороший профиль IntelliJ Inspection, с точки зрения рентабельности инвестиций?

Question

Проверка кода IntelliJ (и анализ кода в целом) имеет тенденцию собирать множество различных вопросов различной полезности. Некоторые с высокой рентабельностью, которые нужно исправить, например исключения нулевого указателя, и другие более тонкие проверки, такие как декларация доступа может быть слабее.

Используете ли вы проверки кода в своей непрерывной интеграции? Какой хороший профиль проверки для этого? (Да, я знаю, что это может измениться между командами, но я хотел бы начать с хорошей базовой линии, которая фиксирует реальные ошибки, с как можно меньшим количеством ложных срабатываний).

Answer 1

Это сильно зависит от технологий Java, используемых в вашем проекте и самом проекте. Проект, как термин, определяется как «новая, уникальная часть работы и т. Д.». Эта уникальность применима и к таким инструментам управления проектами, как проверки кода IntelliJ.

Например, проверки сериализации в основном бесполезны для общих целей, но становятся критическими и экономят много времени, когда дело доходит до распределенных приложений J2EE. Проверка «Метод никогда не использовался» хорош в простом программировании на Java, но раздражает методы получения / установки, требуемые контейнерами приложения (JSF, JPA и т. Д.).

Но даже если ваши технологии будут определены и соответственно настроены инспекции, это не избавит вас от постоянной адаптации профилей инспекций в соответствии с регулярным отчетом управления проектами, анализом проблем и т. Д. Особенно для больших и долгосрочных проектов.