Привет, Хабр! Меня зовут Данил. Я frontend-разработчик департамента корпоративных систем ЛАНИТ, который очень любит порядок в коде. На мой взгляд, именно выразительность и чистота кода позволяют ему лучше работать и дольше жить.
В этой статье я структурировал информацию о пользе и важности статических анализаторов кода, основываясь на личном опыте.
Что такое статический анализ кода
Статический анализ кода – метод оценки качества и корректности исходного кода, который не требует его запуска.
Статический анализатор кода – это, в свою очередь, некий парсер, который проверяет написанный код и сверяет его с общепринятыми или персональными правилами. После чего формирует отчёт и предлагает исправить несоответствия.
Что можно выявить с помощью статического анализа?
Запахи кода. Это некоторые ключевые признаки необходимости рефакторинга. Данный термин был введён Кентом Беком и распространён Мартином Фаулером благодаря книге «Рефакторинг: улучшение проекта существующего кода».
Потенциальные уязвимости. С помощью статического анализа можно обнаружить различные уязвимости в коде, которые пропустил человеческий глаз.
Устаревшие конструкции. Некоторые конструкции языка в коде проекта с большим сроком жизни могут банально устареть. Статический анализ способен выявить их и предложить современную альтернативу.
Несоответствие кода стандартам. Если в проекте есть договорённости по написанию кода, которые не закреплены никакими проверками, можно считать, что их нет. Статический анализ позволяет поддерживать однородность кода, чтобы при работе с любой из частей кодовой базы приложения не нужно было тратить много времени на ознакомление.
Баги. Статические анализаторы имеют большое количество правил, которые позволяют выявлять потенциальные ошибки. Таким образом, разработчик будет предупреждён о том, что код может работать не так, как он ожидает.
Существует большое количество инструментов для статического анализа кода. Так как я являюсь frontend-разработчиком, то приведу в пример основные инструменты для frontend-приложений. Уверен, что они есть у всех популярных языков программирования.
ESLint / typescript-eslint. Инструменты для анализа JavaScript и TypeScript. Позволяют устанавливать большое количество правил, связанных со стандартами написания кода, поиском потенциальных ошибок и уязвимостей. На данный момент оба инструмента насчитывают в сумме более 300 правил.
Stylelint. Инструмент для анализа файлов стилей. Благодаря ему можно устанавливать правила, связанные с корректностью стилей и стандартами их написания. Насчитывает более 100 правил.
html-eslint. Инструмент для анализа HTML-файлов. Он дает возможность устанавливать правила, связанные с SEO, доступностью, а также стандартами написания. На данный момент насчитывает более 30 правил.
SonarQube. Инструмент, который позволяет производить полную проверку кода на соответствие некоторым правилам и подтверждающий прохождение заданной планки качества. Он способен выявлять ошибки, уязвимости, запахи кода и технический долг с предположительным временем его устранения. В настоящее время комплексная проверка TypeScript, JavaScript, HTML и CSS насчитывает более 700 правил.
Prettier. Инструмент, позволяющий устанавливать стандарты написания кода. Насчитывает около 30 правил.
Статический анализ не ограничивается лишь бизнес-кодом приложения. С его помощью можно проверять локализацию приложения, зависимости, названия и структуру папок и файлов, при необходимости код тестов и т.д.
Плюсы использования статического анализа кода
Экономия времени. Благодаря статическим анализаторам сокращается время, которое расходуется на замечания по стандартам написания во время code review. Анализаторы берут поддержку стандартов на себя. Также значительно снижается время знакомства нового человека с кодом, потому что всё приложение написано в едином и понятном стиле.
Поддержание стандартов написания кода. Когда новый разработчик приходит в команду, у него остаются привычки написания кода с прошлого места работы, которые могут не соответствовать новому. И если не указывать с помощью статического анализа, что в этом коде приняты другие стандарты, то в проекте начнут появляться части, которые написаны по-разному. Рано или поздно это приведёт к проблемам понимания кода проекта.
Воспитание хороших привычек у разработчиков. Когда на протяжении большого количества времени специалист следует стандартам написания кода, он перестаёт совершать ошибки, на которые будут ругаться большинство статических анализаторов. Как правило, они реагируют на что-то плохое. Таким образом формируется внимательность и сосредоточенность.
Повышение надёжности и безопасности кода. Благодаря использованию статических анализаторов на полную мощность увеличивается надёжность кода за счёт контроля сложности, пригодности к рефакторингу и наличия ошибок в нём. Также повышается его безопасность благодаря контролю уязвимостей.
Увеличение срока жизни кода в первозданном виде. Если писать код с использованием статического анализа со всеми его возможностями, то в будущем будет меньше необходимости его рефакторить, так как лучшие практики уже были соблюдены.
Повышение Developer Experience. Лично мне как разработчику всегда приятнее работать с красивым и качественным кодом. Его проще сопровождать и в нём легче ориентироваться.
Возможность написания собственных правил. Если возникает ситуация, когда подходящего под вашу конкретную ситуацию правила нет, вы можете написать его самостоятельно.
Минусы использования статического анализа кода
Статические анализаторы, как и любой другой инструмент, не лишены недостатков.
Миграция. Если при написании кода ранее не использовались статические анализаторы, то их внедрение, настройка и исправление кода в соответствии с их правилами будет достаточно затратным мероприятием, соизмеримым с размером кодовой базы. Но в перспективе это поможет повысить качество кода проекта.
Ложные срабатывания. Статический анализатор – это тоже программа, в которой могут быть баги. Об этом не стоит забывать, и от этого никуда не деться. Каждый раз, используя стороннюю библиотеку (даже если разработчиком является огромная корпорация), мы подписываемся на эти риски.
Нетривиальные случаи. Иногда при специфическом подходе к написанию кода статический анализатор может упустить из виду важные аспекты, а при использовании нетипичного языка программирования анализатора может вовсе не существовать. Скорее всего, это достаточно редкие случаи, но при реальной необходимости и большом желании всегда можно написать свои собственные правила и целый анализатор на их основе.
Вывод
Использование статических анализаторов кода – очень полезный вклад в развитие проекта. Важно отметить, что это не серебряная пуля от багов, уязвимостей и запахов кода, а лишь инструмент, который даёт возможность улучшить качество кода и снизить количество вышеупомянутых проблем.
Если вы до сих пор не используете статические анализаторы, то решение в первую очередь за вами. На мой взгляд, тратить ресурсы и время на их внедрение не стоит лишь тогда, когда срок жизни кода проекта относительно мал. Во всех остальных случаях использование этого инструмента оправдывает себя в полной мере.
Всем качественного и производительного кода. Помните, красивый код работает правильнее.
*Статья написана в рамках ХабраЧелленджа 2.0, который прошел в ЛАНИТ весной 2024 года.
