# 5 причин, почему статический анализ кода важен для бизнеса

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

![1046_Why_static_analysis_is_important_ru/image1.png](https://import.viva64.com/docx/blog/1046_Why_static_analysis_is_important_ru/image1.png)

## Что такое статический анализ кода

[Статический анализ кода](https://pvs-studio.ru/ru/blog/terms/0046/) — это автоматизированный процесс поиска ошибок и потенциальных уязвимостей, выполняемый программным инструментом при участии человека\. Является разновидностью тестирования белого ящика, так как работа ведётся с исходным текстом программы\.

Классический обзор кода выполняется командой разработчиков\. Это полезный, проверенный временем способ выявления ошибок и передачи знаний\. Его недостаток – высокая стоимость\.

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

## Работа со статическим анализатором кода

Инструмент анализа кода получает на вход текст программы и выдаёт список предупреждений\. Разработчик изучает эти предупреждения и принимает решения, где стоит внести правки в код, а где нет\. 

Полностью автоматизировать процесс нельзя, т\. е\. анализаторы сами не модифицируют код\. На это есть несколько причин:

1. Статические анализаторы иногда генерируют [ложноположительные срабатывания](https://pvs-studio.ru/ru/blog/terms/6461/)\. Они могут считать код ошибочным, хотя на самом деле он корректен\. Только человек способен понять, нужно вносить правку или нет\.
1. Часто, хотя наличие ошибки очевидно, у анализатора нет информации, чтобы предложить исправление\. Исправить код может только человек, знающий, как должна работать программа в целом\.
1. Некоторые предупреждения анализатора носят информативный характер и указывают на "код с запахом"\. Программист должен решить, стоит ли провести рефакторинг кода и как сделать, чтобы код стал более понятен для коллег и анализатора\.

Сценарии работы со статическим анализатором весьма разнообразны\. Анализ кода может запускаться вручную из IDE или автоматически после сборки проекта\. Анализ может запускаться для файлов, закладываемых в систему контроля версий\. Проверка проекта может осуществляться ночью на сервере, а утром разработчикам будут приходить письма с предупреждениями, относящимися к их коду\. Могут использоваться другие сценарии или их сочетания\. Всё зависит от того, какой из вариантов более удобен команде\.

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

## Польза внедрения статического анализа кода

Статический анализ требует времени на внедрение и использование, как и любая другая методология тестирования\. Например, юнит\-тесты тоже требуют времени на написание и сопровождение\. Однако использование статического анализа, как и написание юнит\-тестов, обернётся экономией ресурсов команды при сопровождении и развитии программного проекта\.

Существует пять причин, почему статический анализ окажет положительное воздействие на процесс разработки ПО с точки зрения бизнеса:

1. Сокращение времени и стоимости исправления ошибок;
1. Раннее обнаружение потенциальных уязвимостей;
1. Высвобождение ресурсов для решения бизнес\-задач;
1. Контроль качества;
1. Поддержка различных стандартов кодирования\.

Рассмотрим каждую из них подробнее\.

### 1\. Сокращение времени и стоимости исправления ошибок

Чем раньше ошибка обнаружена, тем меньше стоимость её исправления\. Статический анализ может выполняться ещё на этапе написания кода, а это самый ранний момент, когда можно выявить ошибку\.

Согласно книге С\. Макконнелла "Совершенный Код", средняя стоимость выявления и исправления ошибки на этапе тестирования уже в 10 раз выше, чем её исправление на этапе написания кода\. Если ошибка обнаружена после выпуска программы, то стоимость исправления может вырасти ещё больше\.

### 2\. Раннее обнаружение потенциальных уязвимостей

Ситуация ещё более критична, если говорить не о простых ошибках, а об [уязвимостях нулевого дня](https://pvs-studio.ru/ru/blog/terms/6478/)\. Компания может понести большие репутационные и финансовые потери, если злоумышленник обнаружит уязвимости в её сервисах\. На графике показаны средние затраты на устранение дефектов безопасности, обнаруженных на различных этапах жизненного цикла программного обеспечения\.

![1046_Why_static_analysis_is_important_ru/image2.png](https://import.viva64.com/docx/blog/1046_Why_static_analysis_is_important_ru/image2.png)

Рисунок 1\.  Относительная стоимость исправления уязвимости по данным IBM System Science Institute\.

Статический анализаторы, проверяющие код на наличие [потенциальных уязвимостей](https://pvs-studio.ru/ru/blog/terms/6441/), называются [SAST\-решениями](https://pvs-studio.ru/ru/blog/terms/6631/) \(Static Application Security Testing\)\. Примером такого инструмента является PVS\-Studio\.

### 3\. Высвобождение ресурсов для решения бизнес\-задач

Автоматизированное выявление части ошибок на этапе написания кода с помощью анализаторов высвободит больше ресурсов на решение бизнес\-задач\.

![1046_Why_static_analysis_is_important_ru/image3.png](https://import.viva64.com/docx/blog/1046_Why_static_analysis_is_important_ru/image3.png)

Рисунок 2\. Статический анализ помогает уменьшить количество незавершённой работы \(WIP\) и сократить количество внеочередных срочных задач, связанных с правкой критичных багов\.

Цитата из книги Дэвида Андерсона "Канбан\. Альтернативный путь в Agile":

> Кейперс Джонс сообщает, что в 2000 году во время пузыря доткомов он оценивал качество программ для североамериканских команд, и оно колебалось от шести ошибок на одну функциональную точку до менее чем трех ошибок на 100 функциональных точек \- 200 к одному\. Серединой будет примерно одна ошибка на 0,6\-1,0 функциональной точки\. Таким образом, для команд вполне типично тратить более 90 % своих усилий на устранение ошибок\. Есть и прямое тому свидетельство: в конце 2007 года Аарон Сандерс, один из первых последователей Канбана, написал на листе рассылки Kanbandev, что команда, с которой он работал, тратила 90% доступной производительности на исправление ошибок\.
>
> Стремление к изначально высокому качеству окажет серьезное влияние на производительность и пропускную способность команд, имеющих большую долю ошибок\. Можно ожидать увеличения пропускной способности в два \- четыре раза\. Если команда изначально отстающая, то концентрация на качестве позволяет увеличить этот показатель вдесятеро\.

Один из способов снижения плотности ошибок в коде заключается в регулярном использовании статического анализа\. Анализаторы находят ошибки, а их предупреждения [помогают писать более простой и лаконичный код](https://pvs-studio.ru/ru/blog/posts/cpp/0968/)\. Понятный код легче сопровождать, а при его изменении меньше вероятность внесения новых ошибок\.

### 4\. Контроль качества

Менеджерам может быть интересно получить ответы на вопросы следующего типа:

* В этом году команда пополнилась большим количеством новых сотрудников\. Не повлияло ли это на качество кода в худшую сторону?
* Мы планируем внедрить X\. Как узнать, скажется ли это положительно на качестве кода?

Ответы на эти вопросы могут дать графики плотности предупреждений, построенные на основе результатов статического анализа\. Если количество предупреждений в пересчёте на 1000 строк кода становится всё больше, значит качество падает\. Такие графики могут быть [построены](https://pvs-studio.ru/ru/blog/posts/0452/), например, с помощью платформы SonarQube\.

### 5\. Поддержка различных стандартов кодирования

Создаваемый код должен отвечать стандартам, принятым в соответствующей индустрии\. Например, при разработке систем, для которых важны безопасность и отказоустойчивость, применяют стандарты MISRA C, MISRA C\+\+, AUTOSAR C\+\+14 Coding Guidelines\.

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

## Заключение

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

Наша команда разрабатывает SAST\-решение [PVS\-Studio](https://pvs-studio.ru/ru/pvs-studio/) и имеет большой опыт помощи компаниям во внедрении статического анализа в их процесс разработки\. [Напишите](https://pvs-studio.ru/ru/about-feedback/) нам, если у вас есть вопросы по тематике статического анализа\. Надеюсь, мы сможем помочь вам улучшить процессы создания программных решений\.

## Дополнительные ссылки

1. [Внедряйте статический анализ в процесс, а не ищите с его помощью баги](https://habr.com/ru/articles/436868/)\.
1. [Как внедрить статический анализатор кода в legacy проект и не демотивировать команду](https://pvs-studio.ru/ru/blog/posts/0743/)\.
1. [Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps\-пайплайн](https://pvs-studio.ru/ru/blog/posts/0937/)\.
1. [List of tools for static code analysis](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis)\.
1. [Философия статического анализа кода: у нас 100 программистов, анализатор нашел мало ошибок, он бесполезен?](https://pvs-studio.ru/ru/blog/posts/0534/)