Привет, Хабр. Я Матвей Лихота, старший Go-разработчик и DevSecOps. Как это часто бывает с внутренними инструментами, идея этой утилиты появилась уже после того, как у нас упал прод. Во время хотфикса сотрудник забыл обновить в одном из двух сервисов версию библиотеки с контрактами и в результате в зависимостях осталась предыдущая версия. Перед слиянием код собирался и тесты проходили, но после деплоя сервис упал с ошибкой 500: новое поле в структуре запроса не появилось на сервере. Пришлось откатить изменения и даунтайм был ощутимый.

Снова попадать в такую ситуацию никому, конечно, не хотелось. Можно было бы добавить пункт в предрелизный чек-лист, но кто будет заполнять его во время хотфикса? Можно было еще раз напомнить разработчикам про версии, но такие напоминания работают от силы пару недель, а потом об этом снова забывают.

Тогда я решил, что теперь проверять актуальность зависимостей будет CI. Так и появился Dependency Validator.

Привет, Хабр! Я Матвей Лихота, старший Go-разработчик. В предыдущем материале я показывал, как получить Go-код из OpenAPI. Теперь хочу сделать еще один шаг назад — к моменту, когда контракта еще нет.

На демо частенько можно увидеть, как по простому запросу «напиши CRM» или «собери интернет-магазин» LLM уже через минуту готовит сервер, модели, миграции и тесты. Но в реальности, конечно, все происходит чуть иначе: проверяем код, а там — сюрприз-сюрприз ошибки. Повторив тот же промпт, мы получим другую архитектуру и снова потратим время на проверку. И нет гарантии, что после переделки ошибок не станет еще больше.

Конечно, все дело в промпте. Согласитесь, странно просить модель понять задачу, выбрать архитектуру, определить границы и все реализовать за один шаг? Что, если LLM сначала проектирует систему и выпустит OpenAPI, Proto, JSON Schema, CloudEvents и AsyncAPI? А код мы добавим чуть позже: за повторяемую часть будут отвечать обычные генераторы, а за проектно-зависимую — разработчики и агент в контексте репозитория.

Такой подход, где главным артефактом становится контракт, а код — его производной, можно назвать Documentation Driven Agent Development или Specification Driven Agent Development. Как он работает — покажу на примере разработки простой автоматической телефонной станции (АТС), а еще проведу границу между генераторами и агентами.

Привет, Хабр. Я Матвей Лихота, старший Go-разработчик из МТС Web Services. По моему опыту, документация, которую пишут руками отдельно от кода, устаревает уже в момент следующего коммита. Из-за этого мы в команде тратили до 20% времени на поддержание актуальности swagger-документации в десятке микросервисов. И когда ошибки интеграции уже стали привычным фоном, мы все-таки решились и перевернули все с ног на голову: внедрили Documentation-Driven Development (DDD) — подход в разработке, когда процесс начинается с документации. 

Что за подход и что он дал в итоге, зачем понадобилась утилита oapi-codegen и как мы генерируем Go-код из OpenAPI-спецификаций — подробно рассказал и показал под капотом.