Я к тому, что они тратят на разработку не деньги издателя, а деньги «бейкеров». И все эти покупки это вклад пользователя в «игру мечты». И пользователи готовы платить за это.
Какая разница чьи это деньги? Ну они выбрали такую модель монетизации проекта: брать деньги с БУДУЩИХ игроков. Вполне себе нормальная модель монетизации. Судя по цифрам — ничуть не хуже модели с инвесторами.
Но от того, что деньги они получают с конечных пользователей ДО выпуска продукта, это не перестает быть монетизацией
«Монетизация» !== «pay-to-win». Монетизация — это модель получения денег. И «нагиб за бабло», и «за бабло только бесполезные (но миленькие) рюшечки», и все промежуточные варианты — это все монетизация
Команда у нас действительно не большая, но над одной задачей бывает работают несколько разработчиков.
О таких калечащих изменениях обычно сообщается всем и заранее. Все приблизительно в курсе, кто чем занимается, поэтому если есть необходимость что-то поменять, то об этом сообщают людям, которых это может затронуть.
Не понятно, чем в данном случае ребейз от мержа будет отличаться? Только тем, что семантический конфликт будет зарыт внутри мерж-комита, а не идти отдельным?
Они будут не меньше, а все те же 1..N на каждый конфликтный файл.
Это будут уже другие конфликты. И высока вероятность, что их вообще не будет.
Я не утверждаю, что затраты всегда меньше, я говорю, что они с большой вероятностью будут меньше.
Похоже, что у нас слишком разный паттерн использования гита и продолжать спор смысла нет
Вот именно, ситуация когда разработчик не знает как правильно решить конфликт бывает гораздо реже (голова у тимлида не резиновая, тут Вы верно заметили).
Для решения конфликта тимлид наверняка привлечет разработчика ветки. Так почему бы разработчику самому не решать конфликты, без привлечения тимлида?
Описываемая Вами ситуация для нашей команды экстраординарная (если для Вас это норма — искренне Вам сочувствую). Поэтому накладные расходы на повторный ребейз и ревью не нами учитываются (к тому же они весьма вероятно будут значительно меньше).
Не знаю как у Вас построен процесс, а у нас в мастер вливает только тимлид. Владелец ветки перед передачей на слияние ребейзит ветку от мастера и решает конфликты, если они есть. Тимлиду же остается только влить изменения (после ревью). Конфликт решить проще разработчику, нежели тимлиду.
когда одновременно есть десяток-два веток становится сложно в этом ориентироваться. И не всегда все ветки вливаются в мастер, периодически фичи вливаются в фичи, особенно если над одной большой задачей работает несколько разработчиков.
Почему больше N? Разве не 1..N?
Действительно, может оказаться так, что конфликты в одном и том же месте придется разрешать несколько раз. Но есть большая вероятность, что они окажутся проще, чем при merge.
ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)
Вы не так поняли комент Davert-а. Он говорит о том, что есть уже симфони2 с Di, а зендовцы свой изобрели. И говоря о двух одинаковых фреймворках под разными брендами, он имеет в виду Symfony2 и ZF2, а не ZF1/ZF2
Этот пример вполне себе работает до определенного момента. И обычно критичным становится не ресурсы на вставку, а время преобразования при выводе.
И вообще, этот пример приводится скорее как иллюстрация отличия монги от реляционных СУБД, а не прямой призыв к действию. При проектировании надо головой пользоваться, а не оголтело пользоваться примерами
Ну если у Вас нагрузка НАСТОЛЬКО высока, что Вы оптимизируете вставку в поддокументы, используйте одноуровневые документы, там накладные расходы меньше