Transcription
Всем привет.
Приветствую. Елизет, можем стартовать, на самом деле. Передаю тебе слово.
Да. А, коллеги, всех рада приветствовать в наш прекрасный четверг. Уже финишная прямая наша рабочая неделя, и хочется поговорить про собственный опыт, про путь от мануалов опи к автоматической генерации через Open AP с помощью искусственного интеллекта. А тема такая достаточно распространённая, актуальная, потому что с интеграциями, думаю, сталкивались многие, работают тоже многие. На проектах встречается практически везде в 99% случаев. И хочется понять уже, а как же эту интеграцию можно автоматизировать, как её писать, перестать писать, а начать генерировать, и вот к чему это в итоге может привести.
А, немножко познакомимся. Меня зовут Акманова Елизавета. Я являюсь ведущим аналитиком группы компании USTech и уже там более 5 лет проектирую интеграции в разных форматах: и в табличных, и вот недавно перешли на Open AP. И моя основная задача рассказать вам о том, почему вообще мы ушли от описания АПИ в виде документации, почему этот подход нам в какой-то момент перестал подходить и какие преимущества мы перед таким способом нашли в Open? Что это за формат? Какие он нам даёт дополнительные инструменты для работы с интеграциями?
А после того, как мы с этим инструментом познакомимся, перейдём к тому, как его можно автоматизировать, как этот инструмент отлично работает в связке с искусственным интеллектом и получается такой симбиоз. А, и не только про сами технологии поговорим, но и про сложности этих технологий, про а то, какие трудности у нас были во время перехода от одного подхода к другому. И давайте уже начинать с первого же пункта.
А, и немножко такой предыстории. А у нас на проекте раньше документация велась в базах знаний, в табличном виде, где мы писали системные названия, а, полей, их описание, типы данных, обязательность. Ну, всё, всё по классике. А при этом у нас уже существовал на тот момент свагер, но он генерировался автоматически из кода. То есть это делали разработчики уже после того, как, э, в соответствии с документацией они реализовали, а, тот или иной программный интерфейс. И с точки зрения процесса он выглядел, ну, в упрощённой форме примерно так. У нас аналитик писал документ, при этом разработчики эти документы никак не валидировали и не были с ними связаны. Они приступали на основе него писать код. В итоге у нас получался сервис и в конечном итоге уже а наш продукт.
И вот какие у нас здесь были основные сложности, связанные с описанием АИ в виде документации. Первое - это неактуальные данные в документе. Бывали случаи, когда разработчики решили поменять или название полей, или структуру. Поэтому иногда это это нужно было уведомлять аналитиков об этих изменениях. Аналитики могли забыть эти изменения, внести в документацию, то есть её актуализировать. И как итог мы получали, что очень редко документация вообще соответствовала тому, что на самом деле было разработано и реализовано. То есть за счёт вот этой отсутствия валидации разработчикам ещё на этапе Discoverovery и их дальнейшим корректировками.
А после того, как мы документацию разработали, у нас могли быть ошибки при генерации свагера. А ошибки были разного характера. Иногда у нас параметры отображались, но не совсем те, которые действительно были реализованы. То есть они отмечались, например, как обязательные параметры, а или, например, вообще отсутствовали. У нас был один такой очень сложный кейс, когда в Свагер просто не пробрасывались query параметры все, которые начинались с из из active, is done, is close. А это очень критично для нас было, потому что это базовый параметр, по которому у нас происходила фильтрация. Поэтому свагер у нас тоже был не всегда актуальный.
И на самом деле где где-то, чтобы обойти вот эти проблемы, мы строили костыли. А если вы думаете, что я шучу, то нет. Вот вот это тот самый случай, когда у нас параметры а при свагере написаны с красной звёздочкой, что они обязательны, но как стоило тебе открыть описание полей, то уже написано, что они опциональные. А комментарии разработчика на эту тему, что Свагер не удалось победить с дефолтными полями, поэтому решили, а, просто писать описание. А время потраченное, ресурсы сожгли на то, чтобы с этой проблемой побороться, в итоге не получилось. И вот такой косцель обходной путь мы в итоге придумали. Это было для нас тоже одним из камней преткновения за счёт того, что свагер генерировался напрямую из кода.
Дальше у нас вообще существовало таким образом два источника правды. С одной стороны есть свагер, который не сильно детально описан. То есть там, да, есть параметры, можно повызывать методы, но непонятно, что они обозначают, как они заполняются, есть ли какой-то паттерн, регулярка, чтобы его заполнять, есть ли какие-то, а, дефолтные значения и примеры вообще запросов и ответов. Это всё можно было найти в документации. А документация не всегда соответствовала тому, что действительно было реализовано. Поэтому у нас существовало два источника правды. И это было достаточно сложно поддерживать, потому что вот этот дубль информации, он всё-таки существовал.
А мы на это всё посмотрели, поняли, что мы хотим идти в ногу со временем и эти все проблемы устранить. Поэтому от описания документации в виде таблицы документации мы решили перейти к формату, а, который, а, не содержит в себе описание через документацию. То есть её нужно было упразнить и сделать единый источник правды - это свагер. Но как это сделать? Какие есть для этого инструменты? Какие есть правила перехода? И вот когда эту всю историю начинаешь изучать, ты сталкиваешься с таким инструментом, который называется Open AP.
А тут мы переходим уже ко второму пункту нашего плана. Сейчас посмотрим на преимущество этого инструмента. И перед этим будет такой небольшой интерактив, где я, а, жду от вас, участники обратной реакции. Можете написать в чат ответ на вопрос, а чем вообще отличается Open AP от Свагера на том уровне, на которой там вы это понимаете, на котором вы знаете их основные особенности одного и другого понятия. Можете включить микрофон, пообщаемся голосом, это будет даже даже приятнее.
>> Ну, Openби - это, я извиняюсь, меня Антон зовут. А open - это стандарт само по себе описание, а Swager - это по факту инструмент для работы с этим стандартом.
>> Угу. Супер. Да. А вот и всё, всё замечательно. Давайте такой ещё наводящий вопрос. Open AP, вы сказали, это такой стандарт. А стандарт какого формата? В каком формате описывается Open AP?
>> Если
>> Jon,
>> ну если подразумевается базовые, то есть Jon, да, но он может быть и в ямлике, и формате, то есть два формата тоже зачитается.
>> Это супер. Да, всё действительно так. У нас ещё вижу в чате ответы. Спасибо за обратную связь. А есть, да, Openпи, а СВАР. А на самом деле всё верно. Мы с вами подметили. Панапе это, ну, такая спецификация, да, формат Jon формат Яam, он поддерживает все вида. А свагер - это инструмент. Инструмент, который работает на основе этой спецификации. Я думаю, там большинству из вас знакома эта картинка. Это наш стандартный свагер. И как нам получить Open AP, который под этот свагером лежит? На самом деле всё просто. У нас в хедерах есть путь, по которому мы можем это всё достать. Его нужно прописать в адресной строке. И вуаля, мы получаем JSON, на основе которого у нас TWвагер сгенерирован.
А я привыкла больше работать в формате YAML. Поэтому это можно тоже очень легко переконвертировать. Просто в адресной стке JON меняем на yam. У нас происходит скачивание документа. И после этого скачивания его можно открыть там в обычном блокноте и абсолютно то же самое посмотреть. Здесь уже будет писать формат описания в виде Ямла. И что из себя вообще Open AP представляет? У него есть несколько основных блоков. Первое - это метод данные, которые в себе содержит версию IP, которую мы используем, её описание, то есть, что она из себя представляет. Такое максимально верхнеуровневое наше первое приближение к вот формату интеграции. Дальше серверы, которые находятся на этом свагере, который можно вызывать, а, тоже не сильно много места занимают. Основные два блока - это описание наших запросов, где мы видим путь, метод, что он возвращает, какие есть у нас ответы, что мы по результату этого метода можем в итоге получить. А уже саму структуру, сами сообщения, схему данных мы видим дальше в виде компонентов, а, с типами, с обязательностью. Это всё можно прописывать дальше. И после того, как мы в данном, данной структуре, в данной спецификации всё опишем, можем проверить ещё до нашей разработки в через Swager Editor, где мы всю эту информацию отправим, и нам автоматически сгенерируется Swagер, который потенциально может быть реализован через эту спецификацию Open AP.
И мы решили, что описание вот этого Open App возьмёт на себя аналитик, то есть он не будет больше генерироваться из-кода. И как изначала изменился вообще наш процесс а разработки? А аналитики проектируют спецификацию, разработчики подключаются уже даже на этом уровне и эту спецификацию начинают валидировать, потому что в будущем она ложится именно в основу нашего кода и в основу нашего приложения. После того, как мы всё провалидировали, согласовали и приняли, что всё, у наш наш стандарт, он зафиксирован, идём уже на разработку, а, и получаем в итоге конечный продукт.
А как это всё повлияло на те проблемы, о которых я говорила ранее? А у нас больше а нету неактуальной документации, неактуальных данных, потому что аналитики сразу её описывают в формате свагера, и она лежит в основе кода. Поэтому код опирается уже на эту самую спецификацию, на этот самый документ. И по-другому, по сути, вот реализовано быть не может. А вторая наша проблема с ошибками при генерации. Ну, у нас разработчики перестали воевать со Свагером, перестали воевать с генераторами, потому что сейчас они у нас не генерируются, а основу нам даёт аналитик, и мы получаем свагер абсолютно корректный. И более того, а он помогает разработчикам даже генерировать свой исходный код. То есть мы стали не на основе кода генерировать спецификацию, а на основе спецификации генерировать код, то есть в обратную сторону. И разработчику осталось только навести порядок в коде согласно там кодстайлу или каким-то внутренним корпоративным правилам. И уже всё, всё у нас готово. И после этого у нас остаётся единый источник правды - это свагер с максимально полным описанием. У нас там абсолютно вся исчерпывающая информация относительно нашей интеграции. А, и нам для этого не нужно было оставлять документацию. Документация у нас осталась лишь внутренняя логика реализации этих методов, то, что работает под капотом, что в Свагере, к сожалению, написать нельзя. А уже сами программные интерфейсы и работа с ними у нас ведётся вот в данном формате.
Поэтому аналитики больше не думают о том, как поддерживать два документа одновременно и менять её по ходу разработки. А разработчики у нас при этом автоматически генерируют код на основе этой спецификации, которую мы им предоставили. А перестают воевать со свагером, потому что это просто не нужно больше делать. И также есть встроенная валидация того самого кода, который у нас в итоге получается. Для тестировщиков здесь тоже есть польза. Они начинают ещё на этапе разработки уже писать автотесты и точно также генерировать их. А таким образом мы этот процесс нашей разработки кратно увеличили.
Но опять же это же не сразу к нам пришло. Мы же уже набили шишки с документацией. И тут у нас стал логичный вопрос: а как вообще нам переписать вот эти все многолетние интеграции, которые мы проектировали из документации? Как нам их переводить, что нам для этого нужно? А, ну и глобально есть таких два стандартных процесса. Первый - это постепенная миграция, когда мы там берём один метод, который нам нужно доработать, переводим его в формату Open AP и потом уже дорабатываем так, как нам нужно. И вот так вот с каждой задачкой постепенно мы всё переписали. А второй формат есть кинуться прямо в омот с головой переписывать всё с нуля самостоятельно. А, но это бы заняло очень много времени, и аналитики бы не смогли заниматься там другими вещами, которые приносят уже прибыль бизнесу и напил каких-то тех фич.
А, но вот тут ко мне пришёл коллега и сказал мою любимую фразу: "А что, если?" А что, если мы используем искусственный интеллект для того, чтобы перевести документацию с одного вида в другой? У нас же есть тексты, есть стандартная спецификация. Наверняка это друг с другом может работать. И здесь мы логически переходим к третьему пункту, который касается использования искусственного интеллекта при генерации наших схем.
И первое, с чего хочется начать - это с базового промта, который мы для этого использовали. Он выглядит примерно следующим образом. А тут в нём есть роль. Роль - это работает как опытный системный аналитик. Когда мы искусственному интеллекту задаём конкретную профессию, которую он должен играть, он уже начинает использовать термины этой профессии, использовать, а те паттерны и то общение, которое присуще вот данной роли. И поэтому это делать, ну, я постоянно делаю, я всегда, э, искусственному интеллекту задаю роль, когда начинаю с ним общаться по тому или иному поводу. А есть чёткая задача, что нам на выходе нужно получить код формат Open AP, желательно в ямлике, потому что мы именно с этим форматом привыкли работать, для того чтобы нам создать описание апи методов, которые мы в итоге хотим получить. И дальше много-много контекста по типу какие методы у нас есть тела запроса, тело ответа, ну, то, что у нас уже лежит по сути в документации.
А когда мы всю документацию попытались скормить, думали счастливые, сейчас вот одним промтом всё сделаем, у нас заработает. Но на самом деле это не сработало. То есть у нас искусственный интеллект выдал абсолютно невалидную информацию, когда мы всё это скормили. А некоторые параметры были пропущены, некоторые названы не так, какие-то методы вообще не были реализованы. Ну, получилось, ну, концептуально вроде то, но абсолютно не соответствовало действительности. А поэтому мы решили ещё немножко поработать над промтом и вывели для себя правила, которые мы используем для описания Open P. Что в каждом запросе мы должны описывать один метод. Если больше, искусственный интеллект начинает в них уже путаться, спотыкаться и генерирует что-то несуразное. Плюс ко всему сами методы тоже не должны быть большими. А примерно 30 полей - это в самый раз. Если больше, то нужно дробить уже на подзапросы с использованием разных форматов описания, чтобы эту всю историю нам декомпозировать. И опять же искусственный интеллект не начал добавлять уже от себя. А, и, конечно же, самый важный пункт, обязательный - это проверка результатов с помощью нашего Swagдитора, который мы вот видели там пару слайдов назад. А без этого никуда. Я очень часто вижу, ну, не очень часто, всегда, а всегда вижу в любых сетках внизу моя любимая строчка мелким шрифтом написана reference only или может содержать ошибки, требует проверки. Поэтому любой искусственный интеллект необходимо проверять ручным способом, но он вам даёт очень, а, большую базу, которую можно там потратить 5 минут на на то, чтобы это всё перечесать. И в итоге у вас получается очень валидный и качественный результат.
Поэтому раньше у нас Вагер выглядел достаточно скудно. Там какие-нибудь ордерсы с параметрами. Максимум из из приятного был только Яна. А после этого у нас уже и форматы появились, и примеры минимальные, максимальное значение, если они есть. И внизу даже пример, пример одного из наших ордеров, которые потенциально можно получить при реализации этого метода. Плюс человеческое описание полей. Разработчики наши не хотели добавлять код человекочитаемое писание, поэтому их и не было. А по сути в Свагере было бы приятно эту всю информацию увидеть буквально на одной странице.
А, всё супер. Мы с вами поговорили про документацию в текстовом описании, в документацию в формате Open P. А, поняли плюсы, минусы каждого подхода. Но как к этому подходу вообще прийти и какие сложности мы с командой преодолели? На самом деле, а, были сложности не столько там технического характера, сколько там элементарного человеческого фактора. и требовалось их так очень грамотно и тихонько обрабатывать. Например, самый первый, про который хочется сказать, это вообще сопротивление изменениям, а, и необходимость обучаться. То есть, особенно аналитиков, которые в формате Open P там мало чего понимали, это новая спецификация, её надо учить. Там куча разных куча разного синтаксиса. Тем более это уже такое, а, описание в виде кода, когда аналитики тоже, ну, конкретно в нашем проекте не очень хотели лезть. А они привыкли работать в документации, а зачем что-то менять? Ну как бы проблема есть, да? Ну как бы мы с ними живём, всё нормально уже, уже привыкли к этой боли. То есть они наша команда, она привыкла к к текущему формату и было очень сложно, а именно защитить новый э подход к работе. Но у нас это получилось, и аналитики в итоге, а, перешли к этому описанию. Разработчики тоже этот процесс отточили, и тестировщики поняли, что вообще а им теперь доступно, какую функцию они могут брать на себя с помощью генерации своих автотестов. И вот человеческий фактор мы преодолели.
А после вообще сопротивления изменениям нужно было глобально пересмотреть наш образ мышления, нашу парадигму, в которой мы работали. Если раньше для нас спецификация была вот чем-то таким средним, мы вот топили за код, мы вот реализация, спецификацию можно по ходу поменять. Из-за этого мы не могли пускать, допустим, параллельную разработку, потому что на беке что-то поменялось или на фронте, и, соответственно, у нас уже ничего не работает. А после того, как мы стали описывать в формате Open App, мы вообще произошёл такой сдвиг парадигмы в сторону IP First. После того, как мы внедрили IP First, у нас невозможна была смена контракта по ходу разработки, потому что, опять же, разработчиков мы подключали раньше ещё до написания кода и проходили валидацию с ними. Поэтому тут нужно было держать дисциплину того, что а доработки уже после переходе перехода задачи в реализацию они уже недопустимы. То есть тут нужно было, а, больше времени тратить именно на тщательном проектирование, нежели на написании кода. А при этом тут тоже один из минусов у нас пошло замедление на старте работ. То есть, да, мы очень много раз параллели, то есть беки, фронты у нас могут писать параллельно, автотесты пишутся параллельно. При этом мы стали больше времени тратить на этапе проектирования, чтобы более тщательно это дело всё описать, потом согласовать. при согласовании могут ещё вылезти всякие ошибки, корректировки, их тоже нужно было вносить, поэтому вот на старте, да, а стало медленнее, но глобально мы во времени мы выигрываем.
А, и третий наш плюс - это генератор иногда делал нечистый код. Ну, точно так же, как и генераторы, не не делали нечистый свагер. Поэтому разработчикам требовалось вносить изменения согласно стилю, согласно структуре, которая в проекте уже прижилась. Иногда это было необходимо при доработке, а плюс при обновлении нашей спецификации она может сломать существующие существующий код. Так что нам требовалось тут очень осторожно вносить изменения и разработчикам очень осторожно использовать генераторы готовые. Поэтому здесь очень важно было всю эту историю а погрузить. И иногда даже легче было вручную реализовать метод, как это, в принципе, у нас было изначально, а нежели пользоваться генераторами. То есть эта история у нас а ушла на откуп разработчикам. Некоторые пользуются, некоторые предпочитают всё-таки самостоятельно писать код.
И а на этом мой доклад потихонечку близится к концу. И вот какой основной вывод после всего вышесказанного хочется сделать. На самом деле главная сложность у нас была не техническая, а именно культурная. То есть у нас очевиден есть успех после внедрения Open AP и переходу к Апифсту, но очень много зависит от команды, от коллег и тех людей, с которыми вы работаете. готовы ли они к изменениям, как они к этому относятся, поддержат ли они вас. Поэтому здесь нужно заручиться помощью от ваших же вашей же команды, потому что технические проблемы, они там опять же решаются выбором правильных инструментов, правильных технологий и настройкой процессов. А вот как с этими процессами работают люди, тут уже всё зависит от нас с вами, от инициаторов. Поэтому тут нужно к этому подходить с большей осторожностью. На этом готова ответить на вопросы, если они возникли, и можем с вами пообщаться, да, даже голосом.
>> Угу. Спасибо большое за выступление. Слушай, а подскажи, пожалуйста, я правильно понимаю, вот просто в моей парадигме мира нормальная история - это когда мы заставляем разработчика описывать полностью весь код полностью вот весь наш свагер, красивенько каждое поле описывать. Вот. А потом аналитик приходит, смотрит, что в Свагере чего-то нет, и мы начинаем рассказывать разработчику, какой он плохой, и надо всё это сделать. А в парадигме, которую ты сейчас описала, делается наоборот. Вы полностью генерите свагер, вы полностью генерите jonхему, передаёте эту jon схему разраву, соответственно, генерите контроллеры там, я не знаю, на своей стороне, и
>> всё описание уже присутствует.
>> А, да, а давай начну с самого начала. У нас сложно прийти к разработчику и сказать: "Пиши в своём коде то, что мне нужно". Ну, то есть разработчики не хотели, допустим, писать примеры заполнение полей, а минимальные значения. Они не хотели добавлять бизнесовый текст в свой код. То есть они считали, что это бизнесовая часть, а техническая. В техническом реализации в кодего быть не должно. В целом я их понимаю. Это их зоны ответственности, как что должно быть находиться в самом коде. Поэтому прямо так прийти и сказать, что мне это нужно, ничего не знаю, я я не могла. Поэтому за счёт того, что это их зона ответственности, они имели тут власть над нами, над аналитиками. И мы стали думать на тему, что что же в итоге с этим делать. И решили решили, что от описания, да, документации мы уйдём и перейдём вот в формате Open P. Поэтому мы им приносим, по сути, уже готовый свагера, они пишут внутреннюю реализацию. Очень забавная история получается, что аналитики, получается, рассказывают разработчикам, как делать базу данных, как составлять контракты. И тут ещё мы больше в сторону лени разработчиков уходим и полностью всё рассказываем, как делать разработчику.
>> А, ну опять же не не без не без их валидации, то есть у нас раз процесс где
>> он
>> Да-да. Мы просто как будто бы ещё сильнее жизнь разработчикам облегчаем.
>> Облегча опять же на этапе проектирования, да, чтобы за счёт этого они зато стали раньше погружаться ещё на этапе анализа, на этапе Discoverovery, когда у нас идёт проектирование.
>> Макс кофе,
>> почему они не погружались в документацию? Ну, это всё супер, конечно. Я очень счастлива, что такой метод появился. Но почему они не погружались в документацию, если бы мы не использовали свагер, допустим? Ну то есть обычно же происходит, как аналитик пишет документацию, а разработчик её читает, валюдирует, смотрят, они вместе что-то поправляют, и дальше разработчик на основе этой документации делает, пишет код. Как бы в нормальном мире в моей парадигме, по крайней мере, было так.
>> Угу. Ну, тут на самом деле
>> Давайте,
>> а сейчас получается у вас какие-то требования зафиксированы, когда вы, ну, аналитик написал спецификацию в свагере, и получается, вы должны с разработчиком её согласовать, то есть какой-то дор провести, где-то зафиксировать, что вы вот вместе договорились вот так сделать, чтобы как бы вся эта ответственность не ложилась только на твои плечи, но как бы вы уже точно знали, что вы с разработчиком это вместе придумали и и согласны с этим решением.
>> Да, насчёт погружения ещё на этапе описания в документации. А я не знаю, возможно, конкретно у наших разработчиков какой-то триггер есть на документацию. Они её так немножко сторонятся. А, конечно, да, мы читаем, мы смотрим вместе поляну. Когда ты уже начинаешь писать код, у тебя всплывают какие-то подводные камни, ты начинаешь смотреть на код уже в окружении другого кода, и тебе кажется, что то, что было в документации, оно не всегда подходит именно с точки зрения внутренней реализации. Поэтому иногда приходилось на ходу там что-то менять и дорабатывать. А так как у нас не было вот этого жёсткой фиксации спецификации, это можно было делать. А, и иногда мы теряли время на актуализации. А когда мы перешли на проектирование через спецификацию, мы это делаем напрямую в гите. То есть прямо как разработчики делаем пулревесты и вся вот эта история. А, проектируем, пишем новый свагер новый Open AP, отправляем разработчикам на ревью. Они там ставят опровы, мы вместе смотрим, пишут комментарии, и мы это всё вливаем уже в основную ветку. И вот тут, да, есть вот эта жёстко зафиксированная договорённость, что вот эти изменения согласовали разработчик 1 2 3. То есть вот за счёт этого, а, то, что мы перешли в их среду, то есть мы пишем прямо в гите спецификацию вот эту, и она уже лежит в основе генерации, а разработчикам стало даже проще эту спецификацию валидировать.
>> Ну, то есть они стали включённее в работу, чем с документацией текстовой.
>> Да, да, да.
Спасибо. Хорошо, спасибо. Супер. У нас вот вторая рука есть. Кто кто-нибудь? Вот.
Давайте я попробую.
А такой вопрос. Описывалось то, что используется искусственный интеллект. На основе какой используется использовался искусственный интеллект и почему он допускал так много ошибок? Мне вот это непонятно, на самом деле.
Угу. У нас внутреннее корпоративное решение, насколько я знаю, оно всё всё равно под капотом лежит, насколько я помню, псик. И после того, что мы скормили ему огромное количество спецификаций, мне кажется, что ошибка была связана с тем, с объёмом. То есть мы у нас на самом деле около, ну, условно говоря, там примерно 10 микросервисов. В каждом микросервисе у нас примерно по 30, по 40 методов. Ну и, соответственно, просто глаза разбегались у искусственного интеллекта. И очень сложно было прямо openпи сгенерировать вот на основе вот такого огромного объёма. Поэтому мы это всё дело сократили, чтобы получить как можно меньше ошибок при генерации.
Спасибо большое.
Угу. Кирилл у нас следующий с рукой.
Да. Привет. Меня интересует вопрос, в частности, а как вы решали ситуации, когда у вас контракты менялись? Это же, ну, из-за того, что у вас генерируется код по основе спецификации. При изменении спецификации нужно перегенерировать код плюс менять контракты взаимодействие кода с полученными новыми данными. Вот как вы выходили из этих ситуаций?
А, стандартная доработка. То есть, если менялся контракт, у нас запускался весь процесс сначала, начиная с аналитиков. Мы меняли спецификацию за, параллельно запускали разработчиков БЕКа, чтобы они эту спецификацию подправили, всех наших коллег, которые пользовались нашей интеграцией. Ну, то есть тут с этой части, если меняется контракт, у нас процесс ну не поменялся. Или я не так поняла вопрос? Можете, если что, с направить меня в нужное русло.
Дада. Да, всё верно. Просто конкретно в этой ситуации у меня ещё вопрос возникает тогда. Вы говорили, что вы решили тем самым через работу с контрактами, через работу с генерацией кат вперёд кода на проблему параллельной разработки, но при изменении контрактов как будто бы параллельная разработка всё равно останавливается, потому что эти контракты могут задействовать, например, ну, не другие команды, другие сервисы. сервисы под началами других команд. Вот как получается параллельная разработка существовала в этом контексте?
А у нас могли могли поменяться контракты, когда, ну, с течением времени, когда уже методы существуют и вдруг там надо какие-то дополнительные параметры ввести, тогда да. А вообще прямо во время разработки у нас ну, как правило, контракты уже не меняются. То есть сначала, да, когда мы только-только этот процесс запускали и команда вообще щупала, ознакомилась с новым процессом, мы всё равно с точки зрения разработки параллельно не пускали. Но когда поняли, что у нас, ну, практически перестали возвращаться задачи на доработку с изменением контракта, а мы вот рискнули и стали запускать фронты и беки параллельно, ну, и в целом все интеграционные сервисы. И здесь это нам помогло, то есть не сразу, постепенно, когда команда уже познакомилась с технологией. И да, у нас просто вот на этапе проектирования спецификации перестали быть вот эти нюансы со сменой контракта.
Понял. Спасибо большое за
Угу. Да, Павел у нас следующий с рукой.
Всем привет. Я Павел. А хотел уточнить по поводу момента с автогенерацией. Это, наверное, то, что меня больше всего беспокоит в этом рассказе. Не очень понимаю, каким образом должна происходить валидация результатов регенерации. В частности, был были упомянуты автоматически сгенерированные автотесты, автоматически сгенерированная спецификация. Также я услышал, что после того, как она генерируется, она передаётся разработчикам, которые дают опру. Но, как мне кажется, тут возникает проблема. Допустим, аналитик сформулировал спецификацию через нейронку посмотрел и думает: "Ну, вроде норм". Передаёт разработчикам видимо уже нескольким. Тут происходит разделение ответственности. Каждый из них посмотрел и сказал: "Ну, я ж уже не первый, да и вроде норм". И всё это копится. А получается, что подобные процессы требуют вынедрения каких-то дополнительных процессов. валидации и верификации результата, которые,
возможно, будут занимать и больше времени, и не очень понятно, как их вообще проводить.
Хорошо, вы решили какие-то проблемы.
А, начиная с самого начала, когда у нас идёт генерация open А вот правило подхода, которое мы используем. И тут есть пункт, он третий, ну, почему-то нумерация вторая, но ничего страшного. А у нас после того, как искусственный интеллект сгенерировал Open Pпецификацию, аналитик идёт и проверяет её через Swager Editor. Смотрит, что, во-первых, синтаксис у нас вообще корректный, и это соответствует тем требованиям, которые были изначально поставлены а перед задачей. То есть тут раз проверка. То есть, если раньше мы тратили, мы замеряли время, которое вот аналитики конкретно тратят на описание, а мы бы вручную описывали методы минут, ну, опять же, зависит от метода, но в среднем там, ну, 40-50. А мы сидим прямо в в Open AP спецификации, каждый параметр прописываем, проверяем, с синтаксисом, сравниваем и так далее. А то сейчас у нас это всё генерируется автоматом за минуту. А минут 10 мы тратим на проверку. И на этом всё. То есть это время сократило. Мы не опять же не берём работу искусственного интеллекта в том виде, который он нам даёт. Он всегда требует проверки. И ни разу, по-моему, не было, чтобы аналитик мог действительно результаты работы ишки с первого раза принять и отправить в разработку. То есть это было редко. Потом, когда отправляется эта вся спецификация на ревью разработчикам, а уже у разработки же есть как это культура ревью, ну, есть кодревью, поэтому не было такого, что они увидели, что там один человек опру поставил, а я тоже тогда поставлю. А, то есть у нас во разработчиков всего восемь, а на фронте и три на беке. А на БКЕ нужно минимум от двух человек, на фронте минимум от трёх. То есть у нас нет такого, что ты должен обязательно поставить, и это появилось и это превратилось в какую-то формальность. У человека есть время, он берёт, смотрит и ставит аprв. Поэтому это не обязаловка. Это вот опять же ну есть определённый KPI, что у нас в ревью не должно висеть там больше суток, по-моему, задач. Поэтому эта вся история, она валидируется именно достаточно достаточно корректно. А потом про генерацию кода, генерация автотестов. Ну, то же самое. Я, конечно, ну, сильно в работу коллег не погружалась, но догадываюсь, что они используют, в принципе, такую же технологию, как и аналитики. То есть, да, у нас генерируется автотесты, генерируется код, но это требует всегда ручной проверки. Плюс ко всему разработчики в какой-то момент, я вот слышала от коллег, некоторые вообще отказались от генерации, потому что а сложно настроить генерацию так, чтобы она реализовала только тот метод, который тебе нужен, а не взяла и попортила всё то, что ты уже написал раньше. Поэтому большинство разработчиков, допустим, генераторами вообще не пользуются. Ну только если прямо с нуля надо метод реализовать, там действительно нету ничего, а что ломать, тогда да. А если уж доработка уже существующего метода, то это, как правило, всегда ручные изменения.
То есть, если кратко, вы собрали под это дело отдельный пол валидации результатов.
А, да, внедрили на каждом этапе.
И по итогу получилось, что даже с учётом об валидации это выигрывает время. Верно?
Да.
Угу. Понял. Спасибо. за счёт того, что мы рыбу получаем быстрее нашу основу и за счёт того, что разработка на каком-то этапе мы уже пустили параллельно.
Я тут, кстати, осознал, что этот метод частично помогает в решении проблемы против таких плохих разработчиков, как я. Вот я я могу, например, аа посмотреть на документацию, которую мне прислал аналитик. Вот отложить её в сторонку, вот потратив на чтение документации секунд 15 и написать всё по-своему, а потом прийти к аналитику и сказать: "Смотри, тут я написал так, у тебя неправильно, перепиши". А здесь теперь наоборот и аналитик всегда обязан спустить контракт, который мы обязаны у себя применить. То есть частично решает. Конечно, всё равно разработчик может потом в любой момент переделать, но как будто бы здесь уже есть чёткий, более чёткий процесс.
Ну, на самом деле, да, на любом этапе, с любым процессом, можно сказать: "Я всё переделаю, как как сам захочу". Но да, это определённой формальности добавило с вот этими опровами, с того, что мы перешли в вашу среду разработки. А, и да, с этой точки зрения нам это помогло.
О'кей, Миш,
здравствуйте,
здравствуйте. Здравствуйте. Я не сразу присоединился, хотел спросить, а документация у вас в гите лежит, я правильно понял?
А с Oppen PWA, да?
А генерация происходит автоматически или же её делают сами аналитики? Пишут,
аген Openпи пишут аналитики с разработчиками, с ревью разработчиками.
А вы используете снипеты при работе? Я это слово не слышала, судя по всему, не это когда вот, ну, автотестеры делают часто, там какой респонс, реквест идёт и тем самым в Git можно вставить вот эти респонсы сразу, то есть уже готовые, потому что, ну, так или иначе не написано разработчиками при для автотеста документацию это может вставиться. А вот про это говорить, то что в вот у нас в конце схемы есть, ну, пример режиссонов там какой ответст там кур какой ушёл, какой респонс пришёл, вот их прямо подставляете. Ну то есть можно ручками выставлять, но аналитик может ошибиться. И поэтому иногда делают подход, когда вот этот снипет автоматически.
Сами курлы нет, тут скорее вот по схеме примеры. Ну, которые можно, наверное, переиспользовать в автотестах.
Не совсем тогда понятно получается, что если аналитик пишет сам документацию, то и хранится этотгиit, то в чём тогда роль ID и а написание этой самой спецификации в формате Open AP. Мы её пишем каждый раз не руками, но опять же тут очень всё зависит от изменений. Если там один параметр добавить, конечно, тебе легче это сделать руками. Если нужно реализовать новый метод, то тебе легче его описать в своём привычном формате в документации, а закинуть это всё в иишку, тебе быстренько эта спецификация вернётся уже в стандартизированном формате, и ты внесёшь только изменения, которые вот искусственный интеллект не заметил. Вот здесь идёт генерация. А у вас не было так, что и каждый раз меняет формат подачи? То есть то он одном формате, ну, грубо говоря, там входящие параметры in, двое точи, там исходящие а, а в другом случае напишут там исходящие, ну, совершенно разные стилистика использова. То есть как вы добиваетесь, чтобы вот единообразие было?
А единообразие мы сразу задаём, что формат у нас Ямо, но чтобы он же не использовал.Но Понятно, да?
А по поводу формата именно там входныхвыходных параметров, Open P он уже стандартизированный, там есть определённые правила написания, то есть там нельзя использовать разные имена для входныхвыходных параметров.
Не, вот как раз вот в Ямле тоже можно по-разному там писать заголовки, там вставляется тамс, ответ, все именования. То есть и может оказаться так, что один и тот же ИИ генерирует здесь так, а там немного по-другому стиль, в третьем по-другому, то есть и как-то жёстко задать стилистику вот этого ямого файла. То есть это так, ну разве может не человек как-то
Максим размьютился,
да? На самом деле может спокойно вот потому что я тоже делал эту задачу. Вот делал сейчас GPT. У меня другой промт был. Вот. Но спокойно, в общем-то, перекрывает эту задачу, генерит одинаково. Главное сдать чёткий системной пром и и сказать ему: "Ты должен отдать мне в таком респонсе и ни в каком другом".
Угу. Иногда мы отправляем ещё примеры. Ну, то есть тут этого нет. Это потому что я показывала этот промт в контексте создания документации с нуля. Но а когда мы дорабатываем какой-то метод, мы ему даём базовый, который нужно сделать.
И, кстати, я, насколько я понял, у вас ещё
по аналогии, то есть какой-то шаблон и по аналогии вот сделать так. Так вот,
дада,
Макс.
Да, и насколько я понял, у вас своё решение вот на базе дипсика, то есть вы всегда используете одну лмку. Это первый момент. Второй момент, скорее всего, у вас RG, то есть у вас своя база данных, условно говоря, а, на основе которой вы работаете. Вот и поэтому шанс по сути отхода вправо и влево и генерирование там заново, ну, то есть постоянно новых форматов, он сильно снижается, потому что у вас Лэмка знает, с чем она уже работает и что от неё ожидается.
Ну, контекст она запоминает, да, они же,
да, самообучаемые, да, супер. Пока рук нет. Есть один вопрос в чате. А от Олего, где хранится Open IP схема и как доставляется до потребителей?
А, ну вот, кстати, да, ответили, что это хранится у нас в GTтей и доставляется соответствующим образом автоматизация по передаче схемы. А, ну вот, соответственно, через Git или можно зайти напрямую в Swager и вот через headсы, как мы это делали выше, вот тут вот здесь вот вот вот таким образом можно её получить внешним внешним коллегам. Соответственно, эту часть подставляешь и вот тебе то же самое openпи.
Михаил, а вы храните план и какие-то там плагины для отображения, ну, этих диаграмм, sequ что-то прямо вот.
А саму реализацию внутреннюю, да, очень глуховато, но я услышала слово sequнса, поэтому, думаю, поняла вопрос. А саму внутреннюю реализацию у нас всё-таки осталась в документации, потому что, ну, свагер не подразумевает описание подобной информации, поэтому свагер у нас для описания входных входных параметров и какого-то описания самих программных интерфейсов с точки зрения внешнего пользователя, а вся внутренняя кухня, тут без документации мы пока не ушли. Сиквенсы делаем в планте.
Макс, может быть, ты не поправишь, но, по-моему, генерация через, ну, с Вайбером всегда существовала автоматизированный. А чем сейчас это отличается процесс с использованием там модного слова и и без его использова генератор сильно, потому что до этого это делал, условно говоря, у нас есть, у нас есть спецификация там open вторая, третья, и до этого всегда это было, условно говоря, автоматически, но со стороны разработчика, то есть разработчик диктует правила. А здесь аналитик диктует правила. И в качестве генерации непосредственно решения, э, аналитику надо использовать и вместо автоматизированных ээ инструментов, потому что автоматизированные инструменты может использовать только разработчик, потому что на стороне разработки существует библиотека, а на стороне аналитики это действительно нужно делать и чисто через и вот. То есть по сути процесс подачи меняется. Теперь аналитика больше диктует разработчику, если я правильно понял вообще всю историю.
А если разработчик сделает по-другому, чем отличается в аналитике?
Ну тут мы всегда можем отходить, конечно, и такой разработчик, как я, я всегда буду, например, отходить. Вот поэтому я я плох. И все остальные могут делать по-другому. Но мы как-то пытаемся формализировать таким образом процесс, чтобы меньше шагов делать вправо и влево. Спасибо. Понятно.
Угу. Так-с. Ребята, есть ли какие-то вообще ещё вопросы? Если нет, 3 21 продано, тогда заканчиваю непосредственно