LLM на службе разработки: как мы научили нейросети проводить код-ревью

от автора

Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС Web Services. Наша команда занимается плагинами DevTools, которые упрощают и ускоряют создание софта, в том числе за счет сокращения рутинных операций.

У нас уже есть целое семейство внутренних инструментов. Один из них — DevTools Copilot, который непосредственно из среды разработки позволяет взаимодействовать с LLM в режиме чата. А теперь мы реализовали DevTools Code Review, который помогает проводить самостоятельное код-ревью. В этой статье расскажу, как работает плагин и чего мы с его помощью добились.

Как мы помогаем разработчикам в самостоятельном ревью

Код-ревью — неотъемлемая часть создания кода. Процесс увеличивает вовлеченность команды за счет совместного обсуждения изменений, да и в целом улучшает проект. Однако он требует времени.

В теории все просто: закоммитил → посмотрели → апрувнули. А в реальном мире, отправляя очередной коммит, разработчику надо дождаться, пока коллега освободится. При этом фрагменты кода на ревью могут выстраиваться в большие очереди и не помещаться в одну встречу.

На некоторых проектах в команде может вовсе не оказаться разработчика с нужными компетенциями — непонятно, к кому обращаться за апрувом. А там, где подходящих специалистов несколько, встает вопрос единообразия. Каждый человек проводит анализ со своей степенью погружения. И иногда ревью может быть слишком поверхностным, обращающим внимание лишь на простые вещи на уровне опечаток. В итоге часто код попадал в прод без внешнего ревью (его смотрел только сам автор). Мы решили повысить эффективность этого процесса с помощью AI-ассистента.

Автоматизировать код-ревью пытались давно — есть линтеры, инструменты, подсвечивающие опасные фрагменты кода и т. п. Но они не использовали LLM. Когда мы взялись за задачу, уже существовали аналоги с ИИ, но они еще не закрывали все наши потребности. Тот же GitHub Copilot не умел делать полноценное ревью. Плюс мы отдаем приоритет собственным разработкам.

У нас было несколько вариантов решения этой задачи. Например, запуск бота в GitLab. Но это не наша компетенция, плюс в плагины к средам разработки мы погрузились уже достаточно глубоко, поэтому остановились именно на таком варианте.

Архитектура DevTools Code Review

Изначально мы поставили задачу следующим образом: плагин не должен быть отдельным инструментом с большим количеством своих настроек. Нужна интеграция с существующими решениями — в нашем случае со средой разработки.

DevTools Copilot — довольно функциональный инструмент. В теории с его помощью можно было делать код-ревью, но все же он для этого не очень подходит — от пользователя требуется много разных действий: выбрать файл, добавить в промпт, выделить фрагменты, попросить ревью. Этот процесс в масштабах команд «не взлетел». Нужно было что-то очень простое, что автоматизирует рутину.

Созданный нами плагин DevTools Code Review отслеживает изменения в проекте, обрабатывает файлы и строит промпт. При этом запросы к LLM он отправляет через интеграцию с DevTools Copilot. Получается, что DevTools Code Review — своего рода дополнение к DevTools Copilot и не может без него существовать. Но за счет этой интеграции мы сократили время разработки, а заодно и нагрузку на устройство пользователя.

Как работает плагин

Мы постарались не перегружать DevTools Code Review функциями — хотели сделать максимально легковесное решение, чтобы им можно было быстро начать пользоваться.

Плагин работает в формате ассистента. С помощью специального алгоритма он смотрит внесенные в проект изменения и при попытке коммита предлагает выполнить ревью — в окне среды разработки выскакивает соответствующее уведомление. Если пользователь соглашается, плагин собирает все изменения в промпт и отправляет их через DevTools Copilot в LLM. Для улучшения контекста в промпт добавляется также весь код из файла (по умолчанию промпт для проверки рассчитан на анализ только измененного кода, но пользователь может его скорректировать, чтобы плагин оценивал весь код).

В DevTools Copilot реализована работа с несколькими моделями, которые уже доступны в компании (ее можно выбрать в настройках), а в DevTools Code Review есть конфиг, так что пользователь может скорректировать процесс код-ревью под себя, в частности, подстроить плагин. Ответ приходит в DevTools Copilot и отображается в общем окне с DevTools Code Review.

На наших проектах есть определенные стайл-гайды. Они необходимы, чтобы одни и те же фрагменты кода комфортно редактировать командными силами. Даже через пару месяцев коллега должен вернуться к нему без длительных изысканий. Для этого используется определенный код-стайл и типичные решения. Плагин приводит все к единому стилю.

Если к коду есть конкретные замечания, они отображаются в описательном виде — какие места имеют проблемы.

Примеры на кейсе использования Typescript + React:

Пример 1.

useEffect(() => {     fetchData();   });

В нем DevTools Code Review иправил ошибку в зависимости useEffect:

В текущем коде зависимость useEffect не указана, что может привести к бесконечной рендеринга компонента при каждом обновлении состояния. Добавьте пустой массив зависимостей:

useEffect(() => {   fetchData(); }, []);

Пример 2.

let result = [];         for (let i = 0; i < data.length; i++) {           if (x && data[i].popularity > 30) {             result.push(data[i]);           } else if (!x) {             result.push(data[i]);           }         }

Этот фрагмент плагин улучшил так:

Логика фильтрации языков программирования может быть упрощена с использованием методов массивов, таких как filter. Это сделает код более читаемым и эффективным:

const filteredLangs = x    ? data.filter(lang => lang.popularity > 30)    : data; setLangs(filteredLangs);

Пример 3.

useEffect(() => {     const handleScroll = () => {       const position = window.scrollY;       setScrollPosition(position);              if (position > threshold && !isAboveThreshold) {         setIsAboveThreshold(true);         if (onScroll) {           onScroll(position);         }       } else if (position <= threshold && isAboveThreshold) {         setIsAboveThreshold(false);       }     };     window.addEventListener('scroll', handleScroll);    }, [threshold, isAboveThreshold, onScroll]);

Здесь плагин предложил исправить ошибку в зависимости useEffect:

Аналогично предыдущему компоненту добавьте зависимость onScroll для корректной работы эффекта:

useEffect(() => {   const handleScroll = () => {     const position = window.scrollY;     setScrollPosition(position);     if (position > threshold && !isAboveThreshold) {       setIsAboveThreshold(true);       if (onScroll) {         onScroll(position);       }     } else if (position <= threshold && isAboveThreshold) {       setIsAboveThreshold(false);     }   };   window.addEventListener('scroll', handleScroll);   return () => {     window.removeEventListener('scroll', handleScroll);   }; }, [threshold, isAboveThreshold, onScroll]);

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

Еще DevTools Code Review иногда предлагает заменить код на свои фрагменты. Если пользователь посчитает совет адекватным, то его можно прямо из чата вставить в проект:

Почему нас не пугают ошибки в предложениях от плагина?

LLM, как известно, любят галлюцинировать и выдавать ошибочный код. Но и разработчики могут не понять код или задание. Половина комментариев в «человеческих» код-ревью начинается с формулировки «правильно ли я понял».

Ответ модели и ее рекомендации мы сделали необязательными. Настаивать на коде от ИИ — это нонсенс. Плагин подсвечивает проблемные места, а итоговое решение за разработчиком, который вправе проигнорировать рекомендации.

Языковые модели активно развиваются. Буквально каждый месяц выходят новости о том, что появляется новая продвинутая версия LLM. Поэтому мы продолжаем тестировать и выбирать удачную модель для ревью.

Чего мы добились

Плагин уже выпустили в прод. До этого его тестировала фокус-группа, которую мы собрали еще до релиза из ребят, которые вызвались сами после анонса в команде. При первой возможности мы выдали им доступ для бета-теста. Уже на этой стадии мы получили позитивные отзывы и идеи по расширению функциональности.

После внедрения плагина у нас в команде:

  • Сократилась пауза между коммитом и запуском код-ревью. Обратную связь от плагина можно получить даже ночью.

  • Уменьшилась очередь фрагментов кода на ревью — процесс наконец начал укладываться во встречу.

  • Облегчилась жизнь разработчиков, у которых нет напарника по стеку.

  • Сэкономили время тех, кто занимается код-ревью для коллег.

В целом для компании мы повысили комфорт сотрудников, не проседая в качестве кода, и реализовали механизм, который приводит весь новый код к принятому стилю. По статистике, пользователи плагина отправляют на 20% больше Merge Request по сравнению с теми, кто использует AI-ассистенты без встроенного Code Review. Количество багов на релиз уменьшилось на  8%.

Результат оцениваем как позитивный — после анонса мы увидели, как плагин быстро распространился по другим командам.

Сейчас решение уже пару месяцев в эксплуатации. В ближайших планах — собрать обратную связь и определиться с вектором дальнейшего развития. Добавим функционала, однако планируем так и оставить DevTools Code Review точечным инструментом, не распыляясь на множество функций.


ссылка на оригинал статьи https://habr.com/ru/articles/939168/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *