Когда-то я писал про систему DIDACT (
Когда-то я писал про систему DIDACT (https://t.me/seeallochnaya/573) — инструмент внутри Google, который берёт на себя часть процесса разработки и тем самым увеличивает эффективность программистов. Это не только код писать, но и улучшать его качество, покрытие тестами, помогать отвечать на комментарии и делать предложения по исправлению ошибок.
Вчера Google выпустили блог Safely repairing broken builds with ML, где, как следует из названия, рассказывается о части этой системы на этапе «сборки» кода. Сборка — это перевод человекочитаемого кода в финальный артефакт в машинном формате, например, приложение или исполняемый на сервере файл. И вот такая сборка может ломаться, если вы наделали в коде ошибок. Какие-то вещи заметить просто и без сборки, с помощью десятка эвристик и инструментов, а какие-то всплывают лишь после того, как программист отправил свой код на сборку (так как они сложны и возникают из-за неочевидных взаимодействий).
Иногда сборка ломается, и приходится идти читать логи ошибок, смотреть, что там не понравилось машине — а затем придумывать исправление. Всё это отнимает время, а когда у тебя одни из самых высокооплачиваемых специалистов, то улучшения даже на проценты на таком масштабе дают существенный выигрыш.
В общем, эта система учится по вашему коду и ошибке сборки предсказывать необходимое изменение в коде, чтобы всё заработало. Поскольку хочется избежать багов и уязвимостей, то после генерации нескольких кандидатов система фильтрует их (и может показать 0 вариантов). Такое изменение предлагается внести в одну кнопку — программист смотрит, жмёт Apply, и идёт работать дальше.
Систему раскатили на весь Google на 11 недель, побив разработчиков на 2 равные группы для оценки эффекта. Оказалось:
— на 2% уменьшилось время работы над одним изменением перед его отправкой на сборку
— на 2% уменьшилось время, проходящее от отправки на ревью до закрытия (включая внесение изменений по обратной связи от других сотрудников)
— среднее количество изменений, отправляемых сотрудниками выросло на 2%
— при этом количество откатов назад не изменилось статистически значимо (то есть новые изменения не вносят какие-то другие проблемы)
Ждём двузначных чисел улучшений через годик-два, с улучшением моделей!
Вчера Google выпустили блог Safely repairing broken builds with ML, где, как следует из названия, рассказывается о части этой системы на этапе «сборки» кода. Сборка — это перевод человекочитаемого кода в финальный артефакт в машинном формате, например, приложение или исполняемый на сервере файл. И вот такая сборка может ломаться, если вы наделали в коде ошибок. Какие-то вещи заметить просто и без сборки, с помощью десятка эвристик и инструментов, а какие-то всплывают лишь после того, как программист отправил свой код на сборку (так как они сложны и возникают из-за неочевидных взаимодействий).
Иногда сборка ломается, и приходится идти читать логи ошибок, смотреть, что там не понравилось машине — а затем придумывать исправление. Всё это отнимает время, а когда у тебя одни из самых высокооплачиваемых специалистов, то улучшения даже на проценты на таком масштабе дают существенный выигрыш.
В общем, эта система учится по вашему коду и ошибке сборки предсказывать необходимое изменение в коде, чтобы всё заработало. Поскольку хочется избежать багов и уязвимостей, то после генерации нескольких кандидатов система фильтрует их (и может показать 0 вариантов). Такое изменение предлагается внести в одну кнопку — программист смотрит, жмёт Apply, и идёт работать дальше.
Систему раскатили на весь Google на 11 недель, побив разработчиков на 2 равные группы для оценки эффекта. Оказалось:
— на 2% уменьшилось время работы над одним изменением перед его отправкой на сборку
— на 2% уменьшилось время, проходящее от отправки на ревью до закрытия (включая внесение изменений по обратной связи от других сотрудников)
— среднее количество изменений, отправляемых сотрудниками выросло на 2%
— при этом количество откатов назад не изменилось статистически значимо (то есть новые изменения не вносят какие-то другие проблемы)
Ждём двузначных чисел улучшений через годик-два, с улучшением моделей!
Источник: Сиолошная
2024-04-24 08:21:06