Почему статический анализ кода для Spring так важен? 72% наших пользователей JVM используют Spring в своих приложениях, особенно в таких отраслях, как производство и финансы. Почему? Spring делает программирование на Java и Kotlin более быстрым, простым и безопасным для всех, но при этом сталкивается с уникальными проблемами.
Почему так сложно управлять качеством кода в Spring?
У Spring есть богатый интерфейс API с аннотациями и файлами конфигурации — обширная система со множеством особенностей. Это фреймворк, который работает как связующее звено для вашего приложения, определяя, как вы структурируете, создаёте и запускаете код, освобождая вас от необходимости думать о том, какую логику применять.
В проекте Spring Framework вы можете изменить один файл, и все по-прежнему будет выглядеть правильно. Однако это небольшое изменение может легко повлиять на конфигурацию вашего приложения и привести к ошибкам в других файлах. Вполне возможно, что вы не увидите этих ошибок до тех пор, пока не откроете эти другие файлы, а это уже слишком поздно.
Чтобы уверенно вносить изменения в файлы в таком проекте, вам нужны меры предосторожности, которые помогут вам следить за качеством кода в такой сложной среде. Именно поэтому мы изначально создали плагин Spring для IntelliJ IDEA, чтобы включить в него широкий спектр проверок, специфичных для Spring, для повседневного использования. Теперь мы добавили проверки, специфичные для Spring, в Qodana.
Spring, Qodana и IntelliJ IDEA: как они работают вместе?
В стандартной комплектации IntelliJ IDEA есть всё необходимое для типичной разработки на Java и Kotlin, включая Spring. Плагин выполняет различные проверки для Spring Framework и поставляется в комплекте с JVM-линтером Qodana.
Полный список проверок для Spring Framework в IntelliJ IDEA можно найти в разделе Settings | Editor | Inspections, выполнив поиск по запросу «Spring», чтобы отфильтровать нерелевантные проверки.
Те же проверки выполняются в IDE при написании кода и даже включают анализ на стороне сервера. Это означает, что если вы пропустили какую-то ошибку в IDE, она будет обнаружена линтером Qodana в конвейере CI.
В отчёте Qodana будут указаны проблемы, которые возникли в проекте, и все члены команды будут знать об этом. Qodana превращает проверку кода в командный вид спорта, улучшая общее качество кода и повышая эффективность совместной работы.
Статический анализ кода для Spring: группы проверки
Проверки Spring могут быть сгруппированы по сценариям использования в проверки на наличие проблем, связанных с автоматического связывания компонентов (autowiring), файлами конфигурации, уровнем доступа к данным, веб-уровнем и многим другим. Давайте подробнее рассмотрим некоторые из этих групп.
Проверки автосвязывания в Spring
Поскольку модель программирования Spring основана на аннотациях, различные компоненты обычно разбросаны по всему проекту и часто находятся в разных файлах и пакетах. Не сразу очевидно, существуют ли необходимые зависимости, нет ли конфликтов или корректны ли ссылки на методы жизненного цикла. Эти проблемы относятся к категории проблем с автосвязыванием, и это наиболее типичная группа проблем, с которыми сталкиваются разработчики при работе с Spring Framework.
Вы можете обнаружить множество проблем с автосвязыванием в контексте Spring в редакторе, которые подсвечиваются по мере ввода кода. Они включают в себя как второстепенные рекомендации, такие как избегать внедрения полей, или более серьезные проблемы, такие как неверно введенное имя пакета в аннотации ComponentScan.
Давайте рассмотрим пример ситуации, в которой изменение одного компонента в приложении Spring может привести к сбою другого компонента.
В приложениях Spring можно описать зависимость между компонентами, используя аннотацию @dependsOn, где имя зависимости указывается в виде строки. Компоненты могут находиться в разных частях проекта, и изменение зависимости потенциально может привести к нарушению жизненного цикла зависимого компонента.
На скриншоте выше IDE сообщает, что зависимость, на которую ссылается параметр аннотации @dependsOn, не может быть разрешена, даже несмотря на то, что класс GeneralConfig, реализующий компонент, виден в дереве проекта.
Проблема заключается в опечатке в имени ссылки: вместо “generalconfig” (все строчные буквы) значение должно быть “generalConfig“ (с заглавной буквы "C”) – таково соглашение, используемое в Spring Framework для ссылок на компоненты в контексте приложения.
Несмотря на то, что проблема выделена в редакторе, эту ошибку легко пропустить, если изменение внесено в другом месте без обновления значения ссылки. Процесс компиляции не обнаружит эту проблему, и простые модульные тесты также не обнаружат ее.
Что нам нужно, так это минимальный набор интеграционных тестов и дополнительные статические проверки кода. Именно здесь и пригодится Qodana, поскольку проблемы такого типа включаются в отчет, который генерирует флагманская платформа качества кода JetBrains.
Проверки конфигурации приложения
Проблемы с конфигурацией очень раздражают. Небольшая опечатка в файле конфигурации может привести к некорректной работе приложения или даже к его аварийному завершению.
Проверка конфигурации выявляет нерешённые и устаревшие ключи конфигурации, а также недопустимые значения в файлах конфигурации свойств приложения Spring Boot, которые могут привести к ошибкам во время выполнения.
Например, конфигурация может содержать устаревшие имена свойств. Это может произойти, когда мы обновляем версию Spring Framework в проекте, но забываем соответствующим образом обновить конфигурацию.
Другой тип проблем с конфигурацией связан с неправильным написанием значений свойств. Например, на скриншоте выше значение spring.devtools.restart.poll-interval свойства выделено красным. Это значение должно быть написано как «5m» вместо «5min».
Проверка Qodana и статический анализ кода для Spring Data
При создании запросов к базе данных Spring Data опирается на соглашение об именовании методов. Хотя этот подход очень удобен, его легко не заметить, если не быть очень внимательным.
В приведённом выше примере соглашение для сигнатуры метода findByType требует, чтобы в качестве параметра использовался класс PetType, но вместо этого в качестве параметра был использован Integer. Чтобы исправить это, мы можем либо извлечь запрос JPQL в аннотацию запроса для метода, либо просто изменить тип параметра.
Есть и другие проверки, которые подтверждают, что код, использующий Spring Data, следует применимым соглашениям. Например, вы получите уведомление, если имя метода не совпадает с именем свойства сущности.
Проверки для Spring MVC
Доступ к данным — не единственное место, где Spring Framework полагается на соглашения об именовании. Еще один пример, когда вам необходимо знать о соглашениях, — это реализация веб-уровня.
При работе с Spring MVC мы обычно ссылаемся на внешние ресурсы или переменным пути по имени. Легко допустить опечатку, и тогда внешний ресурс не будет найден.
Проверки для Spring MVC также могут обнаружить неразрешённые ссылки в аннотации PathVariable и недостающие ресурсы для шаблонизаторов, таких как Thymeleaf.
Мощное сочетание Spring, Qodana и IntelliJ IDEA
Spring Framework — это популярный, но сложный фреймворк, многие функции которого основаны на соглашениях об именовании или опираются на ссылки на имена компонентов, которые не проверяются во время компиляции.
IntelliJ IDEA проверяет соответствие Spring Framework соглашениям по мере ввода кода в редакторе, а Qodana использует механизм статического анализа IntelliJ IDEA, чтобы обеспечить видимость проекта для всей команды.
В результате вы сможете использовать Qodana для повышения производительности, улучшения качества кода и предоставления возможностей для обучения разработчиков на разных этапах работы.
У вас есть вопросы по качеству кода для команды Qodana?
Пишите на qodana-support@jetbrains.com или следите за обновлениями по качеству кода на X (бывший Twitter) и LinkedIn. Вы также можете ознакомиться с документацией для начала работы.