Я правильно понимаю, что при параллельной разработке в одном проекте файл "progress.md" будет содержать разную информацию и при мердже в мастер будут постоянные конфликты?
Я так же не доверяю агентам выполнить всё и сразу, они почти как прокачанный джун - такого могут натворить. За ними надо следить и направлять в нужную сторону.
Я каждую команду запускаю самостоятельно. Агенты работают на втором мониторе и я постоянно вижу, что они делают. В это время могу ревьюить описание следующей задачи. Если что-то идет не так, торможу и принимаю решение: удалить и начать заново или самому закончить.
И вам спасибо за совет, буду изучать. Пока у меня нет успешных кейсов по параллельному запуску. Очень быстро такой подход выжирает лимиты и ты остаешься с 2-мя недоделанными задачами. Но все меняется и лимиты растут и модели становятся более умные.
Тут нет пушки и птичек. Это учебный проект для апробации идеи.
Я немного параноик, и не доверяю агентам :))) Лучше я всё своими глазками просмотрю.
А еще здесь проявляется другая проблема "Владение кодом". Ревью частично закрывает это, а без него - это код, который ты купил и поддерживать вряд ли сможешь. Его проще по новой спеке заново сгенерить.
Спасибо за ссылку, к сожалению, не нашел такой подход раньше.Буду изучать в деталях. Но я не изобретал что-то новое. Я в статье старался сказать, что надо брать текущие процессы в компании и под них затачивать своих агентов. Это просто пример, как можно сделать, не более.
Жаль, удобный инструмент. Один контейнер, который умеет и статику отдавать и пыху запускать. Но есть и минусы, например, я не нашел как там внятно делать рерайты.
Вы вынесли конфигурацию каждого Context в папку Resources/Config, а почему не в Presentation или Infrastructure?
Конфиги - это же часть фремворка, в своих проектах, всё что связано с феймворокм, я выношу в слой Presentation (как бы Порты взаимодействия). Но в целом, это можно отнести и к Инфраструктуре.
А есть вариант как "разрулить" 2 типа логов и отправлять их в разные места? Например, мы пишем в stdout контейнера json-данные для OpenTelemetry, а в stderr json-данные для Loki.
У меня нет цели вас переубедить, со временем, понимание само придет. Но размещая всю логику в контроллере, вы заставляете его знать больше чем требует его зона ответственности.
Хм, для меня структурирование кода только уменьшает нагрузку при чтении нового кода. А если эта структура идет из проекта в проект, из модуля в модуль, то всё упрощается в разы. Согласен, не все готовы работать по определенным стандартам - это разрыв шаблона, это ограничение творческой жилки и тп. Я сам через это проходил, но опыт на разных проектах, чтение умных статей и просмотр выступлений помогли сформировать понимание, что стандартизация - это хорошо.
Оверинжиниринг будет ярко выражен на маленьких и простых проектах. В остальных случаях этот подход будет оправдан. Я писал в статье:Нет «серебряной пули», есть только путь в попытке найти баланс между трудозатратами, качеством и скоростью. И в каждому случае - он свой. И там же привел пару правил, которые для себя выработал для определения сложности.
Когда-то моя команда создавала несколько микросервисов, и там мы точно не задумывались над структурой папок. Там на один сервис было не более 20 файлов. Но проекту это не помогло, его закрыли. В сроки и бюджет не уложились, и скорость разработки тут была совершенно не причем. Часто заказчик хочет всё и вчера, но если подойти с умом, то сначала надо сделать MVP, который запустить на рынок и начать зарабатывать, и параллельно с этим допиливать новый функционал. И это всё можно делать с первых строк кода хорошо. Естественно не надо сразу проектировать коня в вакууме, делаем как умеем и только то что надо сейчас + готовим точки для расширения на будущее.
Хелсчек я привел, как пример, своей логики рассуждения. Если у меня сервис не планирует развиваться, например, учет прохода пациентов в клинику, то можно его сделать быстро и по простому. НО если выбран определенный подход, то он должен быть везде по всему коду и к этим правилам должны быть тесты. В противном случае будет хаос и через год-два, даже автор кода будет с трудом там разбираться.
Это уже получается OpenSpec :))
Я правильно понимаю, что при параллельной разработке в одном проекте файл "
progress.md" будет содержать разную информацию и при мердже в мастер будут постоянные конфликты?Поправьте пож форматирование кода, неудобно читать
Поделитесь пож. ссылкой на github с реализацией?
Я так же не доверяю агентам выполнить всё и сразу, они почти как прокачанный джун - такого могут натворить. За ними надо следить и направлять в нужную сторону.
Я каждую команду запускаю самостоятельно. Агенты работают на втором мониторе и я постоянно вижу, что они делают. В это время могу ревьюить описание следующей задачи.
Если что-то идет не так, торможу и принимаю решение: удалить и начать заново или самому закончить.
И вам спасибо за совет, буду изучать.
Пока у меня нет успешных кейсов по параллельному запуску. Очень быстро такой подход выжирает лимиты и ты остаешься с 2-мя недоделанными задачами.
Но все меняется и лимиты растут и модели становятся более умные.
Линтеры есть на каждом этапе.
С массовыми правками я сталкивался очень давно и лечил это более мелкой декомпозицией эпиков и задач. Так же помогает модульность.
Я не доверяю агенту, я за ним всегда слежу и проверяю, что сделано. Это вторая причина, почему я мелко дроблю задачи - делать ревью проще.
Поживем - увидим
Везде нужен баланс
https://docs.bmad-method.org/reference/workflow-map/ - выглядит прям очень круто.
Тут нет пушки и птичек. Это учебный проект для апробации идеи.
Я немного параноик, и не доверяю агентам :)))
Лучше я всё своими глазками просмотрю.
А еще здесь проявляется другая проблема "Владение кодом".
Ревью частично закрывает это, а без него - это код, который ты купил и поддерживать вряд ли сможешь. Его проще по новой спеке заново сгенерить.
Частично Code Review закрывается на "Шаге 2. Перепроверка" в https://github.com/vendelev/MyDrevo/blob/master/.ai/commands/ra-php-implementation.md
Но можно и отдельного агента для этой цели создать и добавить ему какие-то доп проверки.
Спасибо за ссылку, к сожалению, не нашел такой подход раньше.Буду изучать в деталях.
Но я не изобретал что-то новое. Я в статье старался сказать, что надо брать текущие процессы в компании и под них затачивать своих агентов.
Это просто пример, как можно сделать, не более.
Не стоит "заморачиваться" и менять/усложнять базовые правила выбранного фреймворка:
Когда у вас простой проект (кол-во контроллеров и моделей, условно!, 8-10 штук),
Когда проект не собирается развиваться и усложняться (сайт-визитка, лендинг, блог и тп).
А следует задуматься над архитектура, когда проект:
Имеет сложную логику (содержит десятки модулей),
Планируется долгосрочная поддержка и развитие функционала.
Если бизнесу пофиг на будущее, то можно делать как побыстрее, срубить бабло и уволиться. щутка :)))
Жаль, удобный инструмент.
Один контейнер, который умеет и статику отдавать и пыху запускать.
Но есть и минусы, например, я не нашел как там внятно делать рерайты.
Вы вынесли конфигурацию каждого Context в папку Resources/Config, а почему не в Presentation или Infrastructure?
Конфиги - это же часть фремворка, в своих проектах, всё что связано с феймворокм, я выношу в слой Presentation (как бы Порты взаимодействия).
Но в целом, это можно отнести и к Инфраструктуре.
А есть вариант как "разрулить" 2 типа логов и отправлять их в разные места? Например, мы пишем в stdout контейнера json-данные для OpenTelemetry, а в stderr json-данные для Loki.
Очень интересен ваш опыт.
Если не секрет: у вас сколько человек в команде разработки и какие приняты правила по организации кода?
У меня нет цели вас переубедить, со временем, понимание само придет. Но размещая всю логику в контроллере, вы заставляете его знать больше чем требует его зона ответственности.
Всё зависит от ваших знаний и умений.
Хм, для меня структурирование кода только уменьшает нагрузку при чтении нового кода. А если эта структура идет из проекта в проект, из модуля в модуль, то всё упрощается в разы.
Согласен, не все готовы работать по определенным стандартам - это разрыв шаблона, это ограничение творческой жилки и тп. Я сам через это проходил, но опыт на разных проектах, чтение умных статей и просмотр выступлений помогли сформировать понимание, что стандартизация - это хорошо.
Оверинжиниринг будет ярко выражен на маленьких и простых проектах. В остальных случаях этот подход будет оправдан. Я писал в статье:
Нет «серебряной пули», есть только путь в попытке найти баланс между трудозатратами, качеством и скоростью. И в каждому случае - он свой.И там же привел пару правил, которые для себя выработал для определения сложности.Когда-то моя команда создавала несколько микросервисов, и там мы точно не задумывались над структурой папок. Там на один сервис было не более 20 файлов. Но проекту это не помогло, его закрыли. В сроки и бюджет не уложились, и скорость разработки тут была совершенно не причем.
Часто заказчик хочет всё и вчера, но если подойти с умом, то сначала надо сделать MVP, который запустить на рынок и начать зарабатывать, и параллельно с этим допиливать новый функционал. И это всё можно делать с первых строк кода хорошо.
Естественно не надо сразу проектировать коня в вакууме, делаем как умеем и только то что надо сейчас + готовим точки для расширения на будущее.
Хелсчек я привел, как пример, своей логики рассуждения. Если у меня сервис не планирует развиваться, например, учет прохода пациентов в клинику, то можно его сделать быстро и по простому.
НО если выбран определенный подход, то он должен быть везде по всему коду и к этим правилам должны быть тесты. В противном случае будет хаос и через год-два, даже автор кода будет с трудом там разбираться.