Предупреждения статического анализа должны привести сборку CI к сбою?
Наша команда исследует различные варианты для статического анализа в нашем проекте и смешала мнения о том, хотим ли мы, чтобы наша Непрерывная сборка Интеграции перестала работать из-за предупреждений от статического анализа.
Аргумент против сбоя сборки - то, что часто существуют исключения из правил, и пытающийся работать вокруг них только, чтобы заставить сборку успешно выполниться уменьшает производительность. Лучший подход должен был бы генерировать отчеты со сборкой и регулярно выделять время разработчика решению проблем, о которых сообщают.
Контрдовод - то, что для технического долга легко расти, если ошибки сразу не обращены. Кроме того, если сборка перестала работать, когда потенциальная ошибка представлена, количество времени, требуемое зафиксировать ее, уменьшается.
Каковы Ваши мысли?
5 ответов
Лично я предпочел бы, чтобы сборка завершилась неудачей. Хотя некоторые предупреждения являются ложными срабатываниями, предупреждения можно исключить с помощью SuppressMessageAttribute, используя Justification. При этом вы будете уверены, что каждое предупреждение оценивается разработчиками и ничего просто не проскочит.
Возможно, это хорошая идея - завалить сборку, но это не должно быть абсолютно черно-белым решением.
Hudson позволяет отменить сборку, если превышен определенный порог новых ошибок статического анализа. Таким образом, вы можете сказать: "Пометьте сборку как нестабильную, если появился 1 новый дефект; пометьте сборку как неудачную, если появилось 5 новых дефектов".
Это то, что встроено в различные плагины анализа, доступные для Hudson.
Обычно я завершаю сборку сбой из-за ошибок статического анализа (не только сборки CI, но и той, которая раньше выполнялась на компьютере разработчика для фиксации, и я использую инструменты, которые могут быть включены в IDE).
Если вы этого не сделаете, мой опыт показывает, что ошибки не исправляются и никогда не исправятся, потому что, если вы считаете ошибки косметическими (или вы не разрешаете фиксацию, верно?), Всегда будут что-то более важное сделать. Если есть обоснованное исключение, большинство инструментов позволяют исключить фрагменты кода (например, пользовательский комментарий или фильтр исключения).
Если вы хотите использовать статический анализ, делайте это правильно, устраняйте проблему, когда она возникает, не позволяйте ошибке распространяться дальше в систему. Процесс, который позволяет этому случиться неверен :
Давайте приготовим тосты в американском стиле: сожги, я поскребу. - В. Эдвардс Деминг.
Непростой вызов без хорошего глобального отвечать. Я хотел бы согласиться с двумя предыдущими сообщениями и сказать «да», но мой Второй закон статического анализа гласит, что дефекты будут накапливаться в тех частях организации, где процесс разработки программного обеспечения наиболее сильно нарушен. Следствием этого является то, что инженеры, которые вынуждены вносить изменения в свой код в спешке, чтобы предупреждения исчезли, с наибольшей вероятностью могут создать новые проблемы, когда они это сделают; Я видел удручающе много таких ошибок. Я думаю, что лучше программной инженерии делать ложноположительные отметки вне кода, как, например, в случае с Coverity и Klocwork, и на основании этого осуществлять контроль.
Само собой разумеется, что ваша основная мысль об отслеживании таких новых дефектов как можно громче и своевременном выделении времени для избежания технического долга - отличные идеи.
Помимо сбоев при ошибках, вам нужен процесс для исследования предупреждений и определения того, должны ли некоторые из них стать ошибками .