Генери и выгоняй или как работать с людьми которые отстают от мира и только начали использовать ГЕНУ
История одного проекта
Вводная тема, или как я рулил роботами на ROS
Началось все в марте, если мне не изменяет память. Платформа еще продвигается, я на нее по-прежнему рассчитываю, но тут мне предложили поучаствовать в проекте управления роботами. Подумал я: почему бы и нет.
Проект на Java + Go, все знакомо: на Go у меня года три коммерческой разработки, на Java лет пятнадцать. UI на React, и он мне тоже знаком, только нелюбим до отвращения. Ну что поделать, на чем просят, на том и пишем.
С Геной я в тот момент играл еще не очень активно. Был какой-то Qwen, тогда еще бесплатный, был GitHub Copilot с базовыми версиями Sonnet, а больше всего я пользовался Raptor, тоже в Copilot. Я коммитер в одном из проектов Linux Foundation (внезапно), поэтому Pro-доступ к GitHub у меня до сих пор есть.
Начал я потихоньку писать код системы, а в начале, как обычно, нарисовал mind map: вспоминаем мой инструмент и пользуемся. Но ехать на чистом Go/gRPC заказчик не решился. На роботах стоит ROS (Robot Operating System), поэтому туда водрузили rosbridge: он на питоне заворачивает этот протокол в websocket и передает все в виде JSON.
“Давайте сделаем нормально”, - говорил я. Но, как всегда, все считают себя самыми умными, и меня не услышали. Может, это моя проблема, и мир постоянно макает меня в это носом :-) В итоге огребли и настроили велосипедов вокруг rosbridge, потому что поначалу он зависал очень часто.
С этого момента начался мой первый опыт портирования кода с Opus. Буквально за неделю я получил работающего клиента к rosbridge на Go, портированного с open-source roslibjs. Думаю, с той же скоростью можно было написать его и с нуля по спецификации. Но модели тогда были туповаты, плотного опыта общения с ними у меня было мало, и казалось, что работающий код проще переложить на другой язык не только в своей голове, но и в голове модели. Так что портировал пофайлово. Получилась библиотечка на 10 тысяч строк на Go, и это казалось очень много. Наверное, я был наивным и все еще полностью привыкшим к ручному программированию.
Потом я встроил ее в свое общее видение архитектуры, и поехало. Доделывать ее после пришлось совсем чуть-чуть, и она до сих пор ведет себя как нужно.
Дальше было много всего: сначала один сервис, потом сервис для управления конфигурациями роботов, потом масштабирование для большего парка роботов, отладка стека соединений и переподключений и так далее. Получилось вполне интересно, и теперь могу говорить, что рулил реальными роботами.
Что могу сказать в итоге: Spec Driven разработка себя оправдывает. Можно получить вполне работающий сервис, но его все равно приходится дописывать руками. И самое интересное, что написание кода - не главное. Много времени уходит на эксперименты и перебор вариантов архитектуры, чтобы получить решение, которое можно поддерживать. Решение, из-за которого тебя не дергают. Решение, которое просто работает и не тревожит.
А еще больше времени уходит на обсуждение, обсуждение, рисование диаграмм, утрясание ключевых и боковых моментов и тд, оно и раньше всегда было, и меньше его не стало, а из за того что код можно генерировать быстрее, стало только более интенсивным.
Из интересного попутно: на основе turtlesim из ROS 2 Humble я сделал докер-образ с полноценным симулятором для QA. Почему-то QA никто не уважает. А я большую часть карьеры делал инструменты для разработчиков, и мне очевидно, что любой продукт нужно еще и правильно тестировать: проверить все сценарии и не посшибать себе нос по углам. Так что на выходе получились и инструменты для QA: можно развернуть весь стенд со всеми сервисами и прогнать все тесты.
Работой, которую я проделал, я доволен. Но от того, что началось дальше, прямо стынет кровь в жилах.
Как отличить странного менеджера от нормального?
Думаю, все мы уже используем Гену, чтобы писать “драфтовый” код. Его нужно выверять и проверять, и только после этого куда-то пускать. Но это понимают еще не все. И вот пришел он, включил две свои подписки за Nx$, и поехало: 100% покрытие кода для фронта, полное покрытие e2e, +500 тестов, которые идут час на Mac mini M4 Pro. Думаете, кто-то в состоянии просмотреть все, что там генерируется?
Что еще печально, даже описания к пулл-реквестам он делает через модель. Я ему даже скинул свой скилл, чтобы он перестал писать слоп по 50 строк в описаниях git-коммитов и портянки строк в тестах. Но тщетно. Пока человек сам не поймет, никто ему ничего не объяснит.
Вот как это выглядит в цифрах. Обезличенная статистика по 24 репозиториям проекта с конца января по начало октября: коммиты по всем веткам без merge, сгенерированный код, lock-файлы и выгрузки не считаются.
Полоса показывает, сколько строк кода и тестов участник добавил за все время, светлая часть - тесты. Риска на полосе - сколько его строк живет в основных ветках сейчас, по git blame. Разработчик 1 - это и есть тот самый менеджер. Он начал коммитить 21 августа и за шесть недель добавил почти половину всех строк тестов проекта (48%). В основных ветках из его кода осталось 20%, из тестов - 37%. У меня 65% и 75%. И это без 5,5 миллиона строк CSV-выгрузок, которые он закоммитил вдобавок: это 96% всех его добавленных строк.
По неделям видно, как это происходило: до конца августа линия разработчика 1 лежит на нуле, а потом за одну неделю он добавляет 93 тысячи строк. Остальные участники вместе, не считая меня, ни за одну неделю не добавляли больше 35 тысяч.
Что еще настораживает: некоторые люди считают, что 100-процентное покрытие гарантирует качество. Да как бы нет :-) На моей практике раньше такое покрытие было недостижимо, и при этом выпускали вполне качественные продукты. А тут вуаля, захотелось 100%.
По не зависящим от меня причинам проект немного затух, так что пишу сводку той части своей жизни, которая была посвящена управлению роботами. Как бороться с такими менеджерами, мне пока непонятно.
Предрассудки multi-repo и как с ними бороться
Что было мучительно больно. В Платформе у нас один репозиторий, из которого мы собираем весь продукт. В этом есть плюсы: всегда понятно, что стоит версия v0.8.x и все компоненты в ней свежие. Накладных расходов на сборку чуть больше, зато всегда можно по одной версии проверить и найти, что и где сломано.
А тут захотелось много сервисов в разных репозиториях, и поехал цирк с конями. Никто не понимает, где какая версия, разработчики делают только свой сервис, кто что и куда деплоит - непонятно, бардак. А еще экономия на стендах и так далее. В общем, мрак, не нравится мне разработка в куче репозиториев. Или я просто не умею ее готовить.
И странное отношение людей: подними ты в докере весь продукт и делай все локально. Я понимаю, если у тебя совсем слабое железо, но и тогда всегда можно выкрутиться.
Заключение
В целом команда отработала хорошо, не без сложностей конечно, но всем спасибо было приятно со всеми работать.