Комментарии 29
Почему сервис-локатор, а не dependency injection?
Наверное вы имеете в виду dependency injection container, так как di это всего лишь инъекция зависимости. А так, вы можете использовать оба паттерна. Я выбираю сервис-локатор, чтобы в любом месте можно было получить доступ к требуемому объекту, не нагружая конструктор. Хотя с этим можно поспорить.
Наверное вы имеете в виду dependency injection containe
Нет, я имею в виду Dependency Injection как паттерн (в противовес Service Locator как паттерну).
Я выбираю сервис-локатор, чтобы в любом месте можно было получить доступ к требуемому объекту, не нагружая конструктор.
Вы понимаете, что таким образом ваш код получает (а) множество прямых зависимостей от сервис-локатора и (б) невозможность определить по контракту класса, от чего тот зависит?
Ну и да, использовать в сервис-локаторе строковые ключи — плохая идея, в норме используются типы интерфейсов.
Да, понимаю. Скажем так, статье не о пользе/вреде использования di или сервис-локатора. Потому не хотелось бы здесь разводить об этом спор. Если же обойтись без использования сервис локатора, тогда кто будет отвечать за зависимости в коде? С одним di подмена одного класса на другой может привести к изменениям в разных местах, что усложняет, а то и вообще сводит на нет удобство branch by abstraction
Если же обойтись без использования сервис локатора, тогда кто будет отвечать за зависимости в коде?
Если заменить сервис-локатор на вбрасывание зависимостей, то за зависимости будет отвечать вбрасывающая система. У Симана все это прекрасно описано.
С одним di подмена одного класса на другой может привести к изменениям в разных местах
Да нет же. Вы и так, и так конфигурите некий composition root, задавая соответствие интерфейса и реализации, просто в сервис-локаторе вы потом достаете зависимости сам явно, а в dependency injection их в вас вбрасывает внешняя система.
В таком случае — да. Для исключения путаницы, то что вы описали я называю DIC
Dependency Injection — устоявшийся термин. И для этого не обязательно нужен контейнер.
Какой путаницы? Dependency Injection он и в Африке DI. Можно инжектить в конструктор, а можно в объект. С другой стороны, и Service Locator, и DI являются реализациями Dependency Inversion принципа (последняя буква solid). И вот тут уже путать не надо. DI, в отличае от Service Locator'а, как минимум позволяет а) абстрагироваться от контейнера б) отдать управление жизненым циклом объектов на аутсорс. Если и есть в этом мире антипаттерны, то это классический синглтон, и Service Locator.
А как быть, если разрабатываются две(
+n) раздельные фичи для класса `Foo` и в конфигурации у нас свойства: `enableFooFeatureА` и `enableFooFeatureB`? Две раздельные фичи в одном классе — нарушение SRP, не делайте так.
) Да я так и не делаю. Просто ведь из примера — мы добавляем некий функционал к уже существующему классу, то-есть расширяем его. И это вас не смущает? А если мы хотим разбить этот функционал просто на два флага, это уже вас смущает? Или же мы делаем два расширения по очереди, это вас тоже не смущает, а вот уже параллельно, это уже не комильфо?
Вообщем о single resp. principle можно долго холиварить, но не в этом суть. Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.
Вообщем о single resp. principle можно долго холиварить, но не в этом суть. Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.
Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.
Можно сколько угодно. Branch By Abstraction — частный случай Feature Hiding, который позволяет регулировать фичи не только путем подмены реализации, но и просто вставкой if-ов в код.
Думаю, что если фича небольшая, то вы вполне можете поочередно внедрять их. Если же это настолько большой функционал, что требуется одновременно два разработчика — скорее всего нужно разделить класс.
Выше уже ответили. Это плохая практика.
[offtopic]Прочтение статьи навеяло [/offtopic]
Мне кажется или кто-то не умеет готовить `git flow` и организовать организацию?
Настораживает, когда проблемы инфраструктуры решают в коде, а проблемы кода — в триггерах БД ))
Настораживает, когда проблемы инфраструктуры решают в коде, а проблемы кода — в триггерах БД ))
Ваш комментарий похож на этот
Данный подход не из-за неумения, а попытка решить проблему конфликтов при слиянии другим способом.
Не совсем понимаю, что здесь так вас насторожилоно
Данный подход не из-за неумения, а попытка решить проблему конфликтов при слиянии другим способом.
Не совсем понимаю, что здесь так вас насторожилоно
Дело не в неумении, а в том, что лидер ваш видимо не смог организовать команду и некоторые члены её пытаются решить проблему на уровне кода. Это плохо.
Претензия здесь не к тактике/методу/способу, а к стратегии.
Ужасы merge'й обычно бывают у веток, которые никто не ребэйзит и у которых миллион «merge feature branch into feature branch from origin:feature branch». Если же всем (контроль — задача лидера) соблюдать банальное правило, что фича-ветка всегда отребейжена на свежий местный develop, то проблем с merge ноль, ибо уже все отребейжено.
Претензия здесь не к тактике/методу/способу, а к стратегии.
Ужасы merge'й обычно бывают у веток, которые никто не ребэйзит и у которых миллион «merge feature branch into feature branch from origin:feature branch». Если же всем (контроль — задача лидера) соблюдать банальное правило, что фича-ветка всегда отребейжена на свежий местный develop, то проблем с merge ноль, ибо уже все отребейжено.
Ок, а как быть, если вам нужна фича, которую делает другой программист, но которой еще нет в dev? Допустим, что это большой функционал, а у вас нет времени ждать, пока он будет закончен — вы можете начать параллельно.
Дык работаете в одной фича-ветке?
Либо в третью ветку скидываете интерфейс и класс-заглушку (это уже ближе к вашему варианту), но не «засоряете» этим trunk/dev/master/develop/yourname.
Открою тайну — любая VCS умеет делать ветку от любой другой ветки.
Либо в третью ветку скидываете интерфейс и класс-заглушку (это уже ближе к вашему варианту), но не «засоряете» этим trunk/dev/master/develop/yourname.
Открою тайну — любая VCS умеет делать ветку от любой другой ветки.
Ну вот и начинается. Ветка от ветки, затем оказывается, что это еще нужно кому-то и он еще больше ветвится. А если у вас начинает работать 20 человек, в итоге кол-во веток лично меня начинает страшно напрягать.
С засорением проекта не спорю — становится много чего. Но зато у каждого есть актуальный код и в тоже время стабильный trunk.
С засорением проекта не спорю — становится много чего. Но зато у каждого есть актуальный код и в тоже время стабильный trunk.
в итоге кол-во веток лично меня начинает страшно напрягать.
Дык их публиковать то не надо сразу всем подряд и чистить за собой надо тоже.
Локально у человека обычно 3 ветки — develop, master, feature/bla.
А вот вопрос возникает, что когда у нас слишком многим нужно паралелльно, что-то — почему оно так? Low coupling/high cohesion м.б. нужен? Хотя это больше мечты ))
Приведите реальный пример, когда нескольким людям что-то надо было, м.б. даже с картинкой. Сколько людей зависело? 1/2/4/8/...? Как это оно так получилось?
Локально да, а когда нужно каждую ветку протестировать — pull request. Вот тут они и будут копиться, в зависимости как быстро они успешно проходят тесты и как скоро и ревьювят.
Пример: разработка бекенда со сложной обработкой ссылок (парсим, категоризируем текст, картинки пережимаем, тэгаем и т.д.)
Параллельно пишется для этого апи, которого тоже много. Апи должно быть актуальным, и максимально быстро выкатываться с фичами.
Пример: разработка бекенда со сложной обработкой ссылок (парсим, категоризируем текст, картинки пережимаем, тэгаем и т.д.)
Параллельно пишется для этого апи, которого тоже много. Апи должно быть актуальным, и максимально быстро выкатываться с фичами.
тут вопрос на сколько у вас быстро изменения идут в продакшн.
Я готово поспорить что те кто постоянно «бранжит» не готовы релизить несколько раз в день в продакшн в принципе.
А иногда и один раз в день сложно…
И это леко понять… Мердж — мануальный таск… не автоматизировать.
Я готово поспорить что те кто постоянно «бранжит» не готовы релизить несколько раз в день в продакшн в принципе.
А иногда и один раз в день сложно…
И это леко понять… Мердж — мануальный таск… не автоматизировать.
Релизить несколько раз в день? Это по-мойму ближе к хотфиксам. Каждый день так делаем, после сложного релиза или когда ВНЕЗАПНО (с) надо что-то кому-то где-то.
`git flow hotfix start x.y.z`
За мердж фича-веток надо отпиливать по одному пальцу. Фича-ветки должны только ребейзиться на девелоп — и только после этого вся красота и польза веток начинает быть видна в истории. А когда куча веток начавшихся где-то глубоко внизу под текущей версией девелопа, в которые девелоп ещё и вливается каждый раз… Это уже бессмысленый набор коммитов, а не ветки ((
По одному пальцу, не меньше.
PS: shuron, скорее всего у вас тоже организация и дисциплина хромает. Как только мы ввели у себя «китайский» подход — всё сразу наладилось ))
`git flow hotfix start x.y.z`
За мердж фича-веток надо отпиливать по одному пальцу. Фича-ветки должны только ребейзиться на девелоп — и только после этого вся красота и польза веток начинает быть видна в истории. А когда куча веток начавшихся где-то глубоко внизу под текущей версией девелопа, в которые девелоп ещё и вливается каждый раз… Это уже бессмысленый набор коммитов, а не ветки ((
По одному пальцу, не меньше.
PS: shuron, скорее всего у вас тоже организация и дисциплина хромает. Как только мы ввели у себя «китайский» подход — всё сразу наладилось ))
2012 Фейсбук уже два раз в день может
Хотя они лохи.
Амазон оже 2011-ом кажды 11.6 секунд что-то в продакшн релизил techcrunch.com/2012/08/03/facebook-doubles-release-speed-will-roll-new-code-twice-a-day
А у нас не все ок, пока но лучше чем год назад, когда я перешел в компанию…
В моей команде не бранжим с начала проекта, можем релизить и пару раз в день, но в моей команде 3 девелопера и много легаси херни в инфрастктуре что просто не успеваем пока столько сделать для продакшн…
Баги не редко доходят до продакшн, неплохо перекрыти автоматическими тестами…
Соседняй команда состоит из 5 девелоперов и они бранжат… Счастье если они раз в неделю релизнутся…
Хотя они лохи.
Амазон оже 2011-ом кажды 11.6 секунд что-то в продакшн релизил techcrunch.com/2012/08/03/facebook-doubles-release-speed-will-roll-new-code-twice-a-day
А у нас не все ок, пока но лучше чем год назад, когда я перешел в компанию…
В моей команде не бранжим с начала проекта, можем релизить и пару раз в день, но в моей команде 3 девелопера и много легаси херни в инфрастктуре что просто не успеваем пока столько сделать для продакшн…
Баги не редко доходят до продакшн, неплохо перекрыти автоматическими тестами…
Соседняй команда состоит из 5 девелоперов и они бранжат… Счастье если они раз в неделю релизнутся…
Почему может быть только вариант с корявой дисциплиной и кривой организацией?
Как на счет удобства A/B тестирования на определенном проценте пользователей?
Про скорость релизов выше тоже привели пример
Как на счет удобства A/B тестирования на определенном проценте пользователей?
Про скорость релизов выше тоже привели пример
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Service Locator и Branch By Abstraction — супер-зелье