Смотря что абстрагировать. Взять те же СУБД. Подход с репозиториями верный, но не самый быстрый. Ну, допустим, сделаем.
В реализации репозиториев завязываться на конкретную СУБД по полной и фигачить внутри SQL? А если заменить надо будет через 10 лет… хммм… начинаем смотреть на PostgreSQL и MySQL. Понимаем что мало того, что придётся прижаться и юзать SQL99 и выкинуть половину крутых фич конкретной базы сразу (и это верно для большинства готовых data mapper-ов и AR), так ещё и не совсем тривиальные обёртки написать для типов данных, JSON и так далее.
Итого время на реализацию такой обёртки составляет треть от времени реализации начальной версии проекта… а может всё-таки зафиксировать что у нас будет всегда PostgreSQL и не страдать фигнёй?
Похоже на то, но вообще это одна контора же, ThoughtWorks. Они зарабатывают на консалтинге и им нужно было чтобы старый добрый cohesion/coupling стал новым модным SOLID.
Откладывание слишком большого числа технических решений ведёт к страшному усложнению взаимодействия простых вроде бы компонентов (переслоёности), увеличению времени на разработку прототипа, повышению порога входа в проект, невозможности использования уникальных для конкретной реализации фич и другим гадостям. К тому же, абстракции постоянно текут.
Мы фреймворк бросать не собираемся. То есть развиваться будет.
Ветка 2.0 замораживается на тему новых фич через несколько месяцев. Сейчас пилится версия 2.1 с тучей PSR-интеграций и изменениями архитектуры. Она скоро станет основной.
Так а в чём тут удар? Был 1.1. В принципе, и он работал нормально, но надо было обновлять. В компании было много людей с экспертизой в Symfony. Решили перелезть на Symfony. Логично вроде. Вот если бы взяли Yii 2 и он не подошёл бы или были бы проблемы с Yii 1.1, а не то, что его просто не поддерживают давно — тогда да. Был бы удар.
У Symfony идеология отличается прилично. На Yii можно делать очень просто и быстро, но и легко из за этого сделать плохо (лапшекод). На Symfony делать быстро и просто тоже можно (мы это сделали как-то на хакатоне, взяли второе место), но очень легко сделать слишком сложно (лазанья) и скатиться в J2EE (в плохом смысле). Одни compiler-pass и многоуровневое кеширование чего стоят...
Как бороться с лапшекодом знает практически каждый более-менее подкованный программист. Как бороться с переабстрагированием знают уже более опытные разработчики в то время как большинство не считает это проблемой.
Во-первых, стоит уточнить что переписать с Yii 1.1. Он несколько устарел и поменять его, если и так есть необходимость переписать, нормально.
Причины переписать именно с фреймворком не связаны. Бэкенд состоит из множества сервисов, самые старые на Yii 1.1 и, как бывает, архитектура самих сервисов, которая изначально была нормальной, в изменившихся реалиях бизнес-процессов, становится не очень подходящей.
Yii 2.0 вполне подошёл бы, самое сложное там всё-равно совсем не про фреймворк, но так как некоторые сервисы уже на Symfony и у многих экспертиза именно в Symfony, было решено (ещё до моего прихода) не плодить зоопарк.
Смотря что абстрагировать. Взять те же СУБД. Подход с репозиториями верный, но не самый быстрый. Ну, допустим, сделаем.
В реализации репозиториев завязываться на конкретную СУБД по полной и фигачить внутри SQL? А если заменить надо будет через 10 лет… хммм… начинаем смотреть на PostgreSQL и MySQL. Понимаем что мало того, что придётся прижаться и юзать SQL99 и выкинуть половину крутых фич конкретной базы сразу (и это верно для большинства готовых data mapper-ов и AR), так ещё и не совсем тривиальные обёртки написать для типов данных, JSON и так далее.
Итого время на реализацию такой обёртки составляет треть от времени реализации начальной версии проекта… а может всё-таки зафиксировать что у нас будет всегда PostgreSQL и не страдать фигнёй?
Похоже на то, но вообще это одна контора же, ThoughtWorks. Они зарабатывают на консалтинге и им нужно было чтобы старый добрый cohesion/coupling стал новым модным SOLID.
Да ясно, что clean architecture и всё такое. Это не единственный подход к проектированию.
В случае письма у нас:
Очевидно, что тут не сделать небольшую абстракцию — преступление.
В случае с той же СУБД всё уже не так просто.
Откладывание слишком большого числа технических решений ведёт к страшному усложнению взаимодействия простых вроде бы компонентов (переслоёности), увеличению времени на разработку прототипа, повышению порога входа в проект, невозможности использования уникальных для конкретной реализации фич и другим гадостям. К тому же, абстракции постоянно текут.
Потому что не получилась бы красивая аббревиатура :) В SOLID часть принципов прилично накладываются на остальные.
Придумал, а точнее взял Coupling/Cohesion, вывел из них красивые буквы SOLID и сделал их модными именно Роберт Мартин. Тут ошибки нет.
Прямо сразу без правок не будет.
Мы фреймворк бросать не собираемся. То есть развиваться будет.
Ветка 2.0 замораживается на тему новых фич через несколько месяцев. Сейчас пилится версия 2.1 с тучей PSR-интеграций и изменениями архитектуры. Она скоро станет основной.
Так а в чём тут удар? Был 1.1. В принципе, и он работал нормально, но надо было обновлять. В компании было много людей с экспертизой в Symfony. Решили перелезть на Symfony. Логично вроде. Вот если бы взяли Yii 2 и он не подошёл бы или были бы проблемы с Yii 1.1, а не то, что его просто не поддерживают давно — тогда да. Был бы удар.
Работает всё.
Какой бэкенд проекта Yii2 на Symfony?
Я попробовал разобраться. Похоже на data provider-ы из Yii + гриды / списки.
Любой шенген катит.
DI container?
У Symfony идеология отличается прилично. На Yii можно делать очень просто и быстро, но и легко из за этого сделать плохо (лапшекод). На Symfony делать быстро и просто тоже можно (мы это сделали как-то на хакатоне, взяли второе место), но очень легко сделать слишком сложно (лазанья) и скатиться в J2EE (в плохом смысле). Одни compiler-pass и многоуровневое кеширование чего стоят...
Как бороться с лапшекодом знает практически каждый более-менее подкованный программист. Как бороться с переабстрагированием знают уже более опытные разработчики в то время как большинство не считает это проблемой.
И ещё на митапе SuperJob был этот же доклад. Вот видео: https://youtu.be/EfL8lsUTlFo?t=1h27m44s
Скорее нет, чем да. 4-ка только-только вышла. Опасно.
Во-первых, стоит уточнить что переписать с Yii 1.1. Он несколько устарел и поменять его, если и так есть необходимость переписать, нормально.
Причины переписать именно с фреймворком не связаны. Бэкенд состоит из множества сервисов, самые старые на Yii 1.1 и, как бывает, архитектура самих сервисов, которая изначально была нормальной, в изменившихся реалиях бизнес-процессов, становится не очень подходящей.
Yii 2.0 вполне подошёл бы, самое сложное там всё-равно совсем не про фреймворк, но так как некоторые сервисы уже на Symfony и у многих экспертиза именно в Symfony, было решено (ещё до моего прихода) не плодить зоопарк.