Должны ли статические аналитические предупреждения проваливать сборку CI?

Question

Наша команда изучает различные варианты статического анализа в нашем проекте и имеет разные мнения относительно того, хотим ли мы, чтобы наша сборка Continuous Integration не сработала из-за предупреждений статического анализа.

Аргумент против сбоя сборки состоит в том, что часто существуют исключения из правил, и попытка обойти их, чтобы добиться успеха сборки, снижает производительность. Лучшим подходом было бы создание отчетов со сборкой и регулярное выделение времени разработчика на решение указанных проблем.

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

Что ты думаешь?

Answer 1

Вероятно, хорошей идеей будет провал сборки, но это не должно быть абсолютно чёрно-белым решением.

Hudson позволяет отказаться от сборки, если превышен определенный порог новых ошибок статического анализа. Таким образом, вы можете сказать: «пометить сборку как нестабильную, если введена 1 новая ошибка; пометить сборку как сбойную, если введено 5 новых ошибок».

Это то, что встроено в различные плагины анализа, доступные для Hudson.

Answer 2

Лично я бы предпочел увидеть сбой сборки. Хотя некоторые предупреждения являются ложными срабатываниями, предупреждения могут быть исключены с помощью SuppressMessageAttribute с использованием Justification. При этом вы уверены, что каждое предупреждение оценивается разработчиками, и ничто просто не проскальзывает.

Answer 3

Я обычно делаю сбой сборки при статическом анализе ошибки (не только сборка CI, но и та, которая выполняется на компьютере разработчика перед фиксацией, и я использую инструменты, которые можно включить в IDE).

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

Если вы хотите использовать статический анализ, сделайте это правильно, исправьте проблему, когда она возникнет, не позволяйте ошибке распространяться дальше в систему. Процесс, который позволяет этому случиться , неверен :

Давай сделаем тост по-американски: сожги, а я поцарапать. --W. Эдвардс Деминг.

Answer 4

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

Answer 5

Жесткий вызов, без хорошего глобального ответа. Я хотел бы согласиться с двумя предыдущими публикациями и сказать «да», но мой второй закон статического анализа говорит, что дефекты будут накапливаться в тех частях организации, где процесс разработки программного обеспечения наиболее сильно нарушен. Следствием этого является то, что инженеры, которые вынуждены изменить свой код в спешке, чтобы убрать предупреждения, с наибольшей вероятностью создают новые проблемы, когда они делают это; Я удручающе видел много таких ошибок. Я думаю, что лучше для разработки программного обеспечения делать ложно-положительную маркировку вне кода, как, например, в Coverity и Klocwork, и применять на этом основании.
Само собой разумеется, что ваша главная мысль о том, чтобы как можно громче отслеживать такие новые дефекты и своевременно выделять время, чтобы избежать технического долга, является отличной идеей.