Никита Ульшин про IT
Telegram ·
Как Imprint пробует ускорить код-ревью с помощью small-change
Уилл Ларсон (которого я очень люблю читать) в последнее время пишет статьи про построение агентной разработки. На днях он выложил статью о модели ускорения код-ревью для маленьких изменений.
Imprint столкнулись с той же проблемой, что и вся индустрия: значительный рост количества PR (средний инженер мержит в 4! раза больше PR, чем 2 года назад). При этом медианное время ревью выросло с 33 до 77 минут. Поэтому они решили ускорить проверку небольших изменений.
⭐️ Интересные идеи
➡️ Часть изменений автоматически помечаются как small-change. Условия: PR меньше 1000 строк, ai-code-review не нашел ничего критичного, автор замержил 10+ PR в этот сервис или директории, влияние ограничено N сервисами, общие библиотеки и утилиты исключены, отдельные пути можно запретить.
➡️ small-change проходят ревью отдельным скиллом. Этот скилл не комментирует, а только ставит аппрув или оставляет PR без действия.
➡️ Ожидание: если что-то по результатам мержа small-change упало, то проблема заключается в системе. По результатам такого падения нужно улучшать harness, CI/CD, механизмы верификации и т. д.
➡️ Для шаринга знаний у них есть второй скилл — review-pr-cluster. Он разбирает группы PR и предлагает общие темы для обсуждения и новые проверки.
Ларсон честно признаётся, что текущих результатов пока недостаточно для того, чтобы делать какие-то далеко идущие выводы. Сейчас всего около 10% PR помечаются как small-change — он характеризует это как признак того, что сама концепция работает, но её ещё нужно допиливать.
Для меня эта статья важна тем, что показывает, что я не одинок в своей борьбе с ботлнеком в код-ревью. Мне нравится, что Уилл Ларсон рассматривает изменения в процессе через призму функций самого код-ревью и старается их не потерять. Меня тоже беспокоит вопрос того, как не потерять полезные функции чтения кода (например, шаринг знаний внутри команды).
small-change — это не фундаментальный ответ, а скорее эксперимент конкретной компании. Мне здесь интересен сам подход: выделить ограниченный класс изменений для быстрого ревью и отдельно продумать, как сохранить обмен знаниями в команде.
Я сейчас разбираюсь, как разные команды перестраивают код-ревью под агентскую разработку, и планирую собрать из этого отдельный ресёрч. Если вы уже меняли процесс у себя — расскажите, что попробовали и что получилось. Особенно интересно, что не сработало.
// А у вас какие-нибудь изменения уже проходят без человеческого ревью?
