Я не то что сравнивал, скорее констатирую и удивляюсь разнице.
Я с wordpress плотно не работал, но все же кажется, что 500ms на 7 это слишком много. Что-то с wordpress не то
Почему может быть только вариант с корявой дисциплиной и кривой организацией?
Как на счет удобства A/B тестирования на определенном проценте пользователей?
Про скорость релизов выше тоже привели пример
Локально да, а когда нужно каждую ветку протестировать — pull request. Вот тут они и будут копиться, в зависимости как быстро они успешно проходят тесты и как скоро и ревьювят.
Пример: разработка бекенда со сложной обработкой ссылок (парсим, категоризируем текст, картинки пережимаем, тэгаем и т.д.)
Параллельно пишется для этого апи, которого тоже много. Апи должно быть актуальным, и максимально быстро выкатываться с фичами.
Ну вот и начинается. Ветка от ветки, затем оказывается, что это еще нужно кому-то и он еще больше ветвится. А если у вас начинает работать 20 человек, в итоге кол-во веток лично меня начинает страшно напрягать.
С засорением проекта не спорю — становится много чего. Но зато у каждого есть актуальный код и в тоже время стабильный trunk.
Ок, а как быть, если вам нужна фича, которую делает другой программист, но которой еще нет в dev? Допустим, что это большой функционал, а у вас нет времени ждать, пока он будет закончен — вы можете начать параллельно.
Ваш комментарий похож на этот
Данный подход не из-за неумения, а попытка решить проблему конфликтов при слиянии другим способом.
Не совсем понимаю, что здесь так вас насторожилоно
Думаю, что если фича небольшая, то вы вполне можете поочередно внедрять их. Если же это настолько большой функционал, что требуется одновременно два разработчика — скорее всего нужно разделить класс.
Да, понимаю. Скажем так, статье не о пользе/вреде использования di или сервис-локатора. Потому не хотелось бы здесь разводить об этом спор. Если же обойтись без использования сервис локатора, тогда кто будет отвечать за зависимости в коде? С одним di подмена одного класса на другой может привести к изменениям в разных местах, что усложняет, а то и вообще сводит на нет удобство branch by abstraction
Наверное вы имеете в виду dependency injection container, так как di это всего лишь инъекция зависимости. А так, вы можете использовать оба паттерна. Я выбираю сервис-локатор, чтобы в любом месте можно было получить доступ к требуемому объекту, не нагружая конструктор. Хотя с этим можно поспорить.
Я так понимаю, это отсылка к Doom и расшифровывать надо как Big Fucking Rocket?
Я с wordpress плотно не работал, но все же кажется, что 500ms на 7 это слишком много. Что-то с wordpress не то
Как на счет удобства A/B тестирования на определенном проценте пользователей?
Про скорость релизов выше тоже привели пример
Пример: разработка бекенда со сложной обработкой ссылок (парсим, категоризируем текст, картинки пережимаем, тэгаем и т.д.)
Параллельно пишется для этого апи, которого тоже много. Апи должно быть актуальным, и максимально быстро выкатываться с фичами.
С засорением проекта не спорю — становится много чего. Но зато у каждого есть актуальный код и в тоже время стабильный trunk.
Данный подход не из-за неумения, а попытка решить проблему конфликтов при слиянии другим способом.
Не совсем понимаю, что здесь так вас насторожилоно
Спасибо!