Speaker A
Друзья, привет. Это подкаст Организованное программирование. Я ведущий Кирилл Макевнин. У меня сегодня в гостях Иван Поддубный. Ваня, привет.
Опыт внедрения Spec-Driven Development в компании с 150 разработчиками: системный подход, workflow и практические вызовы.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- SDD объединяет процессы аналитики, разработки и тестирования в единую систему.
- Итеративный подход к внедрению позволяет постоянно улучшать процесс разработки.
- Workflow-фреймворк критически важен для регламентации и масштабирования SDD.
- SDD помогает адаптировать классическую водопадную модель к современным гибким требованиям.
- Полный адопшен SDD в крупной компании возможен и приносит значительные улучшения.
What the video covers
- Иван Поддубный, CTO компании Webпрактик, рассказывает о внедрении SDD в крупной IT-компании.
- SDD рассматривается как единая шина контекста для объединения аналитиков, разработчиков и тестировщиков.
- Процесс внедрения SDD был итеративным и направлен на системность и масштабируемость.
- Использование SDD позволило стандартизировать работу со спецификациями на всех этапах разработки.
- В компании был достигнут 100% адопшен SDD среди разработчиков к концу года.
- SDD помогает преодолевать проблемы классической водопадной модели, адаптируя её к гибким реалиям.
- Важным элементом является workflow-фреймворк, который регламентирует роли и действия участников процесса.
- Практические кейсы показывают, как SDD улучшает коммуникацию и контроль качества в больших командах.
- Обсуждаются сложности параллельной работы аналитиков и разработчиков при изменении требований.
- SDD рассматривается как фундаментальный инструмент, сравнимый с популярными фреймворками разработки.
Chapters
- 00:00Введение и знакомство с Иваном Поддубным
- 05:08Причины и предпосылки внедрения SDD
- 10:58Преимущества и системность SDD в компании
- 17:23Практические кейсы и проблемы внедрения
- 23:46Роль workflow и регламентация процессов
- 31:10Преодоление проблем классического водопада
- 37:11Опыт масштабирования и адаптации SDD
- 42:30Заключение и перспективы развития
Full Transcript — Download SRT & Markdown
Speaker A
Привет. Ваня — CTO в компании Webпрактик. Это интегратор, примерно 150 человек компания. И, соответственно, так получилось, что за последнее время на большом количестве конференций, которые проходили там в Москве, в Питере, Ваня приезжал, выступал и рассказывал про то, как они внедрили SDD, Spec Driven Development в свою компанию.
Speaker A
И мне после того, как я это посмотрел, Ваня там пользовался популярностью, во всех кулуарах говорили: "Смотрите, какой классный доклад у Вани, вообще класс".
Speaker A
Мне очень захотелось сделать этот подкаст, поговорить, потому что в основном говорят про теоретическую какую-то имплементацию, да? А на практике кейсов мало. То есть что-то, какие-то кусочки где-то появляются, у тебя есть законченный кейс от начала до конца. И сегодня у нас будет не
Speaker A
теоретизация на тему того, что такое SDD и как мы будем жить в будущем. Мы поговорим про то, как вот вы, наверное, одни из пионеров, как минимум в русскоязычном мире, кто это сделал.
Speaker A
[музыка] Соответственно, у меня первый прямо к тебе вопрос. Как вы вообще пришли к идее, нам нужно внедрить SDD?
Speaker A
Да, я немножко чуть-чуть, буквально скажу, поправлю слово "закончены". Мне кажется, слово "закончить этот процесс" нельзя. Он итеративный, постоянно улучшающийся, особенно в нашем изменчивом мире. По поводу того, как мы пришли к SDD, мы одни из тех, кто довольно-таки рано заадоптился и
Speaker A
условно, то есть, а, одно из наших некоторых достижений, то, что мы к концу прошлого года у нас был там стопроцентный адопшен среди всех разработчиков уже. И именно уже, когда к концу, когда мы подходили к тому, что уже мы отмасштабировались, уже там, не
Speaker A
знаю, когда там декабрь примерно, начали возникать мысли: "А, собственно, а что дальше? А как делать
Speaker A
процесс более системным, как его отстраивать и как его отстраивать, масштабировать не только на разработчиков, а на весь процесс разработки, в принципе. Может, с двух сторон, да, подошло и со стороны необходимости системности, и со стороны необходимости масштабирования процесса,
Speaker A
чтобы он был единый для аналитиков, для разработчиков, для тестировщиков. И здесь как раз SDD для нас выступила некоторой шиной, которая должна была объединять эти процессы. Тут ещё вот была такая история, что мы в начале года, двадцать шестого, как раз собрались
Speaker A
всеми руководителями на тросею очередную ежегодную. И вот там руководители профессии всех собрались, там бэкэндеров, фронтендеров, аналитиков, девопсов. И всем была поставлена такая задача, типа, говорит, вот следующий шаг, он какой? Как вы видите? Вот постройте себе вот архитектурную схему
Speaker A
агентов вашего, как вы видите вот именно ваше развитие в отделе для того, чтобы в том числе повышать автономность вашей работы. Вот один из тезисов — это вот куда мы стремились. Мы уже тогда начали думать, как нам потихонечку
Speaker A
подбираться к увеличению автономного времени. Прошла эта стратегическая сессия, и все пришли со своими схемами.
Speaker A
Но вот такая классическая, ну, не классическая, у многих такая ошибка была. Собственно, мы её вот, получается, отловили на самом, так сказать, начале.
Speaker A
Некоторые в этой ошибке пошли дальше. Все пришли, принесли, и у всех свои источники контекста, свой способ их сохранения, там свои какие-то агенты. И вот мы просто посмотрели на вот эти там условно пять презентаций, как краткие, да, со схемами, и мы понимаем, что, ну,
Speaker A
эта штука, ну, она вообще никак не состыкуется для того, чтобы выстроить этот сквозной процесс. Ну и вот, то есть как бы это вот такая вот одна из таких основных причин, да, тоже в том числе, чтобы мы действительно сделали,
Speaker A
объединили этот процесс, нам нужна вот эта единая общая шина контекста, которая нас будет объединять. Вот. Ну и тут уже понятно, что нам действительно вот нужно этот SDD workflow, какой-то движок, фреймворк готовый, который бы нам это позволил. Ну то есть мы сразу начали уже
Speaker A
смотреть, какие есть готовые инструменты для этого, изучать, сравнивать их. Точнее, мы их начали чуть раньше сравнивать, но вот тогда уже стало понятно, что прямо без этого нам никуда.
Speaker A
Просто потому что без единого способа работы со всем контекстом, чтобы каждый работал вот с единой этой шиной, мы двинуться дальше не можем, наверное.
Speaker A
[фыркает] Вот как мы пришли к SDD — это ответ на этот вопрос. Тогда чуть-чуть расширю, потому что какие-то должны быть предпосылки ещё с точки зрения того, что болело, то есть мы начали пользоваться, то есть вы начали пользоваться агентами и поняли,
Speaker A
что какой-то разнобой идёт или у вас были спеки, но с этим были какие-то проблемы? То есть вот почему именно SDD?
Speaker A
Почему ты сказал, например, скрам, да? То есть ты же мог так же сказать, да?
Speaker A
Да, не мог. Не, ну в смысле SDD для меня это давай как я его воспринимаю. Для меня это способ работы с спеками и контекстом, который у вас есть на всём проекте. То есть, наверное, давай
Speaker A
так, спеками я называю артефакт, который нам идёт на всём протяжении жизни, да? То есть это требование, которое мы должны выражать в спецификации, которые мы должны спроектировать, имплементировать, протестировать, да, условно. И для меня SDD — это как раз тот
Speaker A
инструмент, который это делал, да. У нас были вот как раз там в прошлом году какие-то попытки, да, то есть там локально в виде файликов кто-то пробовал сохранять там разными там super power с какими-то артефактами генерировали, то есть реально пробовали различные
Speaker A
подходы, но это было всё не системно. То есть вот нам нужен был какой-то фреймворк, который бы позволил и регламентировал, требовал, как нужно на каждом этапе, условно, какие скилы каждый участник этого там линейного процесса должен запускать для
Speaker A
того, чтобы вот у нас фича от проектирования до тестирования как минимум проходила. То есть вот как минимум через три амига проходила. Там вопрос деплоя. Мы немножечко там за скобки выносили, он нас не так беспокоил. Такая не какая-то больная для
Speaker A
нас именно конкретно в нашей компании вещь, да? То есть, ну, там просто один скилл сделали там для того, чтобы это всё задеплоилось или выливалось и циклично перепроверяло себя. Это как бы у нас не на этом не было фокуса.
Speaker A
Ценой фокус — это вот у нас классически три амига — это аналитика, разработка, тестирование. И вот, собственно, нам нужен был как бы системный подход.
Speaker A
То есть мы от SDD фреймворка взяли не только то, как мы пишем спеки, мы и взяли ещё и workflow, да? То есть для нас это как движок workflow — это как фреймворк, мы к нему относимся. Вот примерно, я не знаю, как Symphony, Laravel, какой-нибудь Java Spring, React для нас это вот что-то на какой-то фундаментальной штуке, на которой мы уже всё остальное строим.
Speaker A
Кстати, можно было сразу добавить слово водопад. Вот да, блин. Ну действительно, мы приходим к классическому этому водопаду, точнее, мы пытаемся к нему прийти, но иногда спотыкаемся вот о гибкие реалии мира. Что вот одни из проблем, которые мы решаем вот в процессе. Вот я из
Speaker A
отпуска вышел как раз вот на этой неделе и разбирал, какие проблемы были с SDD за последние пару недель. И вот там на одном из проектов, э, как это в классическом мире бывает, что бывает нужно быстро что-то сделать, а
Speaker A
требования не успевают за разработку. То есть у тебя в итоге сроки приближаются, аналитика полностью не проработана, но уже надо начинать, иначе не пойдёшь. И здесь вот как бы в эту классическую схему водопада ты немножко упираешься и такие так
Speaker A
разработчики пойдут параллельно уже работать, и они такие начинают уже вносить изменения в эту спеку вместе параллельно с аналитиками. И здесь они друг другу мешают, толкаются немножко локтями в этом плане, когда ещё не до конца требования проработаны, а их уже
Speaker A
частично делают, они меняются по ходу дела ещё. То есть даже на уровне черновика подключились ребята. И вот такие случаи ломают нашу классическую водопадную схему. Хотя вот по факту SDD — это идеальный водопад, да, к которому мы вернулись, который
Speaker A
переосмыслен после.
Speaker A
переосмыслен после прихода мишки. [музыка] Последний вопрос. перед тем, как нырять прямо внутрь уже и поговорить о том, что там у тебя происходит, какие вы метрики ставили. То есть это же не просто там, о, давайте внедрим. То есть были же
Speaker A
конкретные проблемные зоны, которые хотелось победить, и, наверное, вы как-то их оценили, что что-то должно произойти ускорение разработки не знаю, что-то ещё может быть.
Speaker A
Ну, конечно же, ускорение разработки, да, то есть мы понимали, да, то есть что наши пилоты ещё там в прошлом году показали, да, условно, на уровне компонента, на уровне модуля ты можешь сильно ускориться. А, но как теперь этот результат сделать системным, да? То
Speaker A
есть, чтобы он был воспроизводим всеми участниками процесса, отмасштабирован на все проекты, на все процессы. И, соответственно, это была не какая-то там выброс какой-то просто, где у кого-то что-то получилось, как это, чтобы работало на потоке и стабильно. Вот. И,
Speaker A
ну, то есть основная цель, которую мы ставили, действительно себе ставили - это ускорить разработку.
Speaker A
Прямо цифра была какая-то с точки зрения цели. Вот там мы хотим ускориться пять раз. Нет, мы так не ставили. Мы, то есть, понимали, что рост во многих задачах будет кратный, и он подтвердился, да? То есть потом мы, когда мы в мае сделали замер, вот,
Speaker A
знаешь, вот мы чуть-чуть в сторону отойду, я участвовал в двух круглых столах, как измерять эффективность разработки после происшествия AI. И на самом деле, то есть это сложный вопрос, потому что мы не не научились измерять эффективность разработки ещё до AI
Speaker A
хорошо и качественно, да? То есть там все способы, они немножко лгут, могут лгать, скажем так, особенно если там начинать э делать прессировку на пользу для бизнеса, насколько это эффективно там приносит всё остальное. Там всё ещё сильно сложнее становится. И вот один из
Speaker A
способов, который для меня м я считаю, один из простых и валидных - это оценка поо бейзлайно. То есть когда у вас есть оценка стартовая там типовых задач до и оценка после, сколько выполняете. И так получилось, что действительно у нас в
Speaker A
компании этот бейлайн, он был задолго до аишки. То есть у нас был бейлайн оценок фронтэнда, бэкэнда. Это типовые какие-то штуки простые. И логика, что почти все сложные вещи можно разложить до простых, на которые все команды, все разработчики там аналитики
Speaker A
тестировщики должны ориентироваться в плане оценки. То есть, грубо говоря, мы понимаем, что вот такой вот модуль, его можно разложить на такие компоненты.
Speaker A
Такие компоненты примерно столько должны занимать по времени. Вот. Ну, понятно, что там специфика проекта учитывалась когда сложность, но вот это такое некоторое мерило, которое нам позволяло примерно равнять разработчиков команды и задавать рамки, в рамках которых примерно нужно существовать, чтобы не
Speaker A
было, а, кратного м разрыва между там в одной команде за с такими таймингами работает, в другой с такими. И когда мы переоценили этот бейзлайн в мае, мы увидели кратное увеличение по больше чем половине задач. Вот прямо там x3, x4, x5
Speaker A
вот множители, это которые мы получили на выходе. То есть когда мы шли, мы не ставили себе цель, вот мы вся разработка должна быть x5. Нет, мы понимали, что м мы придём к этим множителям, но, соответственно, это нужно измерить,
Speaker A
когда мы там начнём масштабировать немножко процесс. Не только на звёздных ребят, которые и так действительно и так были быстрые, они стали ещё быстрее, но, соответственно, нужно смотреть вот на масштабе. Вот, к примеру, как раз в мае мы эти цифры замерили. Ну и вот реально
Speaker A
больше половины задачи, кратное увеличение. И после мая мы увидели, что ребята действительно укладываются в эти оценки. То есть это не то, что мы их переоценили там с ребятами, в том числе опросили всех и так далее. И мы действительно увидели, что ребята в
Speaker A
новые типы оценок уже начинают вкладываться. Там, на самом деле, ещё дальше рост. Это мы оценили линейный рост, а есть ещё нелинейный рост, потому что, условно, одну задачу ты делаешь там в три раза быстрее, но по факту это ты,
Speaker A
разработчик сейчас не работает над одной линейной задачей, он работает там три-5ть сессий, да, и там ещё есть нелинейное ускорение. Это вот такой вот следующий нарок вглубь, который тоже позволит нас ещё сильнее получать больше профита в плане ускорения.
Speaker A
Знаешь, какой-то интересный момент, когда ты говоришь про разработку фич, речь идёт из про отдал в тестирование или ты говоришь про сквозную выкладку, что вот прямо довели до прода?
Speaker A
Наши оценки они довели до прода. М, то есть у нас оценки все включаются с, э, доведения до прода. Там есть у нас некоторая хитрая схема, что мы, а, день оцениваем не в 8 часах специально, а в пяти для того, чтобы у нас были
Speaker A
некоторые буферы, которые могут покрывать некоторые риски там на коммуникации и всё остальное. А, и благодаря этим буферам, то есть мы у нас оценки м условно в пятичасовом, ну, дне мы считаем, что эти буферы должны гасить все там некоторые шероховатости, которые
Speaker A
могут возникать. Вот. И это позволяет нам точнее попадать в свои оценки, потому что у нас есть и буферы. Как-то так.
Speaker A
С 2013 года я создаю курсы Hexlet. Сейчас мы активно двигаемся в сторону искусственного интеллекта. Агентное программирование, автоматизация и lлоowукодинг, ll программирование. Всё это становится ключевыми направлениями в ближайшем будущем. Если вы хотите повысить собственную продуктивность, внедрить решение на базе и и в работе
Speaker A
или стартовать собственные проекты, то вы попали в правильное место. Посмотреть на конкретные программы обучения можно по ссылке в описании. Хорошо. Ну что, давай переходить к самой сути. Ты уже говорил про Open Speck. Вообще давай поговорим про вот это
Speaker A
направление, что ли, да, что появились прямо целые фреймворки и ты же выбирал. Расскажи чуть-чуть про это.
Speaker A
Мы ресрчили вместе с ребятами, да? То есть, ну, давай так. Там есть четыре основных игрока, которые там можно рассматривать как больше командные инструменты и два, которые не сильно, на мой взгляд, можно воспринимать как командные, да, то есть основные вот так
Speaker A
три эшелона, наверное. Вот первый эшелон - это Open Spec Kit. Второй эшелон - это вот они больше workflow движки, на мой взгляд. Здесь можно, конечно, со мной поспорить. Это BMAT JSD. И третий - это вот про индивидуальную работу. чуть
Speaker A
больше это вот Pocoк или и Superpers Pocк чуть я на самом деле позднее познакомился, в том числе ты на меня его потолкнул, хотя скил грилми я использовал до этого. Я просто не знал, что у него целая пачка этих скилов,
Speaker A
которые он прямо в в некоторую систему даже построил. Вот. И это больше про индивидуальную, на мой взгляд, работу. Я бы вот не воспринимал этот инструмент для как для командной работы. Вот для командной работы как раз сказать, там Enterprise, как классическая. Вот для
Speaker A
меня это в первую очередь всё-таки Openпек Спектит. Я бы сравнивал эти два инструмента. Причём у спекта больше звёзд, он чуть больше раскручен. Он был первым, но не всегда первый самый лучший, даже несмотря на то, что у него больше звёзд. И он, на мой взгляд, здесь
Speaker A
имеет место инерция, да? [фыркает] То есть некоторые, да, когда лидер становится ещё больше лидером, не потому, что он лучше, да, а просто потому, что на него в первую очередь пересаживаются, несмотря на других игроков. Ну там много разных примеров. Не можно там реактор,
Speaker A
редакци какой-нибудь вспомнить, да, когда лидер просто вканеет, да, в своей нише. Вот Open SPC, чем меня подкупил.
Speaker A
Первое гибкость, простота входа. BYU дизайн. Вот by прямо у них файлик идеологии. И они говорят: "Мы изначально про Браунфи проект. Мы вот изначально затачиваем всю свою работу про вот там вот эти вот десятилетние монолиты. Идите все к нам! Это мы про них, мы прямо на
Speaker A
них заточены". СкIT, по мнению многих экспертов, он чуть лучше работает для Greгenfield проектов. Вот проект с нуля, потому что вот там всё чисто выстраивается. Успек кита, он чуть более сложный. У него выше порог входа, у него там нуже там питон ещё там себе
Speaker A
поставить, эти пакеты дополнительные, больше сложности, именно больше количество артефактов. Причём он родился раньше в то время, когда модели были ещё чуть более слабые. И вот нужно нужна была большая жёсткость. Соответственно, Open SPC он вышел чуть позже, и он уже
Speaker A
немножко предвидел, что такая большая жёсткость может быть избыточной. Э, и можно с меньшей жёсткостью, меньшим контролем, меньше времени тратить на количество, вычитку большого количества артефактов, достигать неплохого довольно-таки результата. И, наверное, одна из его там killрфич - это два
Speaker A
состояния. А первое состояние - это то, что вот как обычно вот так вернёмся назад, как обычно велась у нас документация спецификации в конфлюенсе в корпорациях. Два два варианта. Либо мы описывали состояние и постоянно его патчили, либо второй вариант мы там
Speaker A
выпускали ЧТЗшки, и они наслаивались. Вот у нас есть требования на изменение вот этого функционала и так далее. И вот, собственно, она как история в гите, да, условно у тебя были этот и не было источника истины. И очень мало кто
Speaker A
поддерживал сразу два этих источника, потому что, ну, это накладно с точки зрения человеческих ресурсов и ЧТЗ, да, и состояние и смежить белковой нейронкой, да, так скажем. А с приходом Ишки как раз, кажется, это стало не так сложно. И Openпекто взял эту Kкиillр
Speaker A
фичу, на мой взгляд, byдизаign себе, что у тебя есть вот эти вот ченджи, которые, ну, вот если очень там упростим, скажем, что это ЧТЗшка, да, такая частное техническое задание, если не сталкивался с термином. И есть состояние, когда ты
Speaker A
выполнил, да, этот чеange, что он его мержит в main spec, да, то есть в текущее состояние из системы, на которую можно тоже всегда очень быстро положиться и которым агент пользуется. И это удобный, хороший для него источник контекста. То есть у него, у агента
Speaker A
теперь есть вот два две возможности. Во-первых, посмотреть эти чейнджи, что зачем, когда вносилось и состояние спецификации требований. Sis сейчас как вот, э, источник истины.
Speaker A
Вот, наверное, основной набор причин, почему мы выбрали Open SP. Знаешь, я сейчас что подумал? А мы можем это продемонстрировать? Ну, чтобы вот прямо не рассказывать, прямо пошарить экран и показать. Может быть, на прямо на гитхабе, в смысле, не ваш проект, а в
Speaker A
целом, как они там же экзампл какой-то есть. Может, на твоём проекте? Угу. Сейчас подумаю, посмотрю.
Speaker A
Да. Минутку. А ты всё сделал уже? Да. О'кей, начинаем. Давай. Угу. Да, собственно, примерно давайте просто покажу, как это выглядит в проекте. Да.
Speaker A
Вот это небольшой, это внутренний портал во практике, который мы там называем Инер. Он, который там отвечает, а, автоматизирует некоторые наши виды деятельности там и некоторые вещи. Там сотрудники могут зайти, посмотреть, сделать. Планирование какое-то у нас и разные другие штуки. помогает сделать.
Speaker A
Как выглядит папочка Openпека, да? Вот, то есть по умолчанию вот есть эти две папочки Чинжи и спеки. А вот Чинжи - это как раз тот источник документации, про который говорил, это когда у нас каждый чейндж - это папочка с набором
Speaker A
изменений. То есть, грубо говоря, каждая папочка - это такое читэзшка отдельное, которая и про бизнес, и про технологии, и так далее. И есть папочка спеки, которая разбита, ну, на капалити. можно как-то называть где-то называть это доменами какими-то, а, какими-то
Speaker A
группами. Сейчас он, последняя версия позволяет делать двойную вложенность, а где мы там на каждую какую-то функциональность у нас есть смерженная спека, да, которую мы можем посмотреть.
Speaker A
Но давайте вернёмся к ченджам, да, это вот такая основная единица рабочая, с которой, собственно, все работают. И вот там вот, к примеру, фича сейчас мы там делаем каталог продуктов внутри нашего портала. И какие здесь основные артефакты? Три основные артефакты
Speaker A
начинается это с пропоd. А, то есть, когда мы работаем, условно, я в консоли пишу, а, в клоде УПСX Propols и с агентом я проектирую, зачем я это вообще всё делаю. когда я спроектировал его, э-э, обсудил его с ним, э, он фиксирует
Speaker A
как артефакты. И вот самый главный артефакт - это зачем мы это всё делаем, это какие там требования, зачем мы это делаем, что изменится, что не является целями этой работы, что мы собираемся получить. То есть это вот такая бизнесовая штука. А в нашем понимании
Speaker A
это основной артефакт, который должны, а, над которым должны работать аналитики и продукты. Здесь он довольно-таки простой, потому что это опять же проект не разрабатывается командой, на самом деле, там в большей мере там его разрабатываю я и один разработчик
Speaker A
полного цикла. Я здесь как вот выступаю больше как продукт-нженер некоторый такой, а который и и код пилит, и идеи придумывает. И мне помогает один из наших старших тимледов делает какие-то штуки, интересные фичи. Итак, мы сделали пропоз. Пропозл MD он сгенерировался.
Speaker A
Потом на основе него агент генерирует дизайн MD. Это что-то типа адрки. Здесь как раз технические решения, что как происходит, там модель данных, как это, то есть всё должно работать, вплоть до того, там здесь может быть описано, какие компоненты могут быть
Speaker A
использоваться и так далее. Третий важный файлик - это tasks MD. Это конкретный план работы агента. Это очень удобно, особенно когда у вас ограниченный контекст или там можно начать работать на работе, продолжить дома без проблем. То есть не обязательно
Speaker A
хранить это. То есть неважно, чтобы вы там сохраняли какую-то сессию. Вы можете сессию потерять, вы можете начать в одном агенте, закончить в другом агенте.
Speaker A
Весь контекст у вас сохраняется внутри ченджа. И в любой момент вы можете пойти и продолжить начинать какой-то следующий другой пункт делать. Соответственно, вот примерно вот так план этот выглядит. Он его довольно-таки низкоуровня декомпозирует. По ходу работы, когда вы
Speaker A
запускаете выполнить команду выполнения OpenPake, там OpenX Apply команда, а он берёт и начинает заполнять эти пункты. Следующая папочка - это спики. Он их разбивает на капалити. Это по сути вот там функциональность, которой он будет конкретно затронута. И в каждом капалити
Speaker A
он пишет с требования, он их делает в виде герна. Zen классические. Формат требований в таком виде спецификации очень удобно трассировать в тесты. То есть можно генерировать прямо по нему пирамиду тестов, которая должна закрывать каждый из сценарий, который у
Speaker A
нас здесь прописан. Как-то так. Наверное, основа она вот в этом после. То есть у нас, грубо говоря, следующие команды, да? То есть получается у нас вот там главная команда - это прос, где мы сгенеровали change. Следующая команда - это у нас команда apply - это
Speaker A
выполнить. И третья команда - это архив. Что делает команда архив? Она change переносит в пеки. Она, точнее, сам чейндж она переносит в архиве в архив.
Speaker A
Здесь вот они архивируется, но она мержит как раз вот ваше требование в состоянии SX в спеке. И, соответственно, у вас получается так, что у вас вот это вот состояние SIS, состоящее из всех спек, оно вот здесь. Если вам нужна
Speaker A
историческая какая-то информация по пропозам, по пожам, то вы можете зайти в агент может зайти в архив. Опять же, ручками мы гораздо реже это заходим. Это в первую очередь мы строим весь контекст для агента. Это такая самая база основа
Speaker A
конспека. Ну, наверное, ещё можно стоит упомянуть про skill Explore. Это вот что-то такой чуть более облегчённый вариант Грилми. Он немножко по другим принципам работает, но смысл примерно такой. Это вот формат брейнсторма вместе с вами, где он задаёт разные вопросы,
Speaker A
рисует схемы, проектирует вместе с вами, и он может быть опциональным, да? То есть, когда вот у вас особенно там идея довольно-таки сырая, где он хорошо с вами поштормит, и по результат его работы он предложит, вызвать скил пропоза, то есть скажет, кажется, мы всё
Speaker A
проработали, как бы, если у тебя нет вопросов, давай мы сделаем пропоз давай всё делаем пропост, там фиксируем apply и так далее. Вот это самая основа.
Speaker A
Понятно, что у нас на самом деле, когда мы работаем в команде там в Enterprise наших клиентах, у нас набор команд он шире. То есть там есть разные дополнительные нюансы. О них может быть чуть позже мы как раз поговорим. Как-то
Speaker A
так. Ну, кстати, я тебе хотел сказать, что поскольку я пользуюсь скилами мата, они же тоже там постоянно меняются и добавляются. И у него сейчас недавно был вот прямо очень серьёзный апдейт. И там вот то, что экспорты ты называешь, это
Speaker A
сейчас не Gre, это Wayfinder называется. Это там прямо описано, что он используется при тасках, которые невозможно там закрыть в рамках одной сессии, бла-бла-бла. Там есть такое описание, короче, когда он составляет некую такую карту Vision, делает [фыркает] много исследований и на базе
Speaker A
этого генерирует ишью и к нему цепляет ещё много, ну, поднаправлений, если они там есть, потому что эта штука может цеплять как бы вообще всё подряд. И я, кстати, это интересно получается. У Мата оно использует, знаешь что, оно использует ту систему тикетов, которая у
Speaker A
тебя есть. То есть он вначале тебя опрашивает, типа ты где хочешь? Ты ему говоришь, например, на гитхабе, он говорит: "О'кей, он использует определённую систему лейблов, плюс использует фишки самого Гитхаба, чтобы строить зависимости и так далее". И в конечном итоге у нас сейчас там вот
Speaker A
просто вот такой огромный объём ишлюсов, который он генерит без остановки. Там есть карты, там есть гриллинг, и он всё это как бы помечает. И удобно ещё то, что любой может как бы с там есть даже такой у него классная скилл, который
Speaker A
называется Askat. Она тебе говорит, типа, что дальше делать. Либо в текущей сессии, либо ты говоришь askмат, посмотри, что там вышью надо. И он такой скажет: "Смотри, вот там типа вот эту штуку можно сейчас грилить, вот эту нужно доработать на Wayfinder проделать,
Speaker A
а вот это уже ready to agent можно брать в работу, а вот это надо в тикеты превратить, у тебя есть спека". Ну и как бы вот такой примерно процесс может там происходить. Вот мы можем показать, кстати, вот давай, если это возможно,
Speaker A
про поуз прямо запустить, посмотреть, как он спрашивает. Просто интересно. Я почему хочу, чтобы это люди увидели?
Speaker A
Один из же важных факторов, э, работы в этой системе, что ты сам ничего не пишешь. Всё, по сути, сводится к вопросам. Это довольно прикольно, потому что это намного проще, чем думать о том, что, блин, мне придётся писать спеку,
Speaker A
там, всё это делать. Не придётся. Он ведь не только тебя спрашивает, он же исследует кодовую базу, берёт весь контекст да и это очень важно, да, это сильно облегчает ему работу.
Speaker A
Ну, соответственно, вот гораздо больше он задаёт вопросы именно в режиме эксплора. И сейчас давайте что-нибудь здесь, ээ, давай сделаем раздел, э, не знаю, интеграции GitHub, да, условно.
Speaker A
Ну, понятно, что здесь ты большое описание какое-то будешь составлять, а здесь он будет сейчас проводить анализ.
Speaker A
Угу. А всегда часто я в программном комите большое количество конференций, когда говорят: "Давайте мы сделаем какой-нибудь интерактив и будем показывать работу агентов". Я всё-та говорю, что это максимально скучно, потому что ты сиди, вы сидите и там втроём смотрите, как
Speaker A
агент что-то делает. Это вот такой некоторый куколдинг. Это не это это не очень динамично. И нужно постоянно развлекать слушателей в этот момент. Ээ том что ты не поверишь, я же делал два мастер-класса на халоуде и тим лиде, как
Speaker A
раз, да, мы где-то там в параллель выступали, и я и у меня был он двухчасовой, и я понимал, что я не смогу как бы вот в таком режиме людям показывать, потому что ты его запускаешь, и ты понятия не имеешь,
Speaker A
сколько он там будет работать, и тебе реально нужно развлекать. И у меня в итоге это просто в стендап превращалось, потому что я что-то там запустил и с людьми просто разговариваю. Да, я до сих пор не научился этого делать. Я не знаю,
Speaker A
как правильно. То есть реально вот показывать работу интерактивную с агентами, это это скучно. Поэтому вот в некоторых докладах, которые там ребята готовили, они просто так говорит, просто чекаут делали. Следующий говорит: "Так, смотрите, я сделал, вот он сделал, он
Speaker A
сделал следующее". Вот такие артефакты он родил. Да, да, да, типа того. Ну я единственное, что хотел не пройти с тобой полностью этот путь, очевидно, а дойти до точки, когда он начнёт задавать вопрос, чтобы прямо увидеть вот этот процесс, потому что это будет, ну,
Speaker A
как-то поинтересней. Другой вопрос, мы не знаем, сколько времени он сейчас вот будет заниматься тем, чем он занимается.
Speaker A
Ну, о'кей, давай, пусть он занимается, мы как бы его оставляем. О'кей? То есть вот есть понятный процесс, есть историчность, есть спейки, много довольно документов и так далее. Там много вопросов из этого вытекает. Но давай сначала поговорим про Aдоoption.
Speaker A
То есть когда вот у тебя конкретно компания, вот конкретно ты это посмотрел, потёр такой ручки и говоришь: "Так, ребята, с завтрашнего дня работаем по OpenS". Вот расскажи, как это начиналось и как ты этот процесс делал, собственно, и с какими проблемами
Speaker A
сталкивался. Ну, начали мы просто с того, что, ребяли разработчикам, он говорит: "Ребята, вот это, наверное, ещё до, наверное, стратегического решения, что мы 100% вообще полностью все на него будем приходить, мы просто нашим членам айклубам, а пару слов о том, что такое
Speaker A
клуб". Это мы ещё в середине двадцать пятого сделали небольшую группу, позвали ребят, которые идейные, которым кайф.
Speaker A
которые мы там собирались там раз в 2 недели примерно, сейчас чуть пореже собираемся. И мы там вот там какая модель вышла, какой агент, что нам, что зашло, что не зашло, ресрчили, на каком там, не знаю, стеке мы хотим работать,
Speaker A
чтобы это там не было полностью вообще, что каждый на чём-то своём работает. И, собственно, вот он, в том числе, этот клуб нам помогал в своё время, а, адоптить ребят. То есть мы, к примеру, ребята, которые сомневались, что это
Speaker A
работает, а мы просто в парное программирование ставили кого-нибудь члена этого клуба, и он помогал кому-то заадоптиться для того, чтобы понять, что вот там садился на конкретной задаче, показывал: "Вот твоя задача, давай мы сегодня делаем её с агентом". Вот
Speaker A
видишь, она работает. Теперь ты попробуй. Пробуй. Нет, не руками код пишешь. Нет, с агентом. Вот садишься. И вот, собственно, таким образом ребята адоптились. И, [фыркает] собственно, ребята из клуба, там, разработчики начали тестить просто именно в рамках функции, да, в рамках разработки. Вот
Speaker A
как разработчик садился, писался безпеки из спекналитик, да, то есть аналитики там в конфлюнсе по-прежнему ещё тогда работали преимущественно. Из этого он агрегировал какие-то артефакты именно в Опспеке и, соответственно, работал. Это вот то, с чего начиналось. Потом вот, когда мы в новом году как раз после
Speaker A
страссии, когда мы поняли, что нам нужно всё-таки фреймворк расширять на всю команду, чтобы это было общая вот эта шина контекста, у нас было месяца месяц или полтора брейншторма с аналитиками.
Speaker A
Это вот где-то в феврале там встречались один-два раза в неделю. Мы, когда говорили, что, товарищи аналитики, теперь вы должны будете писать спецификацию не в конфлюнсе, а агентами в репозитории. Ну, это большое такое, на самом деле, значимое изменение в
Speaker A
процессах, да. Оно затрагивает много чего, потому что и заказчик может хотеть артефакты в некоторых проектах ещё до сих пор в конфлюенсе, да, то есть и в некоторых случаях это требование договора, что у нас там должны быть эти артефакты. В принципе, сам пайплайн
Speaker A
работы нужно было вот туда перестраивать, потому что, опять же, бывает бизнес может ходить в нфлю, задавать вопросы, как он будет делать это в новой реальности. И там вот прямо очень большой пласт вопросов мы обсуждали думали как наверное вот
Speaker A
это такой был самый такой сложный такой брейнсторм этап, прежде чем мы продумали примерно, как действительно аналитики вот в это всё будут перестраивать свою работу. После этого мы начали запускать пилоты с аналитиками и параллельно начали думать, что как работать с QA. С
Speaker A
QA мы здесь изначально а думали, что вот как а приходит аналитик, запускает условно прос разработчик условно только Apply и у тестировщика, который у него там тоже свои бы скилы, которые он запускает для того, чтобы там написать фототесты и так далее. И одна из таких
Speaker A
инсайдов, которые мы получили где-то в апреле, что вот эта вот идея, то, что тестировщики должны приходить писать автотесты, она мёртвая, она неэффективная, потому что агент должен писать автотесты сразу, в том числе тон, да, он их может делать и в рамках своей
Speaker A
реализации он должен их сразу писать, сразу же их прогонять, и они сразу же должны выполнять эту функцию, как раз прогонять эти автотесты, они дают сразу цикл, задают ему обратную связь, где что-то пошло не так. А разрывать это на
Speaker A
две роли - это, ну, просто а зачем? Это больше потерь и так далее. Поэтому мы в какой-то момент поняли, что где умирает роль автотестов в тестировщиках. Вот примерно в этом месте, да. То есть действительно это такое понимание, что
Speaker A
действительно на рынке даже скорее всего и на тестировщики, которые пишут автотесты, на мой взгляд, будут нужны меньше, потому что действительно теперь это должна, скорее всего, делать одна роль, просто потому что так процесс эффективнее строится. Это вот такой прямо первый набор проблематик, которые
Speaker A
мы столкнулись, которые мы начали решать. Соответственно, мы начали с определённого количества проектов. наверное, замедлилась адаптация SDD у нас, скажем так, мы внедрили его где-то в мае, где-то на половину проектов, скажем так, вот на в половине проектов начали экспериментировать для того,
Speaker A
чтобы с этим работать. И здесь у нас просто пришёл очень крупный, важный государственный проект, который с очень сжатыми сроками. И аналитики этого проекта справедливо сказали, что, ребята, мы не хотим идти на эти риски сейчас с переработкой принципов документации. пришлось сказать, пойти у
Speaker A
них на поводо сказать, что хорошо, ребят, мы не запускаем на вашем проекте SDD, понимаем, ну, там реально очень большая горячка была. Оглядываясь назад, я не уверен, что мы поступили правильно.
Speaker A
Возможно, всё-таки нужно было это делать, потому что разработчики-то всё равно писали аишкой. Им не хватало спек в формате, который бы лучше воспринимался агентом. Разработчики начали на этом проекте Open SPC использовать без аналитика, шаря спеки между фронтом и Бэком. На в каких-то
Speaker A
случаях, точнее, вот даже до того, как это они дошли, они начали делать спеки, каждый свою. БК свою пишет, фронт свою пишет. Это первая же ошибка, наверное, которая там очень быстро всплыла. То, что спики расходится, да, то, что там
Speaker A
два агента в двух сессиях по фронт и бэк по-разному, даже несмотря на то, что это контракт на описание, бизнес-логику они по-разному интерпретировали. То есть мы вот тут же поняли, что она должна быть единой. Ни в коем случае не должна
Speaker A
разделяться спека между фронтом и бэком, потому что это как бы мало того, что дублирование тебе вот смысла, бизнес-смысла, да, для чего вы это делаете, они у вас дублируются зачем-то, так они ещё и разряжаются и по-разному интерпретируются разными моделями.
Speaker A
Потом, когда это сшиваешь, возникают там набор некоторых проблем. Поэтому они начали делать общие чижи между фронтом и бэком. Там у нас тоже как бы не всё гладко пошло. То есть вот не хватало как раз вот, чтобы аналитики к этому моменту
Speaker A
подключались. Ну вот там на в середине процесса опять же очень крупного большого проекта в сжатые сроки с не могли мы себе позволить прямо всех аналитиков перевести. А там нужно ещё и на на заказчика- это некоторые вещи завязаны. Поэтому проект он там сейчас
Speaker A
подходит потихонечку к своему завершению. То есть это там федеральный конкурс, федеральное мероприятие для школьников, скажем так. Сейчас уже потихонечку ребята, которые переходят с этого проекта, который идёт к концу, они вот погружаются. И я надеюсь, там ближайшие пару месяцев мы сможем
Speaker A
сказать, что у нас действительно все 100% проекта перешли на SDD. Как-то так. Ответил на твой вопрос.
Speaker A
Давай дальше копать в глупе. Расскажи про монорепу, потому что как бы переход на файлики - это не просто раз и сделали, да? Потому что у тебя бывает, что проект состоит из большого количества подпроектов, и тебе нужно сервисов там, да, и тебе нужно как-то
Speaker A
всё синхронизировать. Расскажи про концепт, как, кстати, правильно работать в современном мире. А, собственно, проблема нюансов, да, то есть на внедрение SDD, которое по факту для нас внедрение AI, в том числе сквозного сквозным процессом. Много, на самом деле, таких кейсов, нюансов
Speaker A
породило. Вот. А что делать, когда у тебя, э, не один репозиторий с монорепой, где у тебя и фронт, и бк делает, когда у тебя есть ээ несколько сервисов или есть монолит, и как бывает очень часто, есть большой монолит и
Speaker A
вокруг него пачка некоторых сервисов. Ну вот, конечно, начинали мы в том числе с простых проектов, где действительно монорепа и там агент очень себя хорошо чувствуют.
Speaker A
Это вот у нас есть несколько продуктов международных, там с многомиллионной посещаемостью. и с монорепами. И там он отлично хорошо себя очень Open SP чувствовал, делая сквозные какие-то изменения. Что делать с вот большим монолитом, когда у тебя есть монолит и
Speaker A
несколько разных сервисов, которые прямо реально разные домены, но иногда у них очень сильная связанность, допустим, админка монолита может управлять вот этим вот сервисом. Ну вот так вот исторически сложилось нам так передалось. А в проекте одно ошибочно мне, на мой взгляд, то есть брать и
Speaker A
разбивать это на разные спеки в каждом репозитории, потому что иногда у тебя приходит сквозная сквозное изменение бизнес-функциональности.
Speaker A
И вот в том числе с точки зрения аналитики, да, то есть у тебя один одно спецификация, которая затрагивает, описывает всё это сквозное изменение через несколько через несколько репозиторий, сервис и так далее. И надо было эту как-то проблему эту решать. и
Speaker A
доставать вот эти спеки из выделенных сервисов в в какой-то общий вид. Что мы придумали? Мы сделали метарепозиторий.
Speaker A
Вот это эволюционно к нему пришли. В том числе это ещё в рамках брейнштормов с аналитиками в феврале тире марте месяце создали этот комментарипозиторий. И в него просто там команда Make Up, он клонирует все дочерние репозитории всех проектов. При этом папка Opens, она
Speaker A
оказывается на самом верхнем уровне, и она получается и агентом ты управляешь именно самое с этого самого верхнего уровня. В том числе мы такие, ну, раз уже нас для как бы спек это общая папка.
Speaker A
Давайте мы, в принципе, весь харнес будем класть на верхний уровень. А в agency Bлиса вот что условно, что какой репозиторий, какая подпапка, к чему относится. И, ну, в общем, если очень грубо сказать, мы действительно вот этим меторепозиториям, мы превратили все свои вложенные
Speaker A
репозитории, все сервисы и в том числе репозитории монолита в один общий в одну общую моно, да, такую вот искусственно созданную, но позволяющую иерархично агенту во все сервисы ходить и внедрять сквозные бизнес-изменения, что избавило нас, а, от необходимости, от большого количества проблем, от
Speaker A
необходимости описывать агентов, описывать, дублировать бизнес-логику, мотивацию, почему это делается в каждой из отдельных леп, когда у тебя спазны изменения. Вот примерно так. А с точки зрения внесения изменений, то есть это стандартно полуреквесты, сохранение обратной совместимости, там, не знаю,
Speaker A
порядок применения, какие-то правила особые задаются на верхнем уровне. Ну, у тебя в любом случае от того, что их засунул вот в такую, может сказать, монорепа, метарепа, да, то есть которая, ну, эфимерная, можно такое слово использовать, это не означает, что у
Speaker A
тебя всё стало релизиться как единый монолит. То есть ты, когда вносишь изменения, у тебя может быть плквест тут, тут, тут, они как бы связаны, но они в разных местах, и у тебя есть разный порядок деплоя, опять же, та же
Speaker A
самая независимость, ради которой эти сервисы и выводились. Соответственно, видимо, должен быть ещё какой-то набор правил или это естественным образом получается?
Speaker A
Ну, естественным образом получается, да? То есть, ну, грубо говоря, как такие изменения были раньше, да? То есть, когда у тебя действительно нужно было внести изменения функциональности этого, эта проблема уже была решена, да, то есть условно уручным способом, да, то
Speaker A
есть не не мы не автоматизировали это, а в принципе это не автоматизированно до сих пор, потому ну как бы условно на решении тимлюда он там определяет порядок деплоев, как что должно задеплоиться нужный день X, условно, когда мы это релизим на прот как
Speaker A
минимум. Ну, мы понимаем, что умная Ишка, она как бы сама предлагает это. Она такая: "Нельзя, а то сломаем".
Speaker A
Да. То есть у нас Иишка, у нас есть скилы, которые там деплоят это на тестовый стент, и на этот стенд, и там можно задавать в скиле, в том числе порядок деплоя.
Speaker A
Хотите расти как разработчик не в одиночку, а вместе с сильным сообществом? Вступайте и в Hexet Клуб.
Speaker A
Это закрытое пространство для тех, кто уже в профессии хочет развиваться дальше. Здесь помогают определить уровень, построить персональный план развития и дают обратную связь менторы из индустрии, в том [музыка] числе из зарубежных компаний. Клубе живые разговоры о технологиях, собеседованиях,
Speaker A
работе в компаниях, карьерном росте и нетворке. Есть отдельные топики с историями участников, отзывами о работодателях, отчётами менторов и планами развития. Люди приходят в клуб, чтобы расти, и помогают другим делать то же самое. Кстати, знаешь, не могу не задать такой гипотетический вопрос. Вот
Speaker A
нас слушают сейчас ребята, да, и такие: "Ну вам классно, вы там с клодом все сидите, и он за вас там всё решает". А вот те, у кого не клод, а квены, шмены и что там ещё сейчас локально ставится,
Speaker A
как ты думаешь, есть ли вообще у них теоретическая возможность без дополнительного харнеса, э вот в чистом виде так начать работать или этой штуки нужно будет слишком много объяснять и направлять её? Отправлять этой штуки это какой? Это OpenSP в
Speaker A
смысле или чему? Модели, которая будет использоваться. Я имею в виду не топовая модель. То есть, если они взяли н если они взяли deep псик, ну, короче, что-то такое вот, что можно поставить локально.
Speaker A
Ну так, смотри, мы начали начинали работать пнспеком ещё в конце прошлого года, да? То есть и уже тогда было видно, что он неплохо справляется. Это лучше, чем работать другим способом, да?
Speaker A
То есть если мы сравниваем работу безсистемно, без единой шины не сквозным образом, да, то есть и супнспеком, да, то есть в рамках одной модели, то мы понимаем, чтопек уже тогда приносил пользу. А на мой взгляд, как будто бы
Speaker A
сейчас все эти квенны, дипсики и так далее, ну, состояние клода осени прошлого года, мне кажется, они плюс-минус уже достигли. Вот. И поэтому, на мой взгляд, Open Spe здесь будет помогать, в том числе слабым моделям, давая ему чуть более жёсткие границы.
Speaker A
Опять же, ну, как бы, чем слабее модель, тем жёстче должен быть харнес, да, как минимум, который будет держать её в узде и направлять, позволять меньше ошибаться, скажем так.
Speaker A
Угу. Ну, то есть глобально в целом, наверное, можно сказать, что в течение года проблема будет решена. И от того, что у нас локальные модели, мы не будем испытывать, ну, те, у кого они стоят, они не будут испытывать больших проблем
Speaker A
с тем, что оно там тупит, не задаёт вопросов и вообще идёт не туда. Правильно я понимаю?
Speaker A
Ну да. Ну, слово локальный тут иногда некоторые воспринимают как локальный на компьютере, да? То есть локальный мы имеем в виду в это может быть какая-то и большая модель на внутренних производственных мощностях, потому что я не уверен, он премис давай модель. Да,
Speaker A
да, он премиус модели, да, потому что локальные, которые у нас на компьютере, я не знаю, когда они вот прямо до такого хорошего уровня могут дойти с нашим небольшим объёмом памяти на наших локальных устройствах.
Speaker A
Да, правильно. Тогда он он премиis будем говорить. Хотя, наверное, когда-то дойдут и такие. При том, что ты более-менее рассказал, но мы не поговорили прямо о конкретном процессе, то есть вот как конкретно поступать задача, в каком виде, кто её берёт,
Speaker A
какую команду выпускает, [фыркает] есть ли тут при этом тикетница, как она передаёт дальше. Можешь прямо вот рассказать весь пайплайн и сложности, которые возникают на разных этапах, да?
Speaker A
Эх, сложности, на самом деле вот таких вот маленьких интересных сложностей во всех случаях их прямо хватает. Ну и они бывают достаточно индивидуальные в целом относительно процесса. Сейчас чуть-чуть в сторону, прежде чем отвечу на твой вопрос. Собираемся у нас такой маленький
Speaker A
SDD комитет раз в неделю. И вот реально раз в неделя от часу до полутора у нас идёт эта встреча и мы какие-то кейсы. Ну она, конечно, сейчас там, не знаю, процентов 30 занимает это то, как нам развивать наш харнес, какие точки
Speaker A
развития мы обсуждаем, да, еженедельно. Но действительно во многом мы разбираем какие-то нюансы, кейсы, которые нам это позволяет там это сделать. Мы даже сделали свой отдельный сервис, э, который показывает трессировку Чинжей.
Speaker A
То есть мы, грубо говоря, на этой встрече мы открываем этот сервис, и там он собирает эту информацию с репозиториев и показывает, какой каждый чейндж у нас происходит, в каком он состоянии. Его можно просмотреть, можно посмотреть трессировку комитов на Чинжи.
Speaker A
У нас одна из метрик, которую мы сейчас смотрим, это то, чтобы каждый комит у нас был подписан чнжом. Это нам важно для того, чтобы в том числе агент на это мог опираться. То есть условно он, когда заходит в код, когда реверсит, что-то
Speaker A
смотрит, а что, а почему здесь это происходит, он может просто поту посмотреть, что это за комит и какой комит ссылается на какой change и понять, то есть смысл, а там на этифарик прос, то есть чем это отличается? У нас
Speaker A
есть и Task ID, но в Task ID там нужно по цепочке было идти в confluлюс и идти resarchть, а тут тебе сразу конкретный кейс на change, там у тебя все смыслы, почему это было принято и на уровне технического дизайна, и на уровне
Speaker A
бизнесового смысла. В общем, это довольно-таки классно работает. В общем, через него мы смотрим трессировку. Да, это я про то, что действительно кейсов прямо много очень интересных возникает в процессе работы. И там я я пока не могу сказать, что вот когда это будет
Speaker A
идеально работать, ну, примерно тогда же, когда мы идеально вообще все процессы во всех компаниях будут работать. Примерно тогда же. Возвращаясь назад, как у нас сейчас в среднем работает любая задача. Ну, то есть опять же клиент у нас чаще всего
Speaker A
сейчас берём непродуктовую нашу историю, да, там, где продукт взял, сформировал требования. Хотя, давайте, давай, давай, давай сначала с простого примера. Вот наш продуктовая команда наша, где продукты делаются. продукт, а мы ему дали возможность сделать спеки. Продукт делает explore, штормит ботом, делает
Speaker A
propose, формирует вот этот чеe, но верифицирует в первую очередь именно файлик props. Вот в дизайн он вообще может не лезть. Иногда он может полезть и захотеть что-то посмотреть и что-то там поменять, но в целом говорит мы вот твоя зона - это пропози. Дальше ты не
Speaker A
смотришь вообще, как это это деталь реализации. Дальше он делает задачу. Ну, собственно, если задача Discovery приходит в Delivery. В delivery, в задаче конкретно он указывает имя чейнджа, который у тебя он есть, он его пушит в мей ветку репозитория.
Speaker A
Разработчик, когда подключается к этой задаче, в продуктовых командах у нас в большей мере универсальные разработчики, хотя есть там, где и фронт и backк, разработчики подключаются к этомужу и начинают работать. Давай расстроить здесь, что делать, когда у вас фронтбк.
Speaker A
То есть и вообще изначально вся эта движуха с аишкой, она гораздо лучше работает, когда у вас один флстек инженер, который отвечает и за то, и другое. Но как бы реальность такая, что мы сейчас вот не можем взять и всех вот
Speaker A
так вот щёлк и завтра вы все фулстекнженеры. Это некоторый процесс долгий переобучения людей и изменения майндсета и всё остального. Поэтому мы делаем так, что в скиле агента мы в пропоузели инструкцию, что ты должен разбивать работу фронтендера и бэкндера
Speaker A
в дизайн. Соответственно, бэкндерфронтенer, когда подключается, они выполняют именно свои пункты агента. То есть они говорят: "Оepscx supply, сделайфont, opcx apply, сделай back и, соответственно, выполняет только свой набор пунктов". Таким образом, мы разделяем работу между фронтом и беком.
Speaker A
Опять же, это, ну, некоторый костыль, да, объективно, потому что процессы и там 10 лет последнего развития из вебмастеров сделали нас фронтендеров и бэкндеры.
Speaker A
Поэтому как бы сейчас вот будет назад словать, но пока мы этого не достигли, у нас есть такой кост. Ребята делают это, проверяют свою работу, деплоят, тестируют, а, соответственно у нас продуктовы в продуктовых наших командах нет QA. Плот показывает заказчику
Speaker A
продукту. продукт проверяет и деплот это напрот. Опять же, после этого, после деплоя напрот происходит архивация. Ты ты архивируешь спеку для того, чтобы работать дальше с другими спеками. Тут, кстати, важный момент, что здесь важно это как подчищать старые фичафлаги, так
Speaker A
и делать эту архивацию. Потому что когда у тебя висит большое количество открытых спек, у тебя больше шанс конфликтов, потому что потом в каком правильнее в правильном порядке их смерджить, ты можешь не в правильном порядке. могут конфликтовать, может агент не учесть все
Speaker A
конфликты открытых спеку, потому что он заточен в первую очередь смотреть именно на мейн спеку, смотреть на конфликты потенциальные точки развития именно с ней. Хотя опять же вот работая с мы себе можем позволить работать с топовыми моделями во многих проектах, в
Speaker A
большинстве проектов, он замечает не забывает проходить и по текущим открытым ченджам. У него то есть есть такие, то есть установки. И в принципе он находит, но всё-таки когда прямо слишком много, у нас прямо был кейс, когда он не учитывал
Speaker A
проблемы, о которой есть в соседнем чинже. Вот поэтому мы в том числе сейчас, когда там у нас несколько чнжей, из них цепочку делаем о том, что ты ты не можешь запуститься раньше, чем этот и так далее. И, соответственно, иногда ты,
Speaker A
кстати, из Эксплора, тут я, кстати, не упомянул, ты не обязательно делаешь одинчейндж. Explore говорит, что я тебе предлагаю сделать три разных ченджа и, соответственно, декомпозировать работу таким образом.
Speaker A
Причём сделать их строго такой последовательности и в том числе сам пропишешь эти зависимости. Вот это как работает продуктовой команде в проектах заказной разработки, который у нас есть, когда мы как интеграторы выступаем. Роль продукта у нас здесь меняется на роль
Speaker A
аналитика. Продукты зачастую находится на стороне заказчиков. Ну и мы вряд ли когда, ну, в ближайшее время сможем прийти к такому, что переучить продуктов, заказчиков работать с аишкой на таком уровне, чтобы получать синергию с нашими разработчиками. То есть это
Speaker A
такой непростой уровень. Это это тот момент, когда вот так вот я понимаю, что роль аналитиков в заказной разработке, она останется очень долго, ровно потому, что не всегда компетенции продукт в растонения заказчиков там позволяют в достаточную глубину, во-первых, хорошо
Speaker A
правильно всё формулировать, правильно ресерчить, правильно проектировать и работать с в агентском пайплайне современном, так как работаем сейчас внутри у себя мы. Поэтому это аналитики и аналитики в этом случае у нас пишут про покс. То есть словно они сделали
Speaker A
интервью с заказчиком, с клиентом, собрали с него требования. Эти требования в сыром виде, да, там интервью передают, закидывают в агент в то же самое Explore, проектируют этот просют это разработчику. У нас в какие есть такие интересные нюансы? Есть
Speaker A
скилы, например, вот как раз разработчик сейчас это, а сейчас мы это вшили. Мы это вшили в прозe. У нас в рамках прополуза проектируется, в том числе дополнительный файлик тестовой стратегии, которая прессирует, а, все сценарии Геркина на пирамиду тестирования и
Speaker A
говорит, каким видом тестирования нужно будет покрыть каждое требование. Это позволяет не дублировать где-то тесты, чтобы тесты там, к примеру, на разных уровнях у нас не покрывали одно и то же, да, к примеру, что мы не на юнитах и
Speaker A
интеграционных НТН не делали всё то же самое. м, позволяет сократить количество НТН-тестов, которые по-прежнему остаются дорогие. Несмотря на то, что, конечно, кратно проще, чем раньше, да, тесты сейчас даются. Тем не менее, они могут гораздо чаще и флаги могут быть, и так
Speaker A
далее. Поэтому юниты интеграционными, где есть возможность закрыть ими- это замечательно. Поэтому мы это используем.
Speaker A
Не открываем спор там пирамида или кубок. По-моему, на одном проекте у нас больше кубок идёт, а на другом проекте пирамида. Это, мне кажется, ещё от проекта зависит. Какие-то у нас ещё дополнительные артефакты есть. Есть артефакты документации, что должно быть
Speaker A
ещё по итогу смерно в документацию пользовательскую. И есть ещё артефакты дополнительные в рамках Чинжал у нас формируются для того, чтобы закрыть формализованное требование от заказчика по освещению и подписыванию некоторых моментов. Для чего это нужно? Потому что потом аналитик для того, чтобы показать
Speaker A
заказчику, он берёт этот чейндж и экспортит отдельным скилом в confluence вот именно в том виде, вот в виде шаблона, который нужно именно заказчику.
Speaker A
Также есть очень у нас дополнительные файлик и юзкейсы. Тут у нас была такая интересная история, когда мы заходили в марте, в Openпек с аналитиками.
Speaker A
Аналитики говорят: "Блин, вот Гертин, он хуже читается, чем юзкейсы". Вот юзкейсы проще читаются человеком. Давайте мы переделаем на USкейс. Мы такие: "Да, в принципе, давай попробуем". И мы перепилили скилыспека так, чтобы они делали именно в формате юзкейсов и
Speaker A
откатились назад. Почему? Потому что мы поняли, что автотесты как раз трессировка в выполнения и вообще, в принципе, автотеста именно геркин ложётся намного лучше. Поэтому, да, здесь пожертвовали чуть-чуть читаемостью относительно человека аспек, но получили лучшие трассировку в тесты, которые у
Speaker A
нас есть. Дальше там разработчики передаётся всё то же самое. Там у нас в пронбк разделение в большинстве проекта заказной разработки у нас на флстекав практически нет. И скиды там некоторые скилы деплоя. Тестировщики сейчас отходя немножечко от автотестов, хотя они сейчас в некоторых проектах
Speaker A
всё-таки приходят и такие говорят: "А вот мы как люди здесь заметили, что здесь автотесты можно делать, улучшить, и они могут в том числе вносить изменения в автотесты". Но опять же основной цикл всё-таки автотестирования закрывается в apply именно разработке
Speaker A
цикла. То есть они могут внести какие-то изменения в автотесты, могут дописать свои какие-то автотесты. то, что вот они подумали и сказали, что вот мы ещё вот такой хотим придумать, условнотест, который там автоматически это закроет.
Speaker A
Они ещё вот так вот, ну, скрупулёзно и не до конца доверяют нашему агентскому пайплайну. У них есть некоторые скилы, когда они проверяют отдельным агентам корректность наших спектр, да, то есть точно ли там у нас нету расхождения потенциальной. И были случаи, когда его
Speaker A
даже какие-то случаи находили эти вещи. Да, кстати, там разработчики в конце цикла разработчиков у них есть ещё ревьём. Раньше он у нас был в репе, сейчас он есть в мы его замкнули локально, потому что, ну, нет смысла там
Speaker A
пушить куда-то в репозитории, там запускать агента ревью, чтобы и так далее. Проще локально ты цикл ревью пройди, а потом уже запуши уже чистую версию. Условно, после работы тесировщиков уже показывается заказчику, соответственно, приёмка, если есть какие-то замечания и там плей. Ну вот,
Speaker A
примерно так писал весь цикл. [музыка] Да, у меня тут много вопросиков по пути возникло.
Speaker A
Давай начнём, наверное, с продуктов. Есть такое мнение. Ну, понятно, что у вас заказная разработка, но когда речь идёт про продуктов, да, во-первых, судя по тому, что ты говоришь, если бы это был не заказной проект, а продакт был на
Speaker A
вашей стране, который участвует, он должен быть довольно техническим чуваком, чтобы не только комлайном пользоваться, но и по сути даже вот когда ты показал этот пропоз, он всё равно какие-то технические детали у тебя включает. И получается, что он должен,
Speaker A
ну, хоть как-то понимать эту тему. Правильно я понимаю? Смотри, то есть задача работы именно продукта чуть в сторону. Я считаю, что понимание там чтения гита, работы с агентами, работа с гитом, это база для любого офисного сотрудника современности. То есть вот как раньше,
Speaker A
не знаю, там что там браузер, Excel, Word должен знать. часто ты должен помимо этого агентов и гит знать. Это вот мастх. Мне кажется, без этого сейчас прямо никак. Тем более, если ты продукт.
Speaker A
Поэтому вот у нас там коллеги иногда говорили: "Вот давайте мы упростим так, чтобы коллегам не пришлось использовать агентов и гит у себя там локально где-то и так далее". Ты понимаешь, что они там строят замки для того, вместо того,
Speaker A
чтобы решить вопрос небольшого самообразования, который прямо людям очень сильно в дальнейшем поможет. Поэтому люди должны писать скилы, работать с этим и так далее. Поэтому продукты с этим работать могут. Могут работать с, я не уверен, что они работают, насколько я знаю, они,
Speaker A
по-моему, не с консольной работают, не с клаудкодом, они работают с апами, да, с эпом. И, по-моему, там они татамы скилы запускают. Я навиких, по-моему, у нас тоже не все с клауд-кодом работают.
Speaker A
По-моему, там половина точно работает с эпом и там гоняют эти скилы, насколько я знаю. И вроде как бы нормально всё у них получается.
Speaker A
читаю насчёт чтения в пропоузе мы стараемся, чтобы туда протекало минимум технических деталей, хотя иногда технические детали туда некоторые протекают. Мы стараемся это уменьшать.
Speaker A
Вот в том числе был бы был такой недавно буквально запрос, что действительно вот получился какой-то слишком технический чейндж в пропаузе. И почему бы это не выносить всё больше в дизайн для того, чтобы вот оставлять больше технических смыслов туда. И мы, возможно, даже
Speaker A
чуть-корректируем сейчас скилы для того, чтобы действительно чуть меньше протекало. Хотя, ну, как бы сейчас как это решается? Просто если есть химические детали, ты за них можешь не вникать, ты на них не отвечаешь. За них отвечает разработчик, когда он приходит,
Speaker A
принимает этот чеange, и он в том числе отвечает за то, что в любом случае вычитывает весь прос и валидирует все технические детали. Есть мнение, что наиболее эффективный путь во всей этой цепочке PDLC, скажем так, да, это когда продакт не просто готовит какое-то
Speaker A
базовое там описание в каком-то виде в зависимости от фреймворка или подхода, который ты используешь, а прямо делает прототип, который уже потом передаёт дальше. Что ты об этом скажешь?
Speaker A
Да, да, да. Ну, здесь как как это делается? Продукты, сейчас возьму продуктов сначала. В клоде они запускают скил: "Сделай мне прототип". И клод делает сейчас HTML прототипа, который сам заливает своё облако, которое может показать, который в том числе на самом
Speaker A
деле пойдёт в дизайн-систему, возьмёт даже твои типы стиле, но пускай он верхнеуровнево по блокам разложит, как это всё примерно работает именно с точки зрения там просто HTML-фаль, как страничка выглядит, там даже какие-то компоненты будут частично работать. У аналитиков примерно такой же. У
Speaker A
аналитиков есть свой скилл, который они пошарили через свой репозитории дополнительные внешний. И сейчас они в том числе влились в наши репозиторию общих скилов, которые переиспользуются на всех основных проектах заказчиков, которые они запускают и генерует свои протокипы там с некоторыми своими а
Speaker A
нюансами. Это вот то, что у нас сейчас с точки зрения протокипов используется. Я знаю, что был доклад у коллег на подлодке, по-моему, было аичной крюшный, как раз открытой, причём сессией. Ребята рассказывали про SDD Open Spec тоже используют. И они говорили, что вообще
Speaker A
делают в отдельном репозитории оди полноценно рабочий прототип. Причём не обязательно они делают со спеками, потом отдают это разработчиками. Разработчики просят: "А теперь отреверси мне этот проект в Open Speck". И брали Ctrl C, Ctrl V эти спеки переносили в свой
Speaker A
основной проект. И теперь по этим спекам реализую уже вот в этом проект. Опять же обновив, конечно, спеки с учётом того, что у него теперь новый истоточный контекст. Вот слышал такую практику, мы не пробовали пока что. Так.
Speaker A
Угу. Ну, в любом случае все идут в то, чтобы не просто ProdКТ дал какое-то описание, но и что-то показал и дал.
Speaker A
Да. У нас вот именно с точки зрения аналитики сейчас почти всегда, когда там собрались требования заказчика, они сейчас всегда делают какой-то прототип, чтобы заказчику показать. Это очень сильно ускоряет согласование процесса.
Speaker A
Всё. Так, соответственно, и продукт у нас тоже приходит к часто с каким-то прототипом к ребятам. Это в продуктовой разработке мотоцикле внутри.
Speaker A
[музыка] YouTube не единственное место, где можно получить пользу от организованного программирования. Также я пишу про обучение, разработку и технологическое предпринимательство у себя [музыка] в Telegram-канале и ВКонтакте. Там я публикую бережно написанные руками посты пару раз в неделю. Только мой личный
Speaker A
опыт без новостей, без кликбейта и нерослопа. Будьте организованы, подпишитесь, ссылка в [музыка] описании. Хорошо, тогда следующий вопрос. Мы поговорили о том, как происходит передача, но есть ситуации, при которых нужно вернуть обратно и доработать. Как это? То есть на уровне репозитория
Speaker A
понятно, все артефакты там фиксируются, но должен же быть ещё какой-то процесс, где в тикете есть, что задача заблочена, что она на ком-то висит, чтобы можно было понять, а что, собственно, происходит, как это решается? То есть какой-то параллельный тикет в жире, где
Speaker A
куда любые истории эти отмечаются в виде статусов или как-то по-другому? Смотри, мы работаем по канбану, и у нас есть с точки зрения визуализации проекта, да, то есть у нас сейчас там вспомню основные колонки в работе, в тестировании по правилу канбанат и назад
Speaker A
передавать. Ну, плохая практика, возвращать на процессы назад. И поэтому мы не двигаем назад, условно просто приоритет у этой задачи, да? То есть, если задача какая-то в тестировании нашлась какие-то проблемы, баги и всё остальное соответственно просто разработчики туда делают акцент и
Speaker A
работают дорабатывают в рамках неё. То есть в том числе там дали какой-то фидбэк заказчики, если требуется аналитика, может подключиться, в том числе аналитик до проработать требования. Это выразится в изменении чиджа, в в появлении дополнительных пунктов в тасках, которые
Speaker A
даются разработчики, разработчики имплементируют. Если это просто баг, то есть, грубо говоря, когда не нужно требут, не требуется изменения спецификации, то разработчик просто дорабатывает в рамках текущего изменения. Баги ещё, когда нужно использовать Openспек, а когда нет, да?
Speaker A
То есть иногда вот, слушай, ну мне там цвет кнопки поменять, а надо ли мне Openспек для этого запускать? Нет, да?
Speaker A
То есть если у тебя там действительно это ошибка вёрстки какой-то, ты можешь просто попросить напрямой агента и не дёргать именно Open SP, потому что как бы здесь у тебя никакого эффекта нет. То есть мы важно говорим, что ты должен
Speaker A
включать голову, да? То есть если ты видишь, что спека точно никак не не афертится, то тебе незачем действительно запускать pipйплаeline Explorer для того, чтобы это всё делать. Помимо этого мы ещё учли, то есть это вот такие кейсы мы решили. Помимо этого ещё решаются
Speaker A
ченжи, которые технические бывают, чейнджи, которым там, допустим, не нужно изменение спек. И мы это ещё там, по-моему, весной у себя решили, что у нас есть типа ченджей, отдельный скилл, который создаёт технический чейндж.
Speaker A
Допустим, это рефакторинг, у тебя изменение функциональности, не изменение требования, да, и там у тебя спеки не генерация. И вот, кстати, OpenSPC только сейчас в версии, по-моему, 1,8, которая вышла в пару недель назад, тоже добавил такую функциональность, что вот такие у
Speaker A
тебя технические чижи есть, которые не афектт изменения спек там тут теперь тоже гладко работает. Наши наработки можно убрать. Вообще забавно, что те проблемы, которые мы решали весной, смотрим, как OpenS их сейчас догоняют, и нам наши решения уже нужно убирать,
Speaker A
потому что вот как бы Openпек- это решил своим системам. Здесь мы, грубо говоря, немножко впереди Онспек этого сами шли и какие-то проблемы решали сами.
Speaker A
Я, кстати, постоянно об этом говорю, и мы с тобой это даже обсуждали, да, что пытаться пилить собственную такую систему, это довольно безумно в современном мире, потому что они всё равно сделают лучше.
Speaker A
Да, да, да. Там весь мир над этим работает. Всё так, всё так. Хорошо, мы ещё с тобой не разобрали ревью. Ты сказал, что он типа сам ревьют, но когда всё-таки пулреквест отправлен, как будто бы ревю тоже должно быть, да, от более там
Speaker A
старших опытных товарищей. Вот эта часть, потому что обычно все жалуются же именно на неё, что вы, конечно, классно там всё сделали, у вас там всё ревью, но в конечном итоге вот это всё прилетает, и кто-то должен прямо ручками, глазками
Speaker A
смотреть или нет? Да, это всё осталось. Это всё классические процессы. Просто настолько классика, что я даже не стал сильно удаваться. Ревю есть человеческое, соответственно. То есть как мы и зна ещё в конце двадцать пятого мы сделали помощника, который ревьют внутри цикла
Speaker A
помогая. Причём стало сделали продвинутого, который там каждую строчечку размечают, типа вот здесь вот такой комментарий, вот здесь, вот здесь такие штуки. А потом ребята говорят: "А можно пока что мы возьмём это, уберём и сделаем это так, что просто он
Speaker A
простынёт, потому что Ctrl C, Ctrl V у агента так проще отдавать, чем копировать с каждой строчки. Мы сделали упрощённой такой штуку. В то время модели очень сильно шумели и очень много давало вот прямо много шумности было.
Speaker A
Сейчас на последних моделях, последние месяцы, я вот спрашиваю насчёт шумности, её очень мало. То есть получается это такой помощник для человека. Опять же человек в первую очередь персам, кто отправил, он получил какой-то фидбк, он и он видел то, что считает не шумом, он
Speaker A
пошёл поправил. Потом, собственно, человек ещё сам это проверяет, но для опять же для него вот вот эта штука подспори. Опять же для того, чтобы мы поняли, что это в первую очередь для человека, который создаёт этот МР - это
Speaker A
отправить там запустить агента. Зачем тебе это долгий цикл, если ты всё равно передашь это агенту назад на вход?
Speaker A
Поэтому давай-ка ты будешь скилревю обязательно запускать локально. И, собственно, у нас сейчас есть скилл, который автоматизирует вообще весь пайплайн, вот это окончание работы. То есть ты работаешь, посмотрел, зааплаил, посмотрел, всё хорошо.
Speaker A
И, ну, там вместо того, что там говорить, там комите архивируют, там отправляй и так далее. То есть ты просто синхронизируй спеки, запускай валидацию спек. Успека есть ещё там дополнительная команда, которая под капотом запускается. Тебе не обязательно делать это валидировать это всё дело. Вот. Но
Speaker A
дополнительно жетельно перед комитом это делать. А когда ты сам просишь закоммитить, агент понимает, что он будет это делать, но мы это у себя в скилах явно прописали. Соответственно, вот вместо всего вот этого там прогонив, отправь, мы это теперь сделали отдельный
Speaker A
скил, типа завершай. Он комитит, синхронизирует валидирует запускает ревью. После ревью может внести правки, закоммитит это всё, если всё окревью пройдено через GLAB. Кстати, вот классная штука, если кто-то не пользуется позвон для себя немножко её открыли. Хотя, я так понимаю, она очень
Speaker A
давно живёт. консольного утилита для работы с Гитлабом для агента. Он создаёт Р через GLAB, э, отправляет его там. Там до сих пор остался ещё агент на другой модели, который, по-моему, там псик у нас крути крутится, который дополнительно это валидирует ещё берёт
Speaker A
его обратную связь, если что может это доработать. Но опять же обратной связи стало гораздо меньше, потому что мы локально теперь гоняем. Лук, локальный лук у тебя это замыкает, всё делает, тебя обовещает и так далее. Что это делает? высвобождает вообще полностью
Speaker A
тебе руки. Ты сказал: "Завершаю", пошёл делать за другой задачей. Ты понимаешь, что на этапе завершения у тебя там он полчаса, иногда час даже может работать просто потому что там в рамках ревью что-то найдёт и так далее, поправит и
Speaker A
так далее. Всё, дальше и брлить по по как раньше принимает. Всё это есть. Но в итоге-то получается, что количество пулреквестов, скорее всего, стало больше, а тимлидов больше не стало. И они там висят или нет?
Speaker A
Да, есть такое, конечно, да. То есть работы стала больше, в принципе. Ну, выполняем мы больше, конечно, всего стало больше, да? То есть условно работа руками, да, код писательны стали меньше.
Speaker A
Мы стали заниматься вообще другими задачами по сравнению с тем, как мы работали год назад, да? То есть очень много всего поменялось. И да, действительно, ты читаешь код, ты читаешь спек больше, ты читаешь свой код больше, ты читаешь чужой код больше,
Speaker A
много читаешь, мало пишешь. Это то, к чему пришли. О'кей. Ну, наверное, можно сказать, что в этом процессе стало участвовать больше людей и, соответственно, в целом люди стали больше как бы заниматься ревью, чем всем остальным. Но возникает, знаешь, какой вопрос сейчас во многом
Speaker A
это профессиональные разработчики, да, и во многом они ещё помнят, потому что как бы ручки, вот они, это было недавно. Как ты думаешь, вот на перспективе, скажем, года, двух-трёх, сейчас даже речь не про появление новых ребят, а вот даже про
Speaker A
ускользание навыков от текущих ребят, потому что ты же всегда учишься или делаешь какие-то новые задачи, которые ты раньше не делал. То есть, например, у тебя там какая-то оптимизация в базе данных, тут ты работаешь с новым видом аутентификации.
Speaker A
И когда ты это делаешь вот без ручек, естественно, ты очень будешь примерно представлять, как это работает. Я с этим последнее время очень много сталкиваюсь.
Speaker A
Я уже очень большое количество вещей не понимаю, как в проекте реально работает. Типа, я какие-то общий. Причём это, знаешь, это ещё проблема такая, как в обучении, когда ты что-то учишь, тебе очень надо долго учить и прямо упираться, чтобы это запомнить. А когда
Speaker A
ты один раз ручками сделал, у тебя как бы это в тебя вошло и всё, и ты это можешь. Вот ты чувствуешь, что это будет проблема или это уже проблема или вообще не проблема, и в конечном итоге нам не
Speaker A
придётся погружаться в спеки, в, ну, я имею в виду спеки, не знаю, протоколов, понимание каких-то систем, которые вокруг нас, и всё это будет само. Я давай так в целом у меня такой майндсет, что предсказывать какое-то будущее я, наверное, перестал в двадцать третьем
Speaker A
году, наверное, или в двадцать четвёртом, потому что такая дичь у нас во всём этом творится каждый месяц, когда ты вообще не понимаешь, ну, то есть все твои прогнозы, они могут очень сильно разбиваться. Этот какое количество вообще и вот если взять
Speaker A
двадцать пятый год по аишке, какие вот как мы это представляли, как это будет работать, какое количество инструментов просто практика умерла, да? То есть, когда там выпускались какие-то стандарты, это всё перечёркивалось, там вышли вот просто скилы вышли, да, они
Speaker A
просто кто-то какие-то свои большие замки контекстов строил. Вот просто один из кейсов программного комитета тоже в сторону предсказывания будущего расскажу. Э, пришли ребята, которые говорят, что, ребят, вот мы запилили платформу аа для еагентов, а члены программного комитета такие
Speaker A
смотрят на него и такие говорят: "Ну всё хорошо, ребята несколько месяцев работали, но это уже платформа предыдущего поколения. Сейчас уже даже как бы не не имеет смысла". Ты понимаешь, что ребята месяцы работали, да? То есть это очень сильно
Speaker A
показательно. Это насчёт прогнозов. Ну, если всё-таки там попытаться это сделать и поговорить, подискутировать немножко про эту проблему. С одной стороны, меня не пугает то, что это происходит, это потому что здесь у меня условно аналог.
Speaker A
Пугаешься ли ты, когда ты делегируешь работу на джуна и ты не знаешь, как он там код написал, да, условно, или на на Мидлан, да, джуна, давайте забудем же, на медла ты делегировал, у тебя там шесть медлов, но ты не знаешь каждую
Speaker A
строчку кода там, которую он написал, ты, возможно, через себя её не пропускаешь, если у тебя кроссревью.
Speaker A
Вот, соответственно, тут такое же примерно делегирование, да, на агентов. А можно я поспорю немножко?
Speaker A
Давай. Я, кстати, вот часто про это говорю, как будто немножко размылось слово делегирование. Делегирование - это про ответственность. Это не про то, что ты кому-то что-то сказал. Это про то, что передал ответственность. И с агентами делегирования не бывает. Это
Speaker A
невозможно по определению слова делегирование. Ну тогда это просто другое какое-то слово должно быть, потому что вот у меня, например, вот представь, я всё-таки компанию управляю, да? Вот у меня есть руководитель отдела маркетинга, у меня есть финансовый директор, у меня есть главный бухгалтер.
Speaker A
Ты же понимаешь, какой это уровень ответственности и какие там решения принимаются. Вот это называется делегирование. Эти люди действительно делают мою жизнь проще, потому что я могу не думать о бухгалтерии, а какой-нибудь штраф, может быть, там миллинов 20, допустим, который меня
Speaker A
обанкротит и приведёт к катастрофе. И теперь агент, который, ну, представь, я его пущу и скажу: "Ну, давай, подай мне годовую отчётность". Естественно, делегирования там в жизни никогда не будет. Это помощник главного бухгалтера, это помощник финансового директора, это помощник руководителя маркетинга. Но это
Speaker A
не замена никогда. И поэтому, а ведь есть же четыре четыре уровня делегирования, да? Вот по одной по одной из разных классификаций есть уровень делегирования, когда ты отдаёшь типа полностью и всё, ты подключит, всё делаешь. А с другой стороны, когда ты
Speaker A
просто каждый шаг контролируешь его, да, то есть ты делегируешь, но маленькими маленькими шагами, и у тебя много-много точек контроля. Это то есть вот, ну, видите, классификация уровня делегирования. И то, и другое называется делегирование. Можно так говорить, но по
Speaker A
сути самое главное в делегировании - это то, что ты высвобождаешь свой ресурс. Здесь ты его, ну, не высвобождаешь. Это просто, ну, то же самое может говорить, что когда редактор генерирует тебе класс или D диаграмму или поdди диаграмме, ну,
Speaker A
или там тесты генерируют и так далее. Ну, генерация не сегодня появилась, да, она появилась достаточно давно. Мы же тоже могли тогда говорить, что это делегирование, но никто это слово не употреблял. И здесь я, наверное, склонен вот к этому, потому что если какая-то
Speaker A
штука не убирает от меня уровень ответственности, ну, она не освобождает мой мозг, она не освобождает мой ресурс, я не могу как бы переключиться на что-то другое. Пока, э, есть риск, что, ну, в конечном итоге прилетит ко мне, если я
Speaker A
не понимаю в этой штуке. Вот. Слушай, ну ты же высвобождаешь своё время, когда ты работаешь с агентами, и они тебе экономят время, и ты ему даёшь выполнить какую-то задачу, проверяя за ним работу. просто этот уровень делегирования, да, то есть мы сейчас на
Speaker A
самом, во многих случаях мы на самом низком уровне делегирования, когда у нас много точек контроля, но со временем по по мере того, как растёт наш харнес, как растёт этот, мы отдаём ему всё больше и больше куски ответственности. Разве нет?
Speaker A
В рамках твоей работы. Не в рамках твоей работы, потому что, смотри, это очень большая разница, которую, ну, разработчикам, может быть, чуть сложнее понять, потому что они привыкли, вот я разработчик, я пишу код, когда ты на уровне другом и у тебя есть зоны, в
Speaker A
которых ты, допустим, вообще ничего не понимаешь. То есть напу, допустим, финансовый учёт, ну, то есть ноль понимания, да, то там, ну, ты понимаешь, да, это совершенно другая работа. Я, в принципе, не могу этим заниматься никак.
Speaker A
И поэтому там вот такое делегирование - это единственный способ масштабироваться, иначе я, ну, останусь всегда маленьким, я никогда не смогу расти. А когда, например, я сам, вот, например, я пишу тексты, я снимаю видео, я там пишу курсы и так далее, мне агенты
Speaker A
делают действительно очень много и позволяют делать больше. Но это всё моя компетенция и это моя ответственность. И я не называю делегированием. просто как бы, ну, такие экзоскелет, который делает меня сильнее. Вот.
Speaker A
Угу. Ну, это просто к слову, что вот всё-таки вот мы к чему это всё ведём, да? Что, грубо говоря появляются какие-то у программиста это, наверное, можно связать с тем, что, ну, появляется что-то совершенно новое, с чем он не
Speaker A
взаимодействовал. И можем ли мы жить в режиме, когда ему и не придётся на этот уровень опускаться? Вот я что-нибудь с сертификатами, например, вот появляется какая-нибудь штука, надо с госуслугами как-то интегрироваться так, чтобы там вот, понимаешь, там безопасность, передача данных, тра-та-та-та-та и
Speaker A
какие-то там технологии, с которыми ты раньше не сталкивался, связанные с генерацией там само каких-нибудь мега сертификатов и, ну, понимаешь, да, вот эта вот вся история. Может, ты так примерно там что-то что-то там происходит, примерно что-то там работает, и примерно он мне обещал, что
Speaker A
всё будет хорошо. Можешь ли ты не опускаться на уровень понимания деталей? Мм. М, я не уверен, мы просто работаем со СМО где-то, да, местами и там обычная разработка, на самом деле.
Speaker A
То есть там нет, ну, просто пример, наверное, этот, то есть верхнеуровневый ты ответственность делаешь, архитектуру ты валидируешь, но вот там условно опуска до уровня переменных и функций класса уже можно не опускаться, да? То есть зачастую, то есть и зависит от
Speaker A
того, как агнес тебе это позволяет это делегировать или нет, да, на каких точках ты сделаешь и какие, как ты продумывал тест-стратегию, вот этот файлик, да, как ты это будешь проверять и валидировать.
Speaker A
Ну, если синьор, который с этим никогда не работал. Кстати, вот классный пример. У тебя был чувак, который занимался мобильной разработкой, и ты говоришь: "А вот теперь разрабатывай сайт". Это вот будет очень похоже на то, что я сейчас говорю. Грубо говоря, он же разработчик,
Speaker A
он же всё понимает, ему не надо идти на нижний уровень. Вот он сможет, грубо говоря, делать. То есть это примерно то же самое, если как бы джун, ну, джун в какой-то момент приходит, да, как он с джуна станет синьором. Вот то же самое
Speaker A
приходит у тебя там мобильный разработчик, он делает сайт, и он не понимает, например, клиент серверную архитектуру.
Speaker A
Вот мне кажется, чуть-чуть как раз в обратную сторону интереснее будет, когда веб-разработчик в мобилку пойдёт, мне кажется, ну, клиент серверную архитектуру, мобильщик тоже понимает, потому что чаще всего мобилка - это, извини, я до того, что, [смех] ну, к
Speaker A
примеру, в мобилке там много каких-то своих нюансов есть действительно тоже, а, с которыми нужно будет знакомиться.
Speaker A
То есть, мне кажется, синьор, когда он придёт в новую штуку, ему нужно некоторое время на погружение в эту специфику, область, прежде чем он действительно сможет принять на себя возможность валидировать результаты ответа. Второе - это будет уровень, он он сильно понизит уровень делегирования.
Speaker A
Он сделает его максимально дотошным поначалу для того, чтобы впитать эти знания. Он будет задавать много уточняющих вопросов, когда то есть ему агент выдаст какую-то вот я тебе сделал там какой-то компонент, условно, он скажет: "А почему так?" А как? А где
Speaker A
какие варианты ты принял? В том числе вот запускай вот некоторый такой цикл обучения самого себя, а на примере каких-то конкретных реализаций. То есть инженер, который там уже прошёл так много лет, да, то есть на других каких-то сеньор, да, знаете, когда он
Speaker A
придёт в новую отрасль, ему нужно ознакомиться с новой спецификой, с новым доменной зоной, с новыми техническими правилами. А и итеративно, да, то есть от агента он не станет писать под руками, он станет писать код агентом, но он будет очень много задавать вопросов
Speaker A
для того, чтобы впитать в себя как минимум архитектурные границы, понять, на каких границах он будет валидировать и проверять эту работу. И постепенно по мере роста его скила именно в этойзоне он сможет повышать этот уровень. Ну, если пускай я согласен с тобой, что вот
Speaker A
уровень слово делегирование может быть не до конца это подходит. Но вот из какого-нибудь делегирование со звёздочкой бы, да, в идеале это бы лучше бы выражало то, что происходит у нас с агентом. Ну вот всё-таки для меня пока что это близко слово делегирование,
Speaker A
потому что там есть уровни делегирования, вот они вот очень понятные. Это то, что при работе с агентами в зависимости от твоего твоей компетенции, неопределённости уровня дотошности, ты повышаешь или понижаешь уровень делегирования. Мне это очень близкое вот такое сравнение.
Speaker A
Я понял. Кстати, интересно. У меня при том, что я обучаю людей, до сих пор нет ответа на этот вопрос, но лично мой экспириенс вот последний, потому что мы начали параллельно делать проекты, например, там я никогда на Гошке не
Speaker A
писал именно, знаешь, больше, чем какие-то скрипты. То есть скрипты писал, проекты никогда. И вот у меня новый стек полный, да, там довольно большой проект, он гошный, и я его весь генерирую. Я просто в какой-то момент понял, что это
Speaker A
в чистом виде вайп-кодинг, даже несмотря на то, что я смотрю на код, и мне не хватает вот этого ручками пощупать. И у меня прямо запланирован на там типа конец года, ближе к праздникам, что я прямо сяду и должен потратить какое-то
Speaker A
время ручками для того, чтобы, знаешь, вот это вот ощущение на кончиков пальцев. Я думаю, что я хорошо пойму, как бы когда будет достаточно, но вот как ты рассказываешь, что только на уровне задавания вопросов, я уже вижу, что у меня, по крайней мере, это не
Speaker A
работает. Вот для момен места, в котором появляется много сложных деталей. Ну, потому что в го, когда начинаются у тебя там рутина и так далее, да, если ты не понимаешь, то ты совсем не понимаешь. А насколько он адекватно вообще пилит и в
Speaker A
ту сторону идёт, вопрос вообще большой. Поэтому я такое понимаю, либо я полностью вайпкожу и доверяю всему, что тут происходит, либо я всё-таки должен сесть и поработать немножко ручками. Ну вот это, по крайней мере, моё последнее открытие вот в этом отношении.
Speaker A
Не, я с тобой соглашусь. Я с тобой соглашусь, что, ну, то есть по ощущениям там, теряю ли я какие-то компетенции, возможно, они у меня немножко условно выветриваются вот в моём стеке, да, на котором я пишу. Я вот я сейчас на этом
Speaker A
стеке валидирую проекты, и я чувствую, что я где-то могу ещё дать жару акенту и нормально вот отвалидировать, направить и сказать, что ты вообще фигню делаешь.
Speaker A
То есть я понимаю, что здесь у меня может, если есть какая-то утичка, то она очень слабая и не скажу, что она прямо есть. Я понимаю, что да, я как бы, если я сяду сейчас писать код, я его буду
Speaker A
писать медленно с точки зрения агента и медленнее, чем я раньше руками писал. То есть мне нужно будет некоторое время вот эти ко на кончиках пальцах это вспомнить, но структурно, архитектурно продумать любой компонент, любой архитектурный модуль, модель данных в базе данных, это
Speaker A
это я всё могу, это всё это всё не проблема. Но когда мне приходится писать на тех языках, которые я не знаю или плохо знаю, действительно я понимаю, что там вот немножко спускаясь на уровень ваймкодинга и теряешь контакт, да, нужно через себя пропускать
Speaker A
некоторые вещи, чтобы ты лучше мог валидировать эти решения архитектурные и так далее. Я здесь с тобой согласен полностью. Это вот когда ты входишь в новую зону, как в Твиттере недавно писали, что системный дизайн - это новый язык программирования. Да,
Speaker A
да, да, да, да, абсолютно. То есть это прямо одна из наиболее востребованных компетенций. Мы вот для себя сейчас как раз понимая, что нам нужно, ну, пускай мы не говорим о том, что вот нам надо взять всех сделать флстек инженерами
Speaker A
сейчас, да, то есть утопия, да, мне кажется, сразу так амбициозно заявлять, но мы понимаем, что количество этих самых full cycle инженеров у нас нужно будет больше, потому что, в принципе, и сама агентская разработка этого требует, и эта эффективность выше. И мы сейчас
Speaker A
как раз думаем о проработке вот этой матрицы компетенции внутри компании, как должен выглядеть этот инженер, какими навыками он должен обладать. И там действительно системный дизайн будет превуалировать для того, чтобы действительно мы могли переучивать сейчас ребят там фронтов в вков, бэков
Speaker A
фронтов да бков, да, да, туда и сюда это всё делать. и каких-то где-то и QA, которые захотят стать фцикл инженерами, им стать на мой на мой взгляд, им x2 сложнее во многом. Поэтому дадим возможность переучиваться всем, но вот эти критерии нам надо прорабатывать,
Speaker A
и системный дизайн там будет один из основных. Не, не могу не обратить внимания, что есть Стой, не ту руку поднял, что есть место, куда можно идти учиться, [смех] да, и мы этим добром занимаемся. Какие следующие шаги, скажи, пожалуйста? Вот
Speaker A
вы дошли до этой точки, у вас Spect Driven Development, вы даже опережаете Open Spect, с которым вы работаете. Что вот что дальше? Что теперь?
Speaker A
Бклога, куча гипотез, да? То есть, ну, очень много всяких точек улучшения Харнеса, да? То есть нужно идти в сторону автономности, продолжительности циклов, которые у нас есть. То есть нужно, э, идти в сторону того, чтобы как можно меньше было вот этих интерактивных
Speaker A
сессий разработчиков, чтобы действительно разработчик мог спокойнее передать, э, и меньше дёргаться итеративно. Для этого нужно улучшать качество Харнеса, причём оно проектно зависимо, правильно передавать контекст и детали проекты архитектуры в ограничения какие-то ставить агента, чтобы он не уходил ни вправо, ни влево.
Speaker A
У нас там всё больше и больше появляется различных хуков, которые запрещают агенту что-то делать прямо на уровне отлова его каких-то типовых, на наш взгляд, галлюцинаций. То есть точек роста в харнесе их прямо очень много.
Speaker A
Нужно зацикливать этот харнес, в том числе замыкать петлю обратной связи, собирая ещё сквозную штуку. У нас же ещё ребята работают с разными моделями, с разными. Ну, то есть у нас есть там два-три разрешённых провайдера моделей, которые мы разрешаем. И в зависимости от
Speaker A
моделей, в зависимости от провайдера моделей, в зависимости моделей внутри него, у нас там получается в том числе разные результаты. К примеру, вот там один из клуков, который мы сейчас обсуждали на последней неделе, что, к примеру, нельзя запускать прос или
Speaker A
Explore на модели младше, чем третий уровень. Да, там Опус и Луна, по-моему, да? У Луна Сол чапити Сол на третий уровень. Я, извините, я не в кодексе не работаю, я в клоде работаю, поэтому ошибиться.
Speaker A
Ну, потому что солнце оно типа самое большое да да. О'кей. Вот, соответственно, то есть, к примеру, проектирование только на старших моделей. Дальше реализацию ты можешь получить младшим моделям. Но просто иногда мы сейчас там словили иногда в SDD проблематику, что кто-то
Speaker A
взял и Санета сгенеровал спеку, а Son, короче, средние модели, они чаще выпрыгивают типа: "А, всё готово". Да, то есть и старшей модели там получше больше перепроверяют. Есть такое, да.
Speaker A
Да. Вот поэтому проектирование лучше им, да, давать. Просто хотел сказать, что мы сначала так пытались сделать, а потом, когда стали просто покупать клод, у некоторых по двое премиум аккаунтов, когда по 100 долларов два, да, но вот два стодолларовых аккаунта уже хватает
Speaker A
для того, чтобы всегда пользоваться только опусом. И поэтому мы как бы такие: "Блин, нам не жалко, давай". И мы в итоге вообще перестали, в принципе, кроме опуса, чем-то пользоваться при любом раскладе.
Speaker A
Да, у нас многие тоже так делают, но иногда это ещё санет ещё и некоторая скорость. Ну, по большей части, да, действительно так. В любом случае мы захотели это прям системно ограничить для того, чтобы прям даже не допускать такие возможности. И там вот таких вот
Speaker A
маленьких точек ограничений по Харнуса допилу каких-то различных скилов. Их очень много. Из того, что хотим вот таких больших вещей - это делаем свой проект по Ивалу для того, чтобы внесение скилов и изменения Харнеса определялось не на вкус, да, вроде норм стало лучше
Speaker A
или не хуже. А чтобы мы это цифрами всё подтверждали, большое направление - это по аналитике сессий. Мы собираем все эти аналитики сессий с разных моделей, агрегируем для того, чтобы анализировать различные аспекты, начиная от где агенты тупят, ошибаются и вызывают лишние тулы
Speaker A
вместо того или там в лишние циклы, запуская анализ и достигая результата, заканчивая. А тем, что понимать, как выглядит цикл работы современного разработчика, да, где он там, у него получается в течение рабочего дня, допустим, запускать много сессий, где нет, да? То есть потому что мы, ну,
Speaker A
действительно приходим вот такую, нам нужно исследовать то, как строится работа современных разработчиков, потому что, ну, она сильно изменилась по сравнению с тем, что было. И каких-то вот там чётких, хороших исследований, как это было, как это должно строиться, оно нет. Мы сейчас действительно на в
Speaker A
некотором фронтире находимся все вместе на рынке, и нам нужно понимать, как это работает, исследовать по границы где-то, в том числе, где там человек ментально может уставать в течение дня с пятью сессиями работать, например, и эффективность падает. И вот эти вот
Speaker A
метрики собирать, это очень интересно. Мы вот этим тоже всем начинаем заниматься. По SDшке у меня один из такой внутренних вопросов: а не нужен ли нам третий слой? Не нужно ли нам третьим слоем сделать ещё LLM вики помимо вот
Speaker A
этих двух уровней ченджей и спецификаций для того чтобы это чуть такой human friendly чуть больше документацию сделать и выделяет туда некоторые моменты потому что спецификация в онспеке да и в спектите она довольно-таки жёсткая формальная а нужно ещё некоторый другой род документации
Speaker A
вот у меня вот есть пока что мысль с которой мы коллеги обсуждаем пока что спорим где-то места Стами, не нужно ли нам построить третий слой, когда из Чинджа будет не только архив спецификации делаться, архив мастерспека вот это делаться, но ещё и собираться на
Speaker A
третий уровня в виде lм wiки. Причём сказать, что LM Wiки могла бы заменить мастерспеку, ни в коем случае, потому что мастерспека, она даёт вот эту жёсткость, которая сейчас ещё довольно-таки сильно актуальна и в виде набора требований, которые мерца и
Speaker A
лучшая конфликция. Я понимаю, что лвики на конфликты, на непротиворечивость проверить будет сильно сложнее, когда она разрастётся до такого масштаба. Она она мягкая, скажем так, она более гибкая. И, соответственно, вот этой жёсткости, которую даёт опцпек, она не даст. Ну, в общем, как-то так, наверное,
Speaker A
по набор гипотез скилов по аналитикам, по QA м очень много. Ну, а дальше нам нужно всё потихонечку к схлопыванию в в идеале универсальных инженеров. И мы понимаем, что вот это сокращение ролей, оно даст довольно-таки сильное усиление.
Speaker A
[музыка] Один из таких вот небольших инсайтов, э, это мы заметили, что блокеров стало больше. вроде работаем с лмками, но каждый день начало в какой-то момент вот там фронт от бэка зависит, бк от фронта, и таких вот кейсов много. И вот,
Speaker A
собственно, если на график нанести некоторую работу, я потом картинку скину, мы даже немножко визуализировали, условно это когда у тебя условно вот были длинные там условно работа фронта, работа БКА, и всегда у тебя есть маленькая коммуникация между фронтом и
Speaker A
Бэком, там согласовать контракт, там один отного другого зависит и так далее. И вот у нас промежутки работы уменьшились и соответственно точек коммуникации их стало больше. И, соответственно, у тебя количество вот этих коммуникаций между специалистами их стало больше. Это проблема именно вот
Speaker A
этого подхода, когда мы действительно слишком много нарезали на эти узкие роли. И когда мы будем схлопывать это всё-таки в единой роли, вот это сам с собой ты коммуницировать будешь намного эффективнее. У тебя количество блокеров сильно уменьшается. Поэтому один, одна
Speaker A
из таких наибольших, наверное, значимых точек роста эффективности, на мой взгляд, это действительно схлопывание ролей для того, чтобы вот этих количества трений стало меньше, потому что сами промежутки работы стали меньше благодаря агентам.
Speaker A
Как-то так. И по Харнесу, наверное, такую вещь хочется сказать. Очень много, из-за скорости развития инструментов очень много быстро становится овенженирингом. Да, я имею в виду, что, ну, ты понимаешь, да, когда у тебя вот ты клодом пользуешься, ты просто офигеваешь, как
Speaker A
каждый месяц он настолько кардинально меняет свою работу, что очень большое количество всего, что ты напилил до этого, нужно просто выкидывать, потому что он даже мешать начинает. И в итоге вот эта команда такая инфраструктурная, которая занимается постоянным контролем, отслеживанием и улучшением, становится
Speaker A
одной из главных, наверное, да, в компаниях. В принципе, Харнес в компании становится, по сути, ядром. Это это самая главная часть, которая у вас есть.
Speaker A
И это почему очень важны валы вам. Да. То есть потому что это, ну, типа ваша корфункциональность это корфункциональность вашего бизнеса практически становится, да, у разработке. Её не покрывать автотестами - это как бы очень нерационально. И в том числе мы должны поднимать деградацию
Speaker A
своего харнеса при выходе новой модели. То есть новая модель, мы должны взять, посмотреть, сравнить с Харнесом и провести набор экспериментов. А точно ли нам вот эти блоки хардеса нужны? И возможно их нужно действительно выпилить и посмотреть. Возможно они становятся
Speaker A
добиваются лучшего эффект. Поэтому здесь с тобой полностью согласен. Кстати, нативная интеграция. Мы с Ваней тут фоном прорабатываем курс, в котором, собственно, ивалы будут одной из таких важных частей, где мы будем про это рассказывать, этому обучать. Так что следите за аносами. Знаешь, ещё какую
Speaker A
штуку хотел сказать? Знаешь, когда у тебя всё это развивается, у тебя постоянно какие-то новые идеи в голову приходят, которые раньше бы не пришли. У меня вот такая идея прямо на днях пришла. Да, он стал генерить много тестов, но у нас было написано много
Speaker A
тестов уже до этого, там тысячи, да, допустим, в проекте. И я понимаю, что именование этих тестов, оно не идеальное, прямо скажем. Ну, потому что когда ты сам пишешь, оно такое себе. А ведь как он понимает, что какие кейсы
Speaker A
вообще есть, покрыты, нет, реверсит, он же не из кода это делает, потому что если так много тестов, он делает из-за названий. Я вдруг понял, что как будто бы, например, у нас появляется одна из таких задач, причём, казалось бы, она
Speaker A
такая простая достаточно, да, что попросить его прямо как отдельной большой сессии: "Проанализируй все тесты, которые есть, и напиши адекватное название теста". Соответственно, что в будущем позволит ему гораздо быстрее отслеживать, а какие кейсы были реализованы, нет, без того, чтобы
Speaker A
изучать тело теста. И вот чем дальше, тем больше я таких вот штучек начинаю видеть, которые раньше в голову как бы не приходили. Я такой: "Хм, прикольно".
Speaker A
Потому что он всё это начинает использовать, потому что вот эти грепы туда-сюда, они дают ему очень много возможностей.
Speaker A
Это, кстати, тоже одна из штук, которую мы решали. В том числе даже формирование вот этих доменов и капалити в Оенспеке, он фантазирует, и он их называет действительно по-разному. И один из элемент жёсткости, который мы добавляли - это мы делали справочник доменов и
Speaker A
капалити, которые есть, чтобы он не фантазировал и не отклонялся и чтобы он оперировал только это. То есть по факту мы приходим к классическому, да, вот этот DDD как вот справочник терминов вот этих всех сущностей, которые у нас должен быть.
Speaker A
Единый язык, да. Да, да. У B lang. Да. Это я, кстати, забыл сказать про это, да, что даже у тебя в маленьком проекте, ну, ну, относительно, да, у тебя там этих папочек миллиард, и если он создаёт что-то новое, ты за этим не отследил. У
Speaker A
тебя может быть такое типа на часть заехала немножко сюда, часть заехала немножко сюда, фронтбк какая-нибудь сбоку фигня, у тебя миллиард папочек в какой-то момент это просто, ну, никто не понимать, ни разбирать не будет, да.
Speaker A
Поэтому надо это тоже сводить. Это я вот показал, как раз делал проект делался на предыдущем конспек, а сейчас он как раз двухуровневый, позволяет это в доме объединить ещё, соответственно, это лучше контролировать. И, собственно, внутренняя задача - это у меня взять это
Speaker A
отрефакторить в новые домины для того, чтобы это теперь чуть лучше работало. Угу. За, забавно, что мат, я вот просто, ну, как бы комментарии не вставлял.
Speaker A
Очень многие вещи мат покок, они двигаются в похожие штуки. Например, у них там есть такое понятие сейчас контекст Map. То есть ты прямо выбираешь: "Я хочу типа у меня проект, когда один контекст или проект, когда много контекстов". Там это опция, да? И
Speaker A
ты выбираешь, если несколько, он создаёт специальный файлик, который называется Map, который как раз определяет эти контексты, и как бы оно погнало, потому что, ну, все, короче, наталкиваются на какие-то проблемы, потому что по дефолту эта штука создаёт слишком много всего, и
Speaker A
оно поначалу как бы весело и здорово, да, в какой-то момент просто неуправляемой может легко стать. И как будто, кстати, может быть, мы на это ещё наткнёмся, когда у тебя будут гигантские объёмы этих данных и никто не будет понимать, что вообще происходит. Дадада.
Speaker A
Да, всё про тебе не кажется, что уже должен быть скилл, который называется Revюw и компакт, который как раз смотрит их, объединяет и убирает лишнее. Я уже думал последнее время о том, что такая штука, Слушай, у Помо я вот недавно смотрел
Speaker A
Мэтпако, у него, по-моему, прямо даже что-то такое есть, когда в конце архитектуру он берёт и как раз компарнит, по-моему, что-то такое делает, как будто новое. Точно. Я видел, что с уже хотят такое добавить. Да, я вот прямо в стате видел, как будто бы
Speaker A
это даже есть у него уже, по-моему. Угу. Короче, появляются скилы теперь. Это то, чтобы всё чистить, да, в обратную сторону.
Speaker A
Да-дада. Всё. Так, Вань, тебе большое спасибо, что ты пришёл, поделился своей историей. Ребят, если вам понравилось, поставьте лайк.
Speaker A
Если не понравилось, поставьте дизлайк. Напишите обязательно используете ли вы у себя, не используете. Может быть, вы вообще против AI, хотя, мне кажется, сейчас уже это редко встречается, да. Что вы обо всём этом думаете? будете ли вы в эту
Speaker A
сторону идти? С какими сложностями сталкиваетесь сами. Всем спасибо. Пока, до новых встреч. Пока. [музыка] เฮ [музыка]
Topics:Spec-Driven DevelopmentSDDвнедрение SDDworkflowразработка ПОаналитикатестированиеИТ-компаниямасштабирование процессовводопадная модель
