28.08.2025 07:00
DobryninV 0 331 Источник

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

Комментарии (0)