Автоматизация обзоров кода возможна с помощью инструментов статического анализа. Следует учитывать, что разовые проверки непродуктивны, поэтому очень важно, чтобы статический анализ кода стал неотъемлемой частью процесса разработки проекта.
Под автоматизацией процесса обзора кода могут пониматься две разные вещи:
Обзор кода (рецензирование кода) — это процесс совместного просмотра кода разработчиками с целью выявления в нём ошибок, дефектов безопасности, неэффективных алгоритмов и так далее. Эта полезная устоявшаяся практика, у которой, к сожалению, есть два недостатка:
Для компенсации этих недостатков можно использовать автоматизированный обзор кода. Речь идёт об использовании статических анализаторов кода. Статический анализатор станет ещё одним "членом команды", который выполняет обзор кода прежде, чем этим займутся коллеги.
Анализатор выдаст предупреждения об аномалиях в коде. Изучив эти предупреждения, человек может устранить ряд ошибок и потенциальных уязвимостей, улучшить оформление кода. Таким образом, статический анализатор берёт на себя часть "грязной работы" по обнаружению багов. Благодаря этому программисты на обзоре кода могут уделять больше внимания не выискиванию опечаток, а поиску более высокоуровневых ошибок. Или больше времени уделить обсуждению недостатков в дизайне классов.
Просто использовать статический анализатор недостаточно. Разработчики допускают ошибку, запуская анализатор кода от случая к случаю. Но это непродуктивный подход. Анализатор следует использовать на регулярной основе — тогда многие ошибки могут быть выявлены на раннем этапе разработки. Чем раньше ошибка найдена, тем проще и дешевле её исправление.
Поэтому важно сделать автоматизированную проверку кода частью процесса разработки. Идеально, если проверка запускается сразу после компиляции кода. Можно запускать анализ при закладывании кода в системы контроля версий (GitHub, GitLab, BitBucket и т.д.). Можно запускать анализ ночью на сервере. Существуют и другие сценарии. Самое главное, что это регулярные процессы!
Хорошая статью на эту тему: "Внедряйте статический анализ в процесс, а не ищите с его помощью баги".
Помимо регулярного использования, очень важно выбрать подходящий инструмент статического анализа. Тут нет универсальных советов для всех. Разным командам могут подойти разные инструменты. Их много (list of tools for static code analysis), и всегда можно подобрать что-то удобное именно вам.
Несмотря на то, что однозначных советов дать нельзя, рекомендую в первую очередь обращать внимание на известные коммерческие решения. Как правило, они предоставляют большой набор функциональности, который удовлетворит многим сценариям использования. Также такие инструменты, как правило, осуществят более глубокий и качественный анализ кода.
В качестве примера можно привести PVS-Studio.
В предыдущем разделе было сказано, что хорошим вариантом является проверка кода сразу после компиляции. Такое как раз умеет делать плагин анализатора PVS-Studio, встраиваемый в среды разработки Visual Studio, IntelliJ IDEA, Rider, CLion (см. режим инкрементального анализа).
Нужен анализ при закладывании кода? Есть и такая возможность: Использование PVS-Studio в GitHub Actions. Возможен запуск в Docker, Jenkins, TeamCity, интеграция с SonarQube и так далее.
Как видите, продвинутый инструмент легче интегрировать в процесс разработки. Глубину анализа кода можно оценить, заглянув в статью "Технологии статического анализа кода PVS-Studio".
Помехой на пути внедрения статического анализа могут стать ложноположительные срабатывания. Это когда анализатор выдаёт предупреждения на код, который на самом деле корректен.
Если ничего не делать с ложными предупреждениями, то они действительно становятся помехой. Полезные сообщения анализатора тонут в ложных срабатываниях, и на сообщения быстро перестают обращать внимание. Статический анализатор становится обузой. Обычно такое происходит у неопытных команд, которые ещё не использовали статический анализ и не знают, как правильно воспользоваться этой методологией.
Недостаточно просто начать запускать анализатор кода, нужно его настроить. Это тоже часть процесса внедрения инструмента в процесс разработки. Три основных момента для успешного внедрения:
Безбажного вам кода!