Популярность оверинженеринга.

[AmdY]

В теме про laravel, hell0w0rd оставил отличный комментарий.

с одной стороны все так, с другой инжектить TemplateEngine внутри контроллера, если ты не пишешь FosUserBundle кажется мне глупостью, в условиях реального приложения, а не абстрактной библиотеки под все случаи жизни.

Последнее время код завален паттернизацией, разные DI, интерфейсы на каждый чих, DBAL, Mapper и Repository, ну и тесты для менеджеров BDD behat и spec. Такое чувство, что все пишут коробочный продукт, где ядро обязано быть upgrade safe, а код трогать нельзя или делают это только ради тестов.

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

В то же время на кофе по java докладчик заявляет - может хватить городить сетеры-гетеры, делайте свойства публичные, а когда понадобится рефакторинг в любой IDE поправит нужный код за секунду. Я придерживаюсь таких же правил, рефакторинг и правка ядра, дешевле абстракций. Особая ниша upgrade safe продуктов, которых единицы. А вы как?

 

[флоппик]

И я

 

[Вурдалак]

Heil Fowler!

А можно с примерами: ради какой маленькой фичи ты городишь десяток сущностей и даже меняешь код ядра?

 

[keltanas]

Что здесь подразумевается под ядом? Общий код для вызова команд в своем велосипеде? Или ядро стороннего фреймворка, на котором строится приложение?
Придерживаюсь мнения, что прежде чем править ядро, какое бы оно не было, нужно точно убедится, что весь код, который этим ядром запускается, на 100% протестирован (у всех ли код хорошо покрыт тестами?)
За себя, например, не могу в этом поручиться, и привык, что правка кода в ядре отзывается жуткой pain in ass. Отсюда и стремление максимально отвязываться и абстрагироваться от ядер. Да и рефакторинг в IDE тоже ошибается.

 

[AmdY]

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

Вурдалак, ну из последнего, нужно вывод данных из логов. Создаём модельку Logger, создаём репозиторий LoggerRepository, в случае доктрины а аннотациями схему, запускаем консольку чтобы всё это съелось, теперь пишем код для DI, чтобы всё инджектилось куда надо, ах, ещё же нужен Paginator чтобы EM передать в него.
В Laravel быдлоспособом это всё делается в одну строку return View::make('logger.index')->withData(Logger:aginate()), но сейчас так же пошла мода на репозитории.

 

[hell0w0rd]

keltanas, тут не хватает сообщения @Вурдалак

https://speakerdeck.com/jakzal/decoupling-from-the-framework — рекомендую.

Посмотри презентацию, человек предлагает вместо $this->getEntityManager()->getRepository(User::class) совать этот код в контейнер, а потом инжектить в контроллер. На этом он не останавливается, нужно под репозиторий написать интерфейс.
AmdY, геттеры/сеттеры в доктрине, к сожалению, обязательны из-за прокси-классов и вроде как отслеживания изменений.

Я когда собирался один бандл от проекта оторвать и на гитхаб выложить, решил конфиги из аннотаций в xml сунуть, вроде все так делают. Как оказалось у доктрины dtd ссылка даже не рабочая, и доки не содержат ссылок на рабочие по каждой отдельной версии, что на мой взгляд показывают, что в xml пишут конфиги из-за какого-то снобства, я плюнул и переделал в yml, ибо в каждом симфони-проекте он есть.

 

[AmdY]

hell0w0rd, часа два назад смотрел эту презенташку, как раз и припекло плюс здравый твой коммент и припекло. Зачем писать внутренний код как внешние бандлы, тем более если вероятность их реиспользования 0.

 

[hell0w0rd]

Кстати есть интересное решение от knplabs, они весь этот ад с паттернами оформили в бандл, который сам создает сервисы и дает кучу сахара над симфони... чем-то мне напоминает ваш любимый ларавел. http://rad.knplabs.com/

 

[AmdY]

hell0w0rd, клёво, так сам ларавел и есть такой же бандл, прячет все паттерны под капот. меня эта писанина очень удручает.

 

[Вурдалак]

Я могу только позавидовать тебе, если писанина у тебя занимает большую часть времени. У меня большую часть задачи занимает:

1. Изучение существующего кода
2. Построение удачной модели (в общем смысле, я не про «M» из MVC) для нового кода.

 

[AmdY]

Вурдалак, так вот эти проблемы со временем обычно и вылазят из-за оверинженеринга, налепят кода и десяток абстракций, ни прочитать, ни баг выловить, ни код писать без толстой вики. Продумывание туда же, вон топик на 5 страниц и пару дней про корзину, решение занимает 15 минут сам сталкивался на практике, не говоря уже о том, что можно на пакэйджгисте скачать готовую. http://phpclub.ru/talk/threads/Интернет-магазин-Хранение-корзины-товаров.78183/

Ну и 100% покрытие тестами - это особая статья, когда каждый гет-сет покрывают и мокают вплоть до файловой системы. Да и большую часть гибкости закладывают ради удобства тестирования.

p.s. Я гиперболизирую проблему, но только потому что стал сталкиваться с обожествлением паттернов, и реально приходится делать кучу лишних действий, профита от которых не получаем.