В последнее время мне в различных статьях встретилась мысль, что статический анализ ограничен областью правок кода и не учитывает сквозное влияние изменений. Вчера в очередной раз прочитал это здесь – ИИ-ревью кода в 2026 году: как оно работает и как внедрять.
В этих статьях рассматривается статический анализ в разрезе pull request, где его возможности ограничены способом использования. Однако написано так, что создаётся впечатление, что технология статического анализа в целом имеет эту слабость.
Несколько гипотез, почему так пишут:
• Авторы имеют опыт работы с простыми инструментами статического анализа (линтерами), которые действительно не используют контекст за пределами функции/файла. Авторы же транслируют свой опыт на все инструменты.
• Команды сами себя загонят в узкий сценарий запуска анализатора, но описывают это как единственный способ запуска анализатора.
• Стоит задача во чтобы то не стало написать, как похорошела жизнь с ИИ. Остальные инструменты/технологии рассматриваются с уменьшением их возможностей на фоне ИИ :)
На самом деле, анализаторы кода уже 100500 лет умеют видеть контекст всей кодовой базы и замечать, как изменение повлияет на работы функций в других файлах. Для этого используются такие технологии как межпроцедурный и межмодульный анализ потока данных.
Естественно, заставляя инструмент анализировать изменения в конкретном файле (инкрементальный анализ) обрубается/усложняется возможность заметить, как эти изменения влияют на другие части проекта. Но и проблемы как таковой нет. Достаточно время от времени выполнять полную проверку проекта, когда включен межмодульный анализ.
Более того ГОСТ Р 71207—2024 (Статический анализ программного обеспечения) явно предписывает выполнять оба вида анализа (см. п. 5.6.).
Статический анализ добавленных или измененных частей ПО следует выполнять после каждого внесенного изменения.
Статический анализ всего разрабатываемого ПО следует выполнять не реже одного раза в 10 рабочих дней, если за данный период времени исходный код был изменен.
Суть – быстро ловим многие ошибки в момент их внесения в код. Время от времени выполняем полный (к сожалению, часто весьма медленный) анализ и выявляем баги при взаимодействии разных модулей. См. вебинар про процессы статического анализа по ГОСТ Р 71207–2024.
Для тех кому-то не понятна суть обсуждаемого вопроса, приведу совсем простой пример из мира C++, где нельзя просто проверить изменения в h-файле. Вернее, можно, но от это мало пользы. Нужно сразу проверять зависящие от него cpp файлы. Я тут даже не про межмодульный анализ говорю, а про препроцессирование.
Допустим, кто-то взял и решил добавить в
definesTypes.h такой макрос:#define sprintf std::printf
Анализирую эти изменения в файле
definesTypes.h нельзя сказать, внесена ли какая-то ошибка. В файле definesTypes.h всё хорошо. Но ошибка использования неинициализированного буфера возникнет в другом месте, там где произойдёт подмена С-функции sprintf на функцию std::printf.Кстати, это реальный баг найденный PVS-Studio в проекте StarEngine: Любите статический анализ кода!