Даст возможность создавать локальный коллектор и не держать его в контейнере со стейтом

Проблема не в этом

он тебе нужен только в рамках конкретной транзакции же

А вот в этом и это уродски выглядит transaction(){ action1->setCollector(collector) action1(); action1->setCollector(collector) action2(); } collector->release()

С другой стороны не прям критикал уродски, но всё же

зачем сеттить? если можно как зависимость в экшон прокинуть фабрику и внутри его создать?

зачем сеттить? если можно как зависимость в экшон прокинуть фабрику и внутри его создать?

нужен единый коллектор, в двух экшенах

зочем?

зочем?

Чтобы собрать ивенты. Это примерно как visitor

сложно крч

А вот в этом и это уродски выглядит transaction(){ action1->setCollector(collector) action1(); action1->setCollector(collector) action2(); } collector->release()

я бы скорее аргументами функции передавал, потому что setCollector - это точно такое же стейтфул, просто раньше у вас что-то хранилось в коллекторе, теперь в экшнах

я бы скорее аргументами функции передавал, потому что setCollector - это точно такое же стейтфул, просто раньше у вас что-то хранилось в коллекторе, теперь в экшнах

Кстати да, согласен, шило на мыло

не настаиваю, но аргумент метода - железобетонно явно, просто и читаемо

и тестируемо, если взбредет в голову

только передавал бы я не сам коллектор, а некую коллекцию, что он дает. по типу, допустим, Stopwatch. там есть метод startTimer (могу в названиях путаться), он возвращает новый объект, и измерения добавляются к нему

то есть не весь коллектор, а EventCollection $collection = $collector->createCollection()

и на этом $collection->addItem(....) в вашем экшне

то есть чтобы не менять шаред-стейт самого коллектора из нескольких гипотетических потоков

а работать строго со своей локальной копией данных, которой 100% владеет текущий код

Интересный вариант, только тогда в самом коллекторе ничего не остается. Возможно если он чуть сложнее, чем просто коллекция - тогда имеет смысл

то есть чтобы не менять шаред-стейт самого коллектора из нескольких гипотетических потоков

Ну это если коллектор в DI хранится

Интересный вариант, только тогда в самом коллекторе ничего не остается. Возможно если он чуть сложнее, чем просто коллекция - тогда имеет смысл

так, а потом обратно эту подготовленную "коллекцию" в коллектор передать типа $collector->finalize($collection)

и пусть он ее там куда-то шлёт или что он должен делать. при некоторой ловкости рук, это можно отложить в fastcgi_finish_request допустим

Всем привет! Подскажите, как вы работаете с вложенными ветками - например, есть ветка A, я из нее наследую ветку B, из которой наследую ветку C. Это все одна большая задача, которую раздробили на более мелкие и по отдельности. И вот на каком-то этапе, например, отдаю задачу С на тест и нужно в эту ветку влить свежий master. Чтобы это сделать, мне нужно влить master в А, А в B, а В в С. Может быть можно как-то это в один клик делать в шторме или еще как-то?

Всем привет! Подскажите, как вы работаете с вложенными ветками - например, есть ветка A, я из нее наследую ветку B, из которой наследую ветку C. Это все одна большая задача, которую раздробили на более мелкие и по отдельности. И вот на каком-то этапе, например, отдаю задачу С на тест и нужно в эту ветку влить свежий master. Чтобы это сделать, мне нужно влить master в А, А в B, а В в С. Может быть можно как-то это в один клик делать в шторме или еще как-то?

Зачем наследовать два раза? Можно мерж использовать

Всем привет! Подскажите, как вы работаете с вложенными ветками - например, есть ветка A, я из нее наследую ветку B, из которой наследую ветку C. Это все одна большая задача, которую раздробили на более мелкие и по отдельности. И вот на каком-то этапе, например, отдаю задачу С на тест и нужно в эту ветку влить свежий master. Чтобы это сделать, мне нужно влить master в А, А в B, а В в С. Может быть можно как-то это в один клик делать в шторме или еще как-то?

я бы советовал таким не заниматься, чай не в ядро линукса коммитите. не заниматься как раз по причине вышеозвученных проблем - головняк с мержами, высокая вероятность человеческой ошибки. у меня практически сотня разработчиков, десятки продуктов, но никто и никогда подобным не занимается, может и вам не надо?

я бы советовал таким не заниматься, чай не в ядро линукса коммитите. не заниматься как раз по причине вышеозвученных проблем - головняк с мержами, высокая вероятность человеческой ошибки. у меня практически сотня разработчиков, десятки продуктов, но никто и никогда подобным не занимается, может и вам не надо?

Что значит "не заниматься"? Как вы предлагаете вести разработку, когда есть 5 задач, зависящих одна от другой?

нормально их организовывать?

нормально - это все в одну засунуть?

ну вполне, да

мои доводы простые: мне за 15 лет в программировании в совершенно разных компаниях (от гигантов до стартапов) всегда удавалось избегать подобных приключений, и вам, наверное, при желании получится избежать

ну у нас процесс так построен: большая задача дробится на подзадачи, которые проще оценивать, отслеживать ее движение и параллельно отдавать разным разработчикам.

у вас правильный флоу, если мы гит используем как задумано - децентрализованно, с несколькими ревьюверами каждый на своём уровне. ровно как в ядре линукса. в мелкой веб-разработке куда больше прижился гитхаб-флоу - с пуллреквестами, сквошами (опционально) и по возможности линейной историей в мастере (чтобы неудачную фичу можно было целиком откатить одним реверт-коммитом, а не кропотливо ребейзить мастер, выкидывая оттуда коммиты, сломавшие продукт). и на эту модель вложенность > 1 влияет негативно, начинается бардак, сложности (АААА я не то вмержил к себе!) и всё равно в конце надо самую верхнюю ветку, которая соберет в себя все задачи, ревьюить еще раз отдельно, ведь нет гарантии, что она в себя корректно интегрировала вложенные. я считаю, что это достаточный повод так не делать

никакого криминала так делать, разумеется, нет, всё в рамках задуманного. просто вносит много лишних действий и суеты. если задуматься, любое дерево можно превратить в плоский лист, упорядоченный по какому-то принципу. типа "сначала Вася делает кор-функционал в ядре" потом, как их вмержили "петя может писать апи", "ваня может пилить миграции" и всё это делать в мастер (ну или какая там у вас транк-ветка), и делать это мелкими атомарными задачками, а не огромной веткой, которая включает в себя еще 20 нижележащих веток, и которую хер помержишь, не сломав половину проекта

Всем привет! Подскажите, как вы работаете с вложенными ветками - например, есть ветка A, я из нее наследую ветку B, из которой наследую ветку C. Это все одна большая задача, которую раздробили на более мелкие и по отдельности. И вот на каком-то этапе, например, отдаю задачу С на тест и нужно в эту ветку влить свежий master. Чтобы это сделать, мне нужно влить master в А, А в B, а В в С. Может быть можно как-то это в один клик делать в шторме или еще как-то?

А зачем вливать мастер в А и Б

Тебе же в С нужно свежий мастер

чтобы тестировать со свежей версией апстрима? в мастере переименовали метод xxx в yyy, но твой код во всех твоих нижележащих ветках вызывает по-прежнему ххх. если ты вольешь это в ветку С, то А и Б от нее отстанут (а в них тоже разработка ведется, как я понял)

да, и еще мердж реквесты С в В будут содержать данные из мастера

я ж говорю, это изначально сложная и херовая ситуация, лучше её избегать. я не понимаю, почему вас релиз-инженер за такое не поубивал)

никакого криминала так делать, разумеется, нет, всё в рамках задуманного. просто вносит много лишних действий и суеты. если задуматься, любое дерево можно превратить в плоский лист, упорядоченный по какому-то принципу. типа "сначала Вася делает кор-функционал в ядре" потом, как их вмержили "петя может писать апи", "ваня может пилить миграции" и всё это делать в мастер (ну или какая там у вас транк-ветка), и делать это мелкими атомарными задачками, а не огромной веткой, которая включает в себя еще 20 нижележащих веток, и которую хер помержишь, не сломав половину проекта

иногда нужно большую задачу выкатывать целиком и нет возможности по отдельности делать задачи и релизить их

на самом деле, я же просто спросил, есть ли такая возможность, а вы мне говорите, что нужно менять подход)

ну возможность есть - мержьте сверху вниз. сначала в крупную ветку мастер, потом в нижележащии по иерархии вниз, в чем вопрос-то?

Мне кажется тут нужен rebase

Всем привет! Подскажите, как вы работаете с вложенными ветками - например, есть ветка A, я из нее наследую ветку B, из которой наследую ветку C. Это все одна большая задача, которую раздробили на более мелкие и по отдельности. И вот на каком-то этапе, например, отдаю задачу С на тест и нужно в эту ветку влить свежий master. Чтобы это сделать, мне нужно влить master в А, А в B, а В в С. Может быть можно как-то это в один клик делать в шторме или еще как-то?

Некоторые прямо в мастер фигачут и вроде это считается даже отличной практикой (транк что-ли называется). Мне кажется у вас явно слишком много уровней вложенности, даже с вашим кейсом. Есть девелоп -> фича -> подзадача. У вас вроде еще один уровень нарисовался. Опять таки даже так уже неудобно, скорее всего надо смотреть в сторону более жесткой декомпозиции главной фичи. Особенно если на бэке, вполне можно вылить какие то обновления, даже если фронт не подоспел

иногда нужно большую задачу выкатывать целиком и нет возможности по отдельности делать задачи и релизить их

для этого придумали фича-флаги, версионирование апи (делаем новое апи в v2 пока текущее работает в v1) и кучу всего другого. вы решаете проблемы неудачного проектирования гитом, оно вот немного боком и выходит. неудачное тем, что без фича-флагов/v2 вы очень обрадуетесь всё откатывать, взорвись оно на проде

а будь у вас фича флаги со-существующие с основным мастером (или новое, нестабильное и непубличное пока апи), вы бы спокойно чинили новый функционал, не откатывая огромный этот релиз, который радостно наплодили

как тут мастер в ветки помержить, право, наименьшая из проблем - ну берете и мержите сверху вниз, в чем вопрос-то?

для этого придумали фича-флаги, версионирование апи (делаем новое апи в v2 пока текущее работает в v1) и кучу всего другого. вы решаете проблемы неудачного проектирования гитом, оно вот немного боком и выходит. неудачное тем, что без фича-флагов/v2 вы очень обрадуетесь всё откатывать, взорвись оно на проде

Фича флаги прикольная штука, но чет вообще не знаю как это можно на бэке норм реализовывать) На фронте мне кажется более понятно -открыл/показал окошки, а на бэке часто касается БЛ и БД. П.С. не юзал, но хотелось бы понять, как грамотно завозить )))

Фича флаги прикольная штука, но чет вообще не знаю как это можно на бэке норм реализовывать) На фронте мне кажется более понятно -открыл/показал окошки, а на бэке часто касается БЛ и БД. П.С. не юзал, но хотелось бы понять, как грамотно завозить )))

тут бесполезно про общие рекомендации говорить. надо конкретные случаи обсуждать. где-то придется вторую таблицу/вьюху рядом завести, типа accounts_v2 и наливать ее триггерами (чтобы параллельно две версии работало), где-то чисто кодом достаточно разрулить

микросервисы примерно и отсюда тоже растут: проще сделать accounts_service_v2 рядом с текущим accounts_service и как-то там трафик в него наливать отдельно, а потом полностью переключиться. например, с помощью api gateway/BFF

Я так понимаю это больше имеет какой то смысл с тестами БЛ/конверсии, которые потом можно откатить. Т.е. типа попробовать фичу в бизнесе, а не ради отката если фича упала из-за кода. Потому что наливать просто фичу фича флагами с такими сложностями в поддержке - как то перебор наверное.

ну хз, вот надо новое апи для мобильного приложения сделать, допустим, это новое апи аутентификации. мобильное приложение не могут писать, если там не будет аутентификации в самом начале

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

поэтому удобнее это новое апи аутентификации помержить в мастер, выложить куда-то по "секретному урлу" и жить с ним, будто это часть мастера

параллельно писать мобильное приложение, никого не блокируя

@sc0rp10 Согласен, но не понял поинт, как это с моими мыслями не согласует.

Тут вопрос в том для чего А и Б ветки

Это временные ветки которые сами по себе будут заброшены?

Или они рано или поздно сами войдут в мастер

Имхо если чел закончил работу с С, то дальше обычный флоу

Смерджил мастер в С, потестил, залили обратно в мастер

Дальше те кто херачят А и Б как обычно когда им надо получили свежий мастер с изменениями от С

Если для того чтобы протестить С нужно менять другие ветки это бред

Это очень неудобный флоу

Не масштабируемый вообще

Тут вопрос в том для чего А и Б ветки

Я так понял, что есть большая фича и подзадачи, в них ведется разработка и они актуальны. И таких фичей может быть несколько с подзадачами. И пока фича не будет сделана полностью, она не вольется в мастер. Но большие фичи ведут за собой проблемы с сложными мержреквестами и разрешением конфликтов.

Просто не пойму зачем здесь и сейчас мерджить мастер в А и Б

Нужно в С свежее из мастера, смерджил мастер в С

Нужно свежее из А, смерджил из А

Те кто работает над А, сами могут решить когда им смерджить себе мастер

Да конечно будут конфликты, но их количество зависиь от количества общего кода который меняется а не от того в каком порядке что мерджится

А не должно по идее зависеть от С никак. Иначе это бред

Просто не пойму зачем здесь и сейчас мерджить мастер в А и Б

Дано: master->future->sub1 master->future->sub2 master->future2->sub3 sub 1 и sub2 не должны в себя мержить мастер. Так как будут и конфликты и не нужные мержиться именно в future, хотя задачах sub 1,2. Например future2 была замержена в мастеп. Если сделать мерж миенно мастера в sub1 то когда будет мерж реквест в future - то там будет весь future2. А если еще и конфликты то вообще пздц. Короче правило точно рабочее: откуда пучкуемся, от туда себе и подмерживаем и вливаемся туда же.

Таким образом чтобы работать с актуальным кодом в sub1, надо сначало подмержить master в future , а только потом future в sub1

Хз что за правило и кто его придумал

Хз что за правило и кто его придумал

Это логика)

Ты так красиво нарисовал тут

У тебя тут никакх диверджей нет

Ну вот пример, мне дали сделать кнопку, а я в свою задачу подмержил мастер (а там новый код). Я когда делаю МР в свою главную задачу, то там будет на проверке и новый код. Оно нафига кому надо?

Ничего не вижу страшного в том что С напрямую смерджит в себя мастер

Ничего не вижу страшного в том что С напрямую смерджит в себя мастер

Ответ выше