Comments 15
Ожидал прочитать про Анализаторы. С примерами уязвимостей, починки, автоматизацией запуска…
Ну, тоже, ничего. Тема интересная. Хорошо, что подняли.
Ну, тоже, ничего. Тема интересная. Хорошо, что подняли.
Да, это вполне можно раскрыть в отдельной статье. Спасибо за идею :)
Увы, сами статические анализаторы — не более чем игрушка (однократно запустить и посмотреть, нет ли где трэша, по настроению исправить самые вопиющие случаи). Внедрить их в рабочий процесс — это адский труд, надо выделить отдельных людей на обработку и фильтрацию результатов. Попытки переложить эти задачи на плечи рядовых разработчиков обычно кончаются ничем. Имхо, внедрять их имеет смысл только там, где безопастность ставится во главу угла, всем остальным эти временные и трудовые затраты просто не окупаются.
Или однократно выделить людей на настройку, чтобы усилий на фильтрацию требовалось поменьше, и разработчики справлялись с разбором ошибок сами.
По моему опыту, даже это проблематично (настраивал оповещение только о новых проблемах, которых не было при прошлом прогоне), всё равно сильно нарушался обычный рабочий ритм — требуется время на переключение туда-обратно с текущих задач, выяснение зоны ответственности, приоритета проблемы и прочее. В итоге начинают срываться сроки текущих задач — я не могу точно распланировать, так как не знаю, сколько за день прилетит проблем от анализатора. Пришлось отказаться, ибо неясно, сколько я могу сэкономить на статическом анализаторе в будущем (за счет проблем, которые удавлены в зародыше), но совершенно точно проигрываю в настоящем. Я не знаю способа оценить выгоду от анализатора, но по субьективным ощущениям, она меньше, чем без него. Нет предсказуемости в сроках, и тяжело сосредоточится на текущих проблемах — всё время на нервах из-за ожидания что прилетит очередное оповещение. Так что либо отдельные люди, либо запускать вручную в свободное время.
Хм… А какой статический анализатор использовала команда?
Кстати, а почему не настроить анализ для проверки коммитов, чтобы код с дефектами нельзя было заложить в основную ветку разработки? Пример на тему PVS-Studio.
Ну или почему бы ошибки не править тем самым программистам, которые заложили этот код? Они сделают это быстро, так как сами написали этот код вчера (если мы говорим про запуск анализатора при ночных сборках). Задачи можно даже не создавать, а ограничиться письмами. Оповещение команд разработчиков на примере PVS-Studio.
Кстати, а почему не настроить анализ для проверки коммитов, чтобы код с дефектами нельзя было заложить в основную ветку разработки? Пример на тему PVS-Studio.
Ну или почему бы ошибки не править тем самым программистам, которые заложили этот код? Они сделают это быстро, так как сами написали этот код вчера (если мы говорим про запуск анализатора при ночных сборках). Задачи можно даже не создавать, а ограничиться письмами. Оповещение команд разработчиков на примере PVS-Studio.
На работе cppcheck, для pet-проекта пробовал прикрутить ваш пвс через TravisCI. Отчасти проблема в ложных срабатываниях, отчасти в тоннах легаси, которое как-то работает и лопатить его чревато, как ошибками, так и просадками производительности.
Править предупреждения при пуше — тоже не всегда возможно (на работе), там нередки случаи когда надо выдать вотпрямщас результат, вылизывать времени нет. Для пет-проекта возможно и попробуем.
Править предупреждения при пуше — тоже не всегда возможно (на работе), там нередки случаи когда надо выдать вотпрямщас результат, вылизывать времени нет. Для пет-проекта возможно и попробуем.
Всё не так страшно. Есть как минимум два подхода, которые позволяют безболезненно внедрять статический анализ даже в большие старые проекты.
Ну и ещё, как вариант, можно перепоручить работу по интеграции статического анализа (настроить, поправить ошибки :). Пример: "Как команда PVS-Studio улучшила код Unreal Engine".
- «Метод храповика», о котором хорошо рассказывает Иван Пономарёв в своём докладе "Непрерывный статический анализ кода".
- "База разметки", которую мы предлагаем пользователям и клиентам, которые используют наш анализатор кода PVS-Studio. Общая идея в следующем. Пользователь запустил анализатор и получал 100500 предупреждений. Раз проект, разрабатываемый 10 лет, жив, развивается и приносит деньги, то, скорее всего, в отчёте не будет много предупреждений, ссылающихся на критические дефекты. Другим словами, критические баги так или иначе уже поправлены более дорогими способами или благодаря фидбеку от клиентов. Соответственно, всё что сейчас находит анализатор, можно считать техническим долгом, который непрактично стараться устранить сразу. Поэтому можно указать PVS-Studio считать эти предупреждения пока неактуальными (отложить технический долг на потом), и чтобы он больше не показывал их. Анализатор создаёт специальный файл, где сохраняете информацию о пока неинтересных ошибках. И теперь PVS-Studio будет выдавать предубеждения только на новый или измененный код. Причем все сделано умно. Если, например, в начало некоего .cpp файла будет добавлена пустая строка, то анализатор понимает, что, по сути, ничего не изменилось и по-прежнему будет молчать. Этот файл разметки можно заложить в систему контроля версий. Файл большой, но это не страшно, так как часто его закладывать смысла нет. И теперь все программисты будут видеть предупреждения, относящиеся только к новому или изменённому коду. Таким образом, анализатор можно начать использовать, что называется со следующего дня. Ну а к техническому долго можно будет возвращаться затем постепенно и исправлять предупреждения и донастраивать анализатор.
Ну и ещё, как вариант, можно перепоручить работу по интеграции статического анализа (настроить, поправить ошибки :). Пример: "Как команда PVS-Studio улучшила код Unreal Engine".
Первый смотреть долго, по второму отпишусь сразу. Он всё равно требует человека, который бы следил за актуальностью базы разметки. И на работе, и в хобби такого человека нет, а самому с этим возиться не хочется ни там ни там.
Классика: есть время фиксить баги, но нет времени заниматься анализатором :). Затраты на сопровождение анализатора сильно преувеличиваются. Как раз недавно я опубликовал статью про это: "Работа с возражениями: статический анализ будет отнимать часть рабочего времени".
Вот без обид, у вас в этой статье только постулаты, без каких либо доказательств или измерений. Даже в статье про ROI только теоретические расчеты www.viva64.com/ru/b/0606
А реально измерить выгоду от использования анализатора весьма затруднительно. Если это вообще возможно…
А реально измерить выгоду от использования анализатора весьма затруднительно. Если это вообще возможно…
Непонятно, почему тут статический анализ привязан непременно к уязвимостям. А освбождение памяти, а проверка на null, а локализация строк? Это только навскидку.
Sign up to leave a comment.
Как внедрить статический анализатор в разработку, чтобы всем было хорошо?