мне кажется гит флоу для веб-сервисов не нужен

github flow(или просто trunk based development) топчик

А можно ли считать убер или спотифай веб-сервисом?) Просто сейчас кажется все или почти все - веб сервис)

у спотифая есть нативные приложения)

merge после деплоя я не вкуриваю)

а почему? страх?

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

Карочи, расчехляем CV и добавляем serverless. Ща начнется (я уже жду, когда Uber сделает подобны пост).

А по факту: Netflix переходит на новую архитектуру, которая построена на лямбдах. Интересно, что там с очередями, но деталей мало, пока.

https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad

Тбд вообще про это ничего не говорит, проблема в том, что тбд вынуждает тебя внедрять много чего вокруг. В том числе более легковесный код ревью или его альтернативы

Скрам это фреймворк аджайл, но нельзя сказать что скрам это аджайл. Вот с тбд и реализацией все примерно так же.
Зы
Я понимаю что мои речи могут звучать как ересь для людей которые живут с пулл реквестами и код ревью

код ревью это, конечно, хорошо, но вы пробовали review before code?

pair programming

не, это другое

Что продаёте?

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

Да не, меня скорее смущает то, что оно все звучит примерно так:
- мы решили что это не проблема и не нужно
- как не нужно?
- ну вот не нужно, это все короче ересь и без этого хорошо.
- ну нет же, мы вот для этого его используем [...]
- нет, оно не нужно, просто используейте X
- оно же решает другие проблемы, а указанную решает лишь частично
- оно вообще не важно, мы вот внедрили вчера и я верю что оно норм.
Как то так:)

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

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

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

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