Платформа качества кода для команд
Качество кода никогда не меняется — или ИИ бросает вызов этому утверждению?
Эта публикация подготовлена на основе выступления Кая Шмитхюзена (Kai Schmithuesen) на мероприятии JetBrains Game Development Day 2026. Посмотрите полную видеозапись презентации и сессию вопросов и арбитража ниже или продолжайте чтение!
Содержание
- Что мы понимаем под качеством кода?
- Почему выпускается плохой код?
- Использование статического анализа кода для решения задач разработчиков игр
- Статический анализ в сочетании с ИИ как решение
- Плюсы и минусы статического анализа и анализа с помощью ИИ
- Что говорят цифры? Когда вы просите ИИ добавить тесты, в конечном итоге эти тесты и все репозитории начинают переполняться, и даже тривиальные процессы, такие как линтинг, могут замедляться. Есть ли у вас опыт работы с этим? Насколько встроенные агенты JetBrains в среде разработки могут считывать инструменты статического анализа самой среды?
- Когда вы просите ИИ добавить тесты, в конечном итоге эти тесты и все репозитории начинают переполняться, и даже тривиальные процессы, такие как линтинг, могут замедляться. Есть ли у вас опыт работы с этим?
- Насколько встроенные агенты JetBrains в среде разработки могут считывать инструменты статического анализа самой среды?
Сначала мы определим, что мы понимаем под качеством кода, затем рассмотрим, как это влияет на бизнес-результаты, где здесь задействован ИИ, каково влияние ИИ на качество и как его защитить в вашей команде.
Вы можете взять описанные здесь методологии и использовать их для множества решений, но мы также рассмотрим пример с Qodana.
Качество кода — это тема, которую порой упускают из виду, особенно в разработке игр, где у вас могут быть другие насущные проблемы. Тем не менее, общаясь со многими клиентами JetBrains на конференциях по разработке игр, мы видим осознание того, что это важная тема. При этом в игровой индустрии нет единого набора передовых практик, поэтому в данной презентации мы поделимся некоторыми из таких практик из других отраслей.
Что мы понимаем под качеством кода?
Для столь важной темы это определение может быть «размытым». Если вы поговорите с десятью коллегами, вполне возможно, что получите множество разных ответов. Первый пункт — корректность.
Корректность: делает ли мой код то, что я заложил в его проект? Производительность: важно для игр, достаточно ли он быстр? Стабильность: падает он или нет, и насколько он стабилен с точки зрения игрока. Безопасность: также важно, чтобы не попасть в новости индустрии из-за взлома. Поддерживаемость: работает ли мой код сегодня и будет ли он работать через пару лет? Особенно с учетом того, что некоторые игры живут по 10–12 лет. Переиспользуемость: эта тема становится все более актуальной для крупных студий: могу ли я повторно использовать код, который уже разработал для других проектов? Все это дает общее представление о том, что включает в себя качество кода.
Если вы зайдете в дикий запад, такой как X или LinkedIn, например, то увидите, что вопрос о том, важно ли качество кода, является предметом ожесточенных дебатов. От мнения одного человека, которому все равно, как выглядит его код, до другой крайности: «Мой код должен быть красивым и безупречным перед релизом», и всего, что между ними. Существует множество самых разных мнений.
Команда Qodana утверждает, что качество кода может оказать реальное влияние на ваш бизнес и на то, как будет принята ваша игра. Одна AAA-студия потеряла 33% своей стоимости через неделю после релиза.
Время загрузки GTA сократилось на 70% благодаря простому исправлению двух небольших ошибок в коде. Время загрузки было сокращено с 6 минут до 2 минут (игроком), а затем Dark Souls была отключена на 2 месяца из-за уязвимостей удаленного выполнения кода (проблема безопасности), и если вы потеряете игроков за эти два месяца, они, скорее всего, не вернутся, и это окажет реальное влияние на выручку. Плохой код не остается только на вашей стороне. Он доходит до ваших игроков, что может привести к возвратам средств и плохим отзывам.
Когда мы смотрим на IGN или PC Gamer, качество, баги, стабильность — всё это всегда влияет на оценки. В конечном итоге это определяет, сколько игроков вы привлечете, а багованные игры вызывают недовольство платящих пользователей. Есть примеры крупных студий, которым это сходит с рук, например Bethesda, но этим не стоит рисковать.
Почему выпускается плохой код?
Во многих беседах мы замечаем, что давление сроков вывода игры на рынок просто огромно. Графики действительно представляют собой проблему, и это отражается на количестве разработчиков игр, которым приходится работать в авральном режиме или сверхурочно (а это более половины). Это побуждает многие студии искать способы использования ИИ для помощи в решении этой задачи.
ИИ, особенно в разработке игр, является горячо обсуждаемой темой. Тем не менее, 95% of Unity developers (Отчет разработчиков игр Unity за 2026 год) используют его на работе для помощи в процессе кодирования, что показывает: ИИ при правильном использовании может быть полезным инструментом.
Вы можете создавать прототипы гораздо быстрее, пробовать новые игровые механики и т. д. Раньше на это уходило пару месяцев, а теперь можно справиться за пару дней и отбросить то, что не работает. Вам не нужно тратить так много времени на шаблонные проблемы, что приводит к повышению эффективности.
Цель состоит не в том, чтобы сократить разработчиков в командах, а в том, чтобы дать вашей команде возможность использовать ИИ для более интересных задач. Однако такая скорость и использование ИИ несут в себе потенциальную обратную сторону, когда речь заходит о качестве кода. ИИ может генерировать много кода очень быстро, и он не обязательно лучше или хуже, но он увеличивает количество проблем. Раньше вы могли написать пару сотен строк. Теперь за то же время ИИ может написать 10 000 строк. Это приводит к реальным проблемам, например:
Медленный код: соответствует ли моя игра требованиям к производительности, стабильна ли она? Можно ли ее взломать или есть ли потенциальные проблемы с безопасностью? Хорошая и плохая новость заключается в том, что код, написанный ИИ, не обязательно хуже кода, написанного человеком, они кажутся вполне на одном уровне по общему количеству проблем, но они проявляются иначе, чем в коде человека.
Когда дело доходит до логики и ошибок, ИИ создает 1,7x more issues than human-generated code. Когда дело касается поддерживаемости и т. д., он хуже, и, что больше всего беспокоит, он также потенциально может создавать больше проблем безопасности, чем разработчик-человек. Об этом говорится в исследовании CodeRabbit. Они сами являются поставщиком ИИ.
Тем не менее, дело не обязательно в том, какие именно проблемы кем созданы (людьми или ИИ), единственный вопрос, который мы ставим: «Соответствует ли наш код в целом требованиям, отвечает ли он нашим стандартам качества?» И здесь на помощь приходит статический анализ. Хорошая новость заключается в том, что вы можете использовать статический анализ, чтобы охватить практически все эти 6 областей.
Использование статического анализа кода для решения задач разработчиков игр
Что касается корректности, у вас есть стандартные инспекции. Вы также можете проверять пороговые значения покрытия кода, которые приобретают все большее значение. И не только само покрытие, но и то, как его использовать.
Производительность — это область, которую может охватить статический анализ. Примерами для стабильности могут служить проверка на безопасность нулевых указателей (null safety), утечки ресурсов, инспекции исключений, инспекции безопасности и анализ состава программного обеспечения — проверка устаревших зависимостей или выполнение анализа загрязнения (taint analysis) в рамках статического анализа для поиска более сложных проблем, таких как SQL-инъекции и т. д.
С точки зрения удобства поддержки вы можете находить фрагменты сомнительного кода («код с душком»), оценивать сложность кода и его дублирование. Это именно то, в чем ИИ действительно силен. Он любит дублирование, но не любит рефакторинг. Если у вас нет способа держать это под контролем, в дальнейшем это серьезно ухудшит поддерживаемость кода, так как на каком-то этапе никто не сможет в нем разобраться.
То же самое касается и повторного использования: дублированный код все усложняет, а статический анализ позволяет проверить, соответствует ли ваш код вашим собственным внутренним стандартам кодирования, чтобы придерживаться единого подхода независимо от проекта, над которым вы работаете. Таким образом, вы также сможете гораздо проще делиться своим кодом.
ИИ создает проблемы подобного рода; наиболее частая причина заключается в том, что он обучался на устаревших источниках. Они уже исчерпаны, а нового материала появляется не так много, что может привести к устареванию зависимостей и аналогичным проблемам.
Статический анализ в сочетании с ИИ как решение
Обратная сторона заключается в том, что этот вид анализа существует уже давно, и на то есть веские причины. Во-первых, результаты детерминированы.
Если вы запустите инструмент статического анализа кода десять раз, он выдаст вам тот же набор результатов десять раз. Если вы запустите его десять раз, это не обойдется вам дороже, так как он не потребляет токены. Если вы дадите ИИ один и тот же фрагмент кода 10 раз, вы получите 20 ответов.
Это быстро и дешево: если сравнить рецензента на базе ИИ со статическим анализом, то обычно статический анализ работает намного быстрее. Возвращаясь к вопросу детерминированности, вы можете привязать каждый результат к конкретной проверке и увидеть, почему это является проблемой.
Это станет еще более важным по мере ужесточения требований к соблюдению нормативных стандартов. Одним из важных примеров является новый Акт ЕС о киберустойчивости (EU Cyber Resilience Act), который уже действует в некоторых сферах. Часть этого закона требует создания спецификации состава программного обеспечения (SBOM). Если вы используете ИИ, это будет сложно. Если вы используете статический анализ кода и можете показать отношение «один к одному» между результатом и исходным кодом, вы с большей вероятностью будете соответствовать требованиям. Тем не менее, у обоих подходов есть свои плюсы и минусы.
Плюсы и минусы статического анализа и анализа с помощью ИИ
Он не может понять намерение вашего кода, поскольку в основном ищет паттерны. Здесь на помощь приходит ИИ. Если вы хотите проверить, делает ли код то, что вам нужно, в разных файлах или во всем проекте, на предмет логических проблем, — вот тут-то и вступает в дело ИИ.
Идеальным вариантом было бы использование комбинации статического анализа в качестве надежной базы и ИИ поверх нее. Человек пишет код, и ИИ тоже может написать какую-то его часть. Затем, когда вы запускаете свой конвейер (пайплайн), статический анализ выполняет первичную проверку. Qodana может проверять наличие любых проблем, а также автоматически создавать быстрые исправления. Таким образом, вы можете автоматизировать процессы даже без ИИ.
Эти быстрые исправления генерируются не с помощью QIA, что дает вам общие преимущества статического анализа: он быстрый, не требует дополнительных затрат и надежный. Затем вы переходите к выбранному инструменту ИИ, проверяете оставшуюся часть и создаете исправления для других сложных проблем, таких как логические ошибки или рефакторинг. Это может дополнить ваш пайплайн.
В идеале у вас получается замкнутый цикл: ИИ возвращает код обратно в пайплайн для статического анализа, чтобы статический анализ мог перепроверить, что созданный ИИ код соответствует требованиям и проходит ваши стандарты качества кода и безопасности. После этого вы можете объединить код в свою основную ветку.
Это звучит трудоемко, но ирония в том, что каждый раз это занимает всего пару минут и может сэкономить время в будущем. Потратить пару минут сейчас лучше, чем часами исправлять невыявленные проблемы позже.
Что говорят цифры?
Уже существуют исследования, которые демонстрируют преимущества такого подхода. Если вы комбинируете статический анализ с вызовами LLM, объем использования токенов сокращается на 72–92%, при этом объем кода, используемого в исследовании, увеличивается. Второе исследование показало, что при использовании такой комбинации в вашу мастер-ветку может попадать до кода, написанного LLM.
Вот краткий пример того, как это может выглядеть в Qodana или любом другом инструменте статического анализа на ваш выбор. Мы поддерживаем самые популярные игровые движки «из коробки». Вот как это выглядит в самой Qodana. Обычно разработчику не приходится проводить здесь много времени. Это удобно для тимлида или менеджера проектов. Один из участников команды Qodana «вайб-кодил» (vibe-coded) этот пример проекта ниже. Это был банковский фронтенд на Java, и само «вайб-кодирование» заняло всего несколько минут, чтобы поднять его и запустить.
Посмотреть демо Qodana
Qodana обнаружила 126 проблем и предоставила удобный способ быстро понять, что действительно важно. После этого к ним можно применить быстрые исправления. Существуют различные способы настройки (с разной степенью автоматизации).
Здесь мы сделали это в рамках конвейера GitHub Actions. Затем мы поместили оставшуюся проблему в Baseline (базовую линию). Как только они попадают в Baseline, они перестают вас тормозить. Когда вы в следующий раз запустите сканирование с помощью Qodana и обнаружите новые проблемы, в идеале 3 из них исправятся автоматически, и вы увидите только 2 новые. Таким образом, становится проще понять, на что потратить свое время.
Если мы посмотрим на пять оставшихся проблем, то увидим дублирующийся код. Хотя их можно просмотреть в Qodana, исправить их отсюда нельзя. Поэтому, если мы откроем это в IntelliJ IDEA, вы увидите, что инструмент переносит нас на точную позицию в кодовой базе IntelliJ IDEA.
Это работает для наших IDE, а также для Visual Studio, Visual Studio Code и Cursor. Вы также можете использовать наш CI-инструмент. Здесь вы можете просмотреть такие проблемы, как дублирование кода, наведя на них курсор (зависит от вашего решения), а затем перейти к дополнительным действиям (more actions), действиям ИИ (AI actions) и попросить ИИ исправить эти проблемы за вас.
Вы можете сделать это вручную или с помощью агента, полуавтоматизировав процесс, чтобы он работал в фоновом режиме, а на выходе вы получили чистый код. Если вы хотите узнать больше, свяжитесь с нами, и мы покажем вам, как этим пользоваться, либо вы с вашей командой сможете попробовать инструмент бесплатно.
Пользователи также пробовали применять Qodana для разработки игр. Прочитайте, как Doc Bok использовал Qodana для игры в Minecraft, или узнайте, как Qodana работает в проектах на Unity и Unreal Engine.
Когда вы просите ИИ добавить тесты, со временем эти тесты и все репозитории начинают переполняться, и даже такие тривиальные процессы, как линтинг, могут начать тормозить. Есть ли у вас опыт с этим?
В некоторых случаях вам приходится проходить через десять разных кругов, чтобы выпустить код. В большинстве случаев это происходит из-за того, что кто-то запустил пайплайн, но никто его никогда не проверял на предмет того, что имеет смысл, а что нет, хотя статический анализ не должен вас тормозить. Поэтому в Qodana так называемый режим pull request проверяет только измененные файлы, и это должно занимать всего минуту или две.
Насколько хорошо встроенные в IDE агенты JetBrains могут считывать результаты работы инструментов статического анализа среды разработки?
В Rider есть функция под названием Hooks (Хуки). Каждый раз, когда агент генерирует код, он вызывает хуки в Rider. Один из них отвечает за переформатирование кода, а другой — за проверку текущих проблем в файле, выполнение линтинга, проверку ошибок и передачу отчета агенту. После этого агент может сгенерировать код заново в соответствии с вашими стандартами или исправить именно то, что вы попросите. Этот механизм носит детерминированный характер, поэтому агент вынужден использовать хуки, а не просто следовать рекомендациям. Хук активируется и выполняется каждый раз.
Обратите внимание: широко распространенные технологии ИИ относительно новы, и результаты стремительно развивающихся данных всегда требуют тщательной проверки, включая данные, представленные в этой публикации.
Особая благодарность Каю (Kai) за его экспертные мнения.
