Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС 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 точечным инструментом, не распыляясь на множество функций.