Среди тех, кто пишет на Symfony встречается много людей, которые его искренне любят. А среди тех, кто его не любит встречается много людей, которые тем не менее этим фреймворком зарабатывают. Так что все написанное ниже не более, чем психотерапия для последних, а также удобная ссылка для троллирования первых фанатами, например, Yii.
Введение
Когда 4 года я впервые начал работать с этим фреймворком, мне показалось, что он переусложнен. В коммьюнити мне объяснили, что я нуб, который опробовал не так много других веб-фреймворков, чтобы делать выводы. Это объяснение меня удволетоврило. 3 года назад мне посчастливилось работать в паре с человеком, фанатом Symfony, который все хотел делать правильно и согласно идеологии, из-за чего мы безбожно срывали сроки. Коллега объяснил мне это тем, что говнокод клепать не надо. Это объяснение было из области идеологии и я предпочел не спорить. 2 года назад я сделал несколько типовых проектов сам, используя так мало компонентов Symfony как только возможно, и был приятно удивлен этим фреймворком. Коммьюнити сказало мне, что у меня низкий уровень интеллекта из-за чего я не способен эффективно оперировать сложными абстракциями. Это объяснение не то что бы меня удволетворило, но худо бедно объясняло происходящее. Год назад мне на поддержку попался проект, владелец которого был недоволен высокой стоимостью поддержки и малой скоростью разработки. Проект писали серьезные ребята, все было сделано по книжке, идеальный код. Было задействовано все: фильтры ассетика, все фичи форм, активно использовались события, были использованы лучшие популярные бандлы где была хоть малейшая возможность не писать свой код, в общем код был редким эталоном, который и в опенсорсе нечасто увидишь. Я списал произошедшее на то, что «звезды» устали заниматься рутинной поддержкой и стали работать спустя рукава. Ну а что мне еще оставалось думать, если бандлы к фреймворку множились, а сам фреймворк мало того что получил грант, так еще и всюду считался верхом совершенства?
И вот наконец месяц назад, я был вынужден оставить и этот проект, передав его другому программисту. Начав искать себе замену, я столкнулся с тем фактом, что все вопросы по Symfony, которые я мог придумать на собеседование, так или иначе упирались в знание справочной информации, что, учитывая ее обилие, было неудивительно но неудобно. Стратегия поиска «просто вменяемого программиста» была бы провальной — нужен был человек, который бы сразу въехал в проект, не тратя свое время на борьбу с премудростями фреймворка, уже набивший шишки. Тем более сам проект был обыкновенным CRUD-ом, пусть и объемным. В итоге я просто составил примерный список основных вещей с которыми должен столкнуться каждый программист, чтобы проверить правда столкнулся ли с ними кандидат перед тем как столкнуться со мной. Но такой подход заставил меня задуматься.
По результатам нескольких проведенных собеседований я пришел к некоторым выводам. Во-первых Symfony толком не знает практически никто, за исключением людей, которые не просто с ней работают, но, простите, пердолятся в нее. Во-вторых даже те люди, которые знают многие компоненты Symfony, ругаются на их переусложненность и в результате не используют их. Все это окончательно убедило меня в том, что с этим фреймворком что-то не так.
Немного истории
Сейчас Symfony около 5 лет, но это так называемая Symfony 2 — вторая ветка фреймворка, совместимая с первой на уровне названия почти полностью(не считая двойки в конце). В остальном это разные фреймворки, и первая ветка уже благополучно всеми забыта, поэтому речь пойдет о фреймворке Symfony 2, первые коммиты в github репозиторий которого были сделаны в январе 2010.
С самого начала фреймворк позиционировался как сборище всего самого нового, лучшего и продвинутого в веб-разработке на PHP, и это были первые плиточки на дороге, ведущей в ад. Сейчас это уже четырехполосное шоссе. Корпоративность из фреймворка перла до такой степени, что создатель предлагал обучающие курсы с сертификацией еще в то время, когда фреймворк был несколько далек от готовности к промышленному использованию. А может это просто был способ монетизации, и если так, то он удался. Само наличие таких курсов уже говорило о том, что фреймворк был не для слабых духом и вообще предназначался для произведения впечатления на серьезных дяденек, которые привыкли видеть стойкую корреляцию между сертификатом и профпригодностью обладателя сертификата. И ведь правда, там была калька со многих вещей из уютного java-мирка: и dependency injection, когда даже родную мать можно объявить сервисом, была бы пустая строчка в конфиге, и ORM по сложности сравнимый с Hibernate, и аннотации, которые были больше чем аннотации, и, в качестве завершающего штриха, сверхмодульная структура, дико дробленая на файлы и пытающаяся выжать все из возможностей ООП в PHP.
Все это настолько соответствовало духу высокого штиля в программировании, что однажды создатель фреймворка получил грант на развитие своего детища в размере 7 млн. долларов. Серьезный фреймворк для серьезных задач получил не только аргументы в рамках действующей идеологии совершенного кода, но еще и аргумент понятный всем программистам, даже совершенно не связанным с совершенным кодом, и более того, не связанных с программированием.
Сперва фреймворк распиарили, и, несмотря на его адову кривизну в 2011 году, все только и говорили какой он замечательный. Что характерно, многие, в том числе я, повелись на это и решили выбрать этот фреймворк как способ профориентации. Некоторые молчали, некоторые плевались, за счет демагогии и активной подмены понятий(компоненты симфонии используются много где == симфония используется много где) проблемы в значительной мере замалчивались, а популярность фреймворка росла. А после получения гранта можно было заткнуть любого скептика. Круг самоподдува замкнулся.
Коротко о главном
Фреймворк переусложнен, причем без видимых на то причин. И все это прибито ментальными гвоздями. В попытках сделать архитектуру фреймворка максимально гибкой была нагорожена тонна абстракций, требующих бойлерплейта и времени на то, чтобы заставить полезный код работать в рамках этих абстракций. Чтобы все было как в Java, но только в PHP.
Избавиться от этого нет никакой возможности — отход от стандартной идеологии крайне не одобряем сообществом. Нельзя просто взять и отказаться от использования компонента, который вам стал поперек проекта. Это повлечет сильные репутационные издержки для того несчастного, который предложит, например, не использовать стандартный ACL или формы. Если вы захотите выкинуть Doctrine из своего проекта, то вам придется потом долго и нудно объяснять каждому встречному, почему вы это сделали под укоризненное качание головы. Сами по себе компоненты Symfony очень хороши(из-за этого у многих сторонних разработчиков складывается впечатление, что весь фреймворк так же хорош), но когда они собираются вместе, начинается страшное.
Хоть прошло и порядочно времени со времен создания PHP, а многие стереотипы потеряли актуальность, очень часто в области веб-разработки до сих пор творится трэш. В мелких проектах никто не пишет тесты, никто не работает над хорошей архитектурой, никто не думает о том, как это потом поддерживать. Да чего греха таить, в средних и крупных все это начинает происходить уже после того как проект «выжил». Это плохо, но это норма жизни. По моим ощущениями, то что пишут на хабре про то, как правильно разрабатывать программы, соблюдается дай бог 20-30% разработчиков. В остальных случаях это трэш, в котором совершенный код — подойдет только в качестве эпитафии на могилу проекта. Тут применение Symfony по всем стандартам качества — не просто метание бисера перед свиньями, это заливание скотины таким количеством бисера, чтобы она хрипела и дохла, захлебываясь им.
Symfony дает колоссально извилистую кривую обучения, на вершине которой вас ждет не эффективность разработки выше чем на других фреймворках, а умение бороться с самой Symfony. Порой это тот фреймворк, где проще все переписать самому, чем следовать его гайдлайнам. Я думал что я идиот не способный понять симфонию ровно до тех пор пока не встретил код от человека, выступающего по конференциям по Symfony, и поддерживающим собственный форк этого фреймворка. Этот код реализовывал собственный механизм ACL. В комментариях к коду была заметка — собственный ACL писался из-за сложности стандартного ACL в Symfony. Возможно он тоже идиот, тут не угадаешь, но есть над чем задуматься, а в целом вырисовывается забавная картина.
Symfony-only developer
Сложность фреймворка такова, что я ловлю себя на мысли, что если пару недель активно не работаю над проектом на Symfony, то мне потом приходится въезжать не только в сам проект, но и во фреймворк. Возможно у меня плохая память, но сможет ли более памятливый читатель, считающий что такой сложности нет, сходу вспомнить и написать без гугла и копипаста как:
- сделать наследование таблиц в доктрине, типичное действие для нескольких групп пользователей
- добавить новую роль в стандартный ACL
- добавить хелпер в Twig
- добавить аннотацию для для VARCHAR и TEXT в модели
- добавить репозиторий
- добавить новую группу валидации в форму
- добавить трансформер в форму
- объявить нечто как сервис, возможно с несколькими аргументами, возможно написать фабрику для этого сервиса
- реализовать загрузку файла, привязанного к Entity
- добавить в доктрину поддержку очередной агрегатной функции SQL
- написать консольную команду
Есть еще и особый третий путь, исконно русский, он заключается в том, что вы устраиваетесь работать в низкопробную веб-студию, которая клепает сайты по шаблону, а значит вы будете по 10 раз на дню повторять одни и те же немногочисленные операции, что даст возможность их запомнить. И даст стойкую иллюзию того, что вы таки знаете Symfony. Хотя если вы достаточно пытливы, то вы ее узнаете. Только зачем?
К сожалению, я не нашел способа как отвечать всем требованиям современного программиста на Symfony, не словив при этом симфонию головного мозга. Если вы, дорогой читатель, обнаружили таковой, и он не является выигрышем в генетическую лотерею, то поделитесь им в комментариях.
Конструктор
Когда я мельком прочитал о том, что Drupal с версии 8 имеет много общего с Symfony, неудивлению моему не было предела. Ведь оба продукта по сути конструкторы сайтов, несмотря на то, что в одном случае мы имеем CMS, а в другом — фреймворк общего назначения. Возможно, что концепция конструктора для большей части современного web — это та концепция, которая позволит сэкономить время, повысить безопасность за счет использования многократно протестированных компонентов. Там еще есть всякие рюшечки, которые смотрятся очень красиво, а старой веб-макаке, не знающей слов дизайна, для самостоятельной реализации недоступны. А заказчики это любят. Рюшечки, а не старых веб-макак.
Но есть некий баланс между тем, сколько времени вы потратите на допиливание готового блока, чтобы он работал в вашем проекте, и тем, сколько времени лично вы потратите на то, чтобы самому написать этот функционал. Этот выбор очень неоднозначен в случае Symfony — сложность самого фреймворка, насаждение сложной для восприятия архитектуры бандлов, кривизна самих бандлов, порой ломающихся при минорном обновлении, все это делает использование готовых блоков не таким уж очевидным выбором. Пусть даже готовый бандл сэкономит вам много часов в будущем, если вы не выкатите новый функционал сегодня, будущего может и не быть. А вы можете и не выкатить, если будете разбираться с бандлом — не все они заводятся с полоборота. Бывали случаи когда я выкидывал после нескольких часов мучений бандл-обертку вокруг популярной библиотеки и в итоге использовал свою обвязку или же прямой доступ к библиотеке. Symfony сейчас популярна, а значит туда лезет толпа самопиарщиков, жаждущих получить сотню-другую звездочек на гитхабе. К сожалению после первых нескольких звездочек энтузиазм таких программистов угасает и багфиксы вы можете делать собственноручно.
Идея же крупного сайта-конструктора часто критикуется из-за того, что такой подход несет сложности в поддержке и поиске тех, кто сможет это поддерживать. Вы не можете найти человека сходу под те технологии, что у вас есть. В Perl-мире это даже одна из самых распространенных проблем — от веб-фреймворка остается только название, под капотом может скрываться все что угодно. И это приводит к поиску «просто хорошего программиста» и даче ему времени, чтобы въехать в проект. Для PHP, где очень значительная часть проектов — мелочь, бюджеты для которых малы, а на рынке труда куча посредственных кадров, поддержка сайта-конструктора вообще вызывает серьезные вопросы.
Ни туда ни сюда
Symfony, в том виде в каком она есть сейчас, занимает непонятную нишу. Выше было написано, что лучше всего она подходит для массового поклепа сайтов на базе фреймворков на ее базе. Но это донышко веб-разработки, особенно с точки зрения квалификации программистов, которые оседают на таком донышке, вкалывая по 10 часов.
Но Symfony подразумевает огромные времязатраты на обучение, есть вполне официальная занудная книга по ней, которая раскрывает тонкости чуть менее, чем никак. Есть курсы по ней же. Вроде как рассчитано на крупные серьезные проекты? Хорошо, допустим. У нас вроде есть все архитектурные изыски требуемые в больших проектах. И дробленость, удобная для тестирования, и события в ядре фреймворка, и DI, а файлы конфигурации подвластны корпоративному божеству Ксамаэлю, и все такое прочее.
При ближайшем рассмотрении все это — не более, чем реализация многих паттернов, которые сами рождаются в любом крупном проекте. Но только если они нужны. Symfony однозначно говорит, что они нужны. И именно в том виде, в котором они реализованы в Symfony. Хотя применение ORM такого как Doctrine в корпоративных проектах вообще крайне сомнительно — длинные запросы на DQL по десяткам таблиц это то, что не приснится даже в самых худших кошмарах. ACL, которое будет завязано на LDAP и черт еще знает что, и которое нужно будет писать почти с нуля, пытаясь подстроиться под стандартный ACL Symfony. А глядя на иные архитектурные изыски диву даешься — компонент для дампа рекурсивных структур данных(а таковыми являются почти вещи которые вы захотите дампить) появился только в версии 2.6, уже после выпуска первой LTS ветки. Понадобилось около 4 лет, чтобы подобная элементарная фича появилась во фреймворке.
Для штучных маленьких проектов Symfony хороша за счет огромного количества бандлов. Но плоха за счет сложности обучения и… решения проблем вызванных самим фреймворком — все это отнимает время. С другой стороны на базе Symfony можно легко построить свой фреймворк, отвечающий специфике вашей работы. С третьей стороны сколько я себя помню, веб-студии и так всегда создавали для себя фреймворки на базе чего угодно для типовых сайтов. И что характерно, сложности при замене программиста те же, что в случае форка Symfony, что в случае самописного проекта.
Для современных сайтов Symfony хороша за счет… того что застряла на уровне веб 2.00, вернее первых его ревизий. Symfony Forms — это отменная вещь до тех пор пока вам не приходится делать полудинамические или динамические формы. Для круда Symfony Forms божественны, для CRUD с парой-тройкой динамический полей они терпимы, для сколько-то серьезной клиентской логики форму проще выкинуть и спроектировать заново. Валидацию и сохранение данных переделать придется тоже. Т.е. сами формы вещь отличная, но вот переход от простого фронтенда к сложному не продуман. То же касается и Assetic. Хотя во всем остальном Symfony пропагандирует самый передовой(или стереотипно-правильный?) подход во всем.
Для корпоративных проектов Symfony подходит тем, что имеет LTS и официальную поддержку, курсы с сертификацией, но плоха тем… а впрочем программное обеспечение для корпораций независимо от фреймворка и языка всегда получается монструозным и трудным в поддержке.
Проблема изоляции компонентов
Даже для незначительных изменений приходится ворошить кучу файлов. Например, если вы добавляете в форму поле, для этого нужно:
- добавить поле в FormType
- добавить рендеринг в шаблон
- если для нового поля нужны какие-то зависимости(например получение извне данных для listbox), то нужно сделать изменения в services.yml, конструктор формтайпа
- если поле привязано к какому-то полю модели, но не может быть прямо сохранено в базу, то вам нужно внести изменения в трансформер формы
- если это поле — файл, то возможно придется править код контроллера, если вы не хотите уродовать модель процедурой сохранения файлов
- если у вас правила валидации в модели(а в 90% проектов они либо там, либо в отдельном yml, но никак не в формтайпе), то добавить аннотации в модель
Изоляция компонентов по файлам и указание зависимостей одних компонентов от других тоже со временем превращается в головную боль. Вы не можете просто дернуть ядро фреймворка через global, это неправильно! Вместо этого когда вам внутри Entity понадобится сделать что-то сложное, но все-таки связанное с этим Entity, то вы можете или сделать проброс нужных зависимостей в Entity, или отрефакторить наверх всю цепочку вызовов, убедившись, что вместе с сохранением Entity происходят нужные действия.
В обоих случаях это сложно и требует высокой концентрации — вам нужно поправить конструктор Entity или его репозитория, убедившись, что нужные зависимости пробрасываются. Потом сделать изменения в services.yml. Звучит просто, но даже с IDE это требует времени. Рефакторинг с пробросом наверх действий, которые требуют зависимостей, тоже вызывает понятные сложности. Вы фактически вываливаетесь из процесса написания бизнес-логики и погружаетесь в процесс ее подгонки под фреймворк. Это примерно как отвлечься на телефонный звонок в процессе написания кода.
Для компонентов максимальная изоляция это хорошо. Для бизнес-логики это, на мой взгляд, вызывает излишние сложности. Во всяком случае в том виде, в котором это преподносится Symfony.
Сообщество
Как только вы объявили нечто самым лучшим и активно это распиарили, у вас почти гарантировано появится аудитория, которая захочет приобщиться к этому новому и лучшему. Эта аудитория оправдает любые огрехи и недостатки технологии, а вас, несогласных,… не оправдает. Symfony неявно(или таки явно?) подразумевает под собой самые передовые решения, самые правильные подходы, что косвенно означает, что если ты не с Symfony то твое место в ПТУ, а твоя участь — поклеп сайтов на джумле. Старое доброе «кто не с нами, тот дурак».
Ладно, допустим вы адаптировались к такому раскладу, и научились строить нужную мину при обсуждении данного фреймворка. Теперь вы сталкиваетесь с другой проблемой — передовые решения зачастую сырые, их часто забрасывают после пары месяцев активности на гитхабе сами авторы. Но вам будут их советовать, особенно сами авторы. Вы будете получать в наследство бандлы которые не заработают под 2.3 или 2.7, фиксы к которым вам придется искать по многочисленным форкам. И качество, качество… На словах вся правильность порой оборачивается соблюдением PSR и хорошей настройкой IDE. Благодаря этому тонны бойлерплейта дают ложно представление о нормальном качестве кода. Сообщество Symfony является почти идеальным примером иллюстрирующим проблему ученого дурака — знания показушны, поверхностны, истинного понимания как все это работает у многих нет, зато есть демагогия позволяющая оправдать все проблемы и непробиваемая самоуверенность.
Самое печальное, что эти люди как правило не знают весь фреймворк в совершенстве, но часто знают отдельные его куски, костыли и прочие козьи тропы. В результате когда кто-то не знает того, что знают они, они раз за разом отказываются замечать сложность фреймворка и огромное количество справочной информации, которую невозможно держать в голове. Они обитают в тесном кругу задач, где все обходные пути уже найдены, а до других частей фреймворка им дела нет.
Сообщество является главным и единственным катализатором того бедлама, который творится с Symfony. Не будь его, можно было бы выкинуть Assetic, Forms, Doctrine, а также Good Practices и использовать как Symfony как нормальный микрофреймворк из коробки.
Неужели все так плохо?
Symfony не сильно хуже всех остальных фреймворков, но идеология и негласные правила, которые идут вкупе с фреймворком, делают его использование неэффективным. В случае пересмотра того, что можно, а что богопротивно делать с этим фреймворком, с ним можно будет комфортно работать даже несмотря на сложность. В рамках такой политики будет полезна и ревизия Symfony Book так чтобы она отвечала на конкретные технические вопросы, а не учила правильному стилю программирования.
Из-за сложности Symfony есть и положительная сторона, не для заказчика, но для программиста — оплата труда несколько выше, чем на других фреймворках. Даже больше! На этом фреймворке вы сможете создать такую причудливую архитектуру, которая не будет понятна никому, но по всем формальным признакам будет идеальной. Это усложнит поиск вашей замены. Ну и если вы потратите пару неделю и соберете на базе Symfony свой фреймворк, то вам будет относительно весело на фрилансе.
В заключении
Я намеренно не приводил иллюстраций конкретных проблем типа реализации аггрегатных функций на Doctrine, медленной работы Assetic, ограничений в темизации форм, примеров бойлерплейта и т.п. Для тех, кто искренне любит фреймворк, это не проблемы. А всех остальных, также считающих, что Symfony — замечательный способ делать простые вещи через тридесятую задницу, я искренне поздравляю — вы не одиноки. Добро пожаловать снова.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (156)
OnYourLips
20.04.2015 01:25+1Сложилось мнение, что пытаетесь стрелять из пушки по воробьям. Данный фреймворк плохо подходит для небольших проектов на 2-5 человеколет. И хорошо подходит для больших проектов, его минусы тут оборачиваются плюсами.
Каждой задаче свой инструмент.PerlPower Автор
20.04.2015 01:38+8Опять двадцать пять. Вы можете мне толком объяснить почему он подходит для них? Хороших программистов на нем мало, DQL для аналитики неудобен, Assetic на большом количестве ассетов первращается не в слайдшоу, а в пошаговую стратегию в режиме разработки. Шаг в сторону от пары десятков распространенных бандлов — и вы сами будете делать все фиксы в них. Да у меня в прошлом году Doctrine ломалась на минорном(!) обновлении. Через несколько лет нединамичные формы будут практически моветоном, по вашему их удобно делать в Symfony? Объясните мне пожалуйста, чем хорош этот фреймворк.
kalessil
20.04.2015 08:44+2Если не лезть в дебри кода, то обратная совместимость минорных релизов — на моей памяти только они это обещание сдержали.
Часть абстракции именно для того, чтобы сложно было напортачить (высокий порог вхождения).
OnYourLips
20.04.2015 10:49+41) Бизнес-логика на этом фреймворке framework-agnostic, не зависит от кода фреймворка в вашу бизнес-логику ничего лишнего не попадет.
2) Строгая конфигурация. Все должно быть описано явно, никаких умолчаний. Я не видел других фреймворков, где не используемая где-то опция в конфигурационном файле роняла проект. И это правильно.
3) Статически-типизированный фреймворк. В Laravel или Zend повсеместно нарушается ООП при использовании fluent-интерфейсов (фальшивых интерфейсов с магическими методами, разрешающими любой вызов), в результате чего IDE ничего не знает о контексте.
4) Прекрасно расширяется, разделение бизнес-логики по бандлам. В Laravel или Yii у вас основные модели очень скоро начнут реализовывать паттерн God Object. В Symfony код, относящийся к определенным подобластям бизнеса, будет лежать в своих бандлах.
5) Еще плюс сервисов — прозрачное их использование. Хотите — просто вызываете их код. Хотите — делаете доступными их по SOAP парой строчек конфигурации. Как вы провернете такое с Yii или Laravel моделями?
> Хороших программистов на нем мало
За 1-2 месяца хороший PHP программист уже нормально пишет на этом фреймворке. Или вам надо, чтобы через 5 минут после найма программист уже досконально ваш проект знал?
> Assetic на большом количестве ассетов первращается не в слайдшоу, а в пошаговую стратегию в режиме разработки.
Не замечал такого, все мгновенно работало. По умолчанию он просто используется в режиме копирования (совместим с Windows), но легко переключается в быстрый режим с использованием симлинков.
Если не хотите использовать Assetic — никто не заставляет, используйте свой любимый сборщик, это же symfony — набор слабосвязанных компонентов. Я бы сейчас gulp подключил.
> Да у меня в прошлом году Doctrine ломалась на минорном(!) обновлении.
Doctrine не является частью Symfony.
> У нас вроде есть все архитектурные изыски требуемые в больших проектах. И дробленость, удобная для тестирования, и события в ядре фреймворка, и DI, а файлы конфигурации подвластны корпоративному божеству Ксамаэлю, и все такое прочее.
DI — это инструмент, который сильно упрощает разработку, снижая связанность кода. Странно, что вы этого не поняли за… сколько там лет опыта вы имеете с этим фреймворком, говорите?PerlPower Автор
20.04.2015 12:05+41) Бизнес-логика на этом фреймворке framework-agnostic, не зависит от кода фреймворка в вашу бизнес-логику ничего лишнего не попадет.
Полностью с вами согласен, но не понимаю при чем тут Symfony. Более того Symfony дает указания как именно вам организовывать код. На Perl почти все бизнес логика лежит в отдельных от фреймворка местах — и это писалось еще тогда, когда Symfony просто не было. Выходит дело в программистах, а не в Symfony.
2) Строгая конфигурация. Все должно быть описано явно, никаких умолчаний. Я не видел других фреймворков, где не используемая где-то опция в конфигурационном файле роняла проект. И это правильно.
А как же подход Convention over configuration? В той же википедии написано, что Symfony использует таки этот подход. Хотя это и не заметно… Вы случайно не путаете необъявленный сервис с не используемой опцией?
3) Статически-типизированный фреймворк. В Laravel или Zend повсеместно нарушается ООП при использовании fluent-интерфейсов (фальшивых интерфейсов с магическими методами, разрешающими любой вызов), в результате чего IDE ничего не знает о контексте.
Приведите пожалуйста конкретный пример когда это может стать проблемой.
4) Прекрасно расширяется, разделение бизнес-логики по бандлам. В Laravel или Yii у вас основные модели очень скоро начнут реализовывать паттерн God Object. В Symfony код, относящийся к определенным подобластям бизнеса, будет лежать в своих бандлах.
Опять же, это можно сделать и без Symfony. В хорошо документированом God Object я вижу наоборот пользу.
5) Еще плюс сервисов — прозрачное их использование. Хотите — просто вызываете их код. Хотите — делаете доступными их по SOAP парой строчек конфигурации. Как вы провернете такое с Yii или Laravel моделями?
Редкий кейз. Его реализация в Symfony не покрывает гораздо более многих времязатрат на борьбу с другими вещами. Тем более если вы напишите SOAP-шарилку даже руками, то потом добавлять туда сервисы будет быстро.
> Хороших программистов на нем мало
За 1-2 месяца хороший PHP программист уже нормально пишет на этом фреймворке. Или вам надо, чтобы через 5 минут после найма программист уже досконально ваш проект знал?
> Assetic на большом количестве ассетов первращается не в слайдшоу, а в пошаговую стратегию в режиме разработки.
Не замечал такого, все мгновенно работало. По умолчанию он просто используется в режиме копирования (совместим с Windows), но легко переключается в быстрый режим с использованием симлинков.
В режиме симлинков он на удивление глючный, и часто не находит файлы. К слову при большом количестве установленных через bower ассетов он и на симлинках не особо быстрей. Если у вас есть фильтры, то приходится использовать как минимум в режиме контроллера, что тоже медленно.
Если не хотите использовать Assetic — никто не заставляет, используйте свой любимый сборщик, это же symfony — набор слабосвязанных компонентов. Я бы сейчас gulp подключил.
Ну через пару лет уже можно будет спокойно его выкидывать, да, сообщество готово. А вот legacy никуда уже не денется.
Да у меня в прошлом году Doctrine ломалась на минорном(!) обновлении.
Doctrine не является частью Symfony.
А почему тогда даже в Symfony Book есть раздел Doctine? Доктрина является де-факто стандартом от которого никуда не деться.
У нас вроде есть все архитектурные изыски требуемые в больших проектах. И дробленость, удобная для тестирования, и события в ядре фреймворка, и DI, а файлы конфигурации подвластны корпоративному божеству Ксамаэлю, и все такое прочее.
DI — это инструмент, который сильно упрощает разработку, снижая связанность кода. Странно, что вы этого не поняли за… сколько там лет опыта вы имеете с этим фреймворком, говорите?
Я использовал самописный аналог DI еще когда не знал что это такое. И я правда не понимаю в чем удобство DI в Symfony и чем он лучше других реализаций этой технологии.
Fesor
20.04.2015 12:29+3Более того Symfony дает указания как именно вам организовывать код.
В каком месте? Приведите пример где именно вам что-то кто-то называет? Вы так же можете ложить всю свою бизнес логику в отдельное место. В целом многие так и делают.
А как же подход Convention over configuration?
Ну так Symfony его и использует. Не вижу конфликта. Мне не нравится реализация dependency injection в Symfony, но это лечится (PHP-DI, autowiring).
Приведите пожалуйста конкретный пример когда это может стать проблемой.
Когда исповедуют TDD?
Опять же, это можно сделать и без Symfony
Да, более того, я против использования бандлов для хранения бизнес логики. Бандлы по определению должны быть самодостаточны, максимум один бандл (что-то типа AppBundle или Infrastrucre Bundle) для изоляции Framework layer.
В хорошо документированом God Object я вижу наоборот пользу.
Какую? Я за язычество, честно скажу. Мне противит идея одного глобального высшего существа который правит всеми.
Еще плюс сервисов — прозрачное их использование. Хотите — просто вызываете их код.
тут хоть цитата и не ваша, я просто хочу заметить что все сводится к сегрегации интерфейсов и инверсии зависимостей. Все это поощряет слабую связанность и ведет нас в светлое будущее.
В режиме симлинков он на удивление глючный, и часто не находит файлы.
может это с файловой системой что-то? В любом случае сам assetic это боль и унижение. выкинуть и забыть. Ассетик хорош только для случаев с крайне примитивным UI и был он нужен только вот в 2010-ом.
А почему тогда даже в Symfony Book есть раздел Doctine?
Ну наверное потому что доктрина идет в Symfony-stanrard-edition. Вам никто не запрещает сделать свою сборку и радоваться жизни.
tl.dr
Совершенного кода нет, есть код который приемлим на данный момент. Как вы уже замечали в статье все эти загоны по архитектуре и т.д. нужны только для одной цели — уменьшить стоимость поддержки кода, а не что бы выпендрится перед друзьями «смотри, я CQRS тут замутил». И все это нужно только для того что бы сделать бизнес-гайс хэппи. Если человек не в состоянии это уяснить, какой бы инструмент он не выбрал всеравно будут сорваны сроки из-за излишней педантичности и т.д.
Вот вы скажите, эти вот мегагуру которые делали все по best practice, какой на выходе у них был код ковередж проекта? Были ли тесты? Функциональные ли, интеграционные, юнит ли… Ибо если эти гуру парились о архитектуре но не писали тестов — значит в принципе они и не парились вовсе.
OnYourLips
20.04.2015 12:33+1> Полностью с вами согласен, но не понимаю при чем тут Symfony.
При том, что эта тема про симфони и сравниваем ее с другими фреймворками.
> На Perl почти все бизнес логика лежит в отдельных от фреймворка местах — и это писалось еще тогда, когда Symfony просто не было. Выходит дело в программистах, а не в Symfony.
В программистах. И в PHP такие программисты выбирают Symfony, чтобы не изобретать свой фреймворк на квадратных колесах.
> Вы случайно не путаете необъявленный сервис с не используемой опцией?
Не путаю. Неиспользуемая опция в конфигурации с большой вероятностью является индикатором ошибки. Поэтому жесткие меры по предотвращению подобных опций оправданы.
> Приведите пожалуйста конкретный пример когда это может стать проблемой.
Невозможность определить тип переменной в коде. Он будет известен только при выполнении.
Это отрицательно сказывается на качестве кода и увеличивает возможность ошибок (которые появятся только в рантайме, причем ситуативно).
Кроме этого это усложняет жизнь и при написании кода, ведь IDE ничего не может подсказать.
> Опять же, это можно сделать и без Symfony.
Конечно же можно. Все можно сделать без Symfony. Только затраты, качество и сроки будут другими.
> В хорошо документированом God Object я вижу наоборот пользу.
Можно пойти дальше, полностью весь код в один файл записать, без классов и функций. А для переходом использовать goto.
> Редкий кейз.
Для тех сфер, где применяется Symfony, частый. Это сервис-ориентированный фреймворк. Использование сервисов с других подсистем — обычное дело.
> А почему тогда даже в Symfony Book есть раздел Doctine? Доктрина является де-факто стандартом от которого никуда не деться.
В ней так же есть и раздел Propel.
Но они не являются частью Symfony.
Symfony не MVC фреймворк, он не предоставляет уровень модели. Это средство для соединения бизнес-логики и HTTP: fabien.potencier.org/article/49/what-is-symfony2
m_z
20.04.2015 13:06> 4) Прекрасно расширяется, разделение бизнес-логики по бандлам
Ну кстати по официальному гайду рекомендация хранить всё в одном бандле.
Но если делать действительно гибко, и «framework-agnostic», то бизнес-логику вообще не надо класть в бандлы.
> 3) Статически-типизированный фреймворк. В Laravel или Zend повсеместно нарушается ООП при использовании fluent-интерфейсов
В Laravel можно и правильно всё делать, можно и не по ООП. С таким же успехом можно и symfony испортить (у меня проект есть, где все зависимости разруливаются через $container->get()).
druidvav
20.04.2015 01:55+1Опыт подсказывает, что на мелких проектах симфони тоже очень даже неплох. И позволяет относительно просто этот проект масштабировать в перспективе. Не так уж много времени тратится на рутинные задачи, нормальному разработчику это время потратить нужно один раз в жизни.
PerlPower Автор
20.04.2015 02:03+5Bingo! У нормальных разработчиков все хорошо с фреймворком, а если у вас все не так хорошо то вы какой-то ненормальный. Вы выше спрашивали что конкретно делать, так вот, первое что приходит в голову: прицепить на главный сайт Symfony слоган «Только для нормальных разработчиков», чтобы всякие идиоты не лезли.
druidvav
20.04.2015 02:08+8Не проецируйте, пожалуйста, свой неудачный опыт на всех, а то комментарии напоминают полуночную истерику, уж извините.
saksmt
23.04.2015 17:40+8Дело не в нормальности/ненормальности, а в здравом смысле:
— те же, ненавидимые вами, формы можно радостно использовать и для быстрого написания CRUD, и для REST-сервисов, и для действительно сложных динамических форм без особых проблем;
— про то, как доктрина упрощает жизнь вероятно даже говорить не стоит, как-никак DataMapping всегда был лучше конкурентов в ORM, а ежели не согласны, то попробуйте-ка прикрутить Bidirectional Many-To-Many к ActiveRecord в том же самом Yii (да это была одна из причин перехода на Symfony, ибо вменяемо к Yii прикрутить что-либо практически невозможно, да даже с их extensions);
— даже при том, что GodObject это плохо, вам ни что не мешает сотворить его в Symfony (Singleton как сервис с call на метод установки контейнера), другой вопрос что проект через год будет проще переписать, чем рефакторить/поддерживать (что и случается с Yii{1,2}/Laravel);
— про память: не можете запомнить как создать репозиторий (простое наследование + одна аннотация/строчка в конфиге), добавить роль (просто одна строчка в конфиге, с содержимым в виде названия этой роли), добавить трансформер (реализовать один интерфейс), обявить сервис (даже IDE это умеет через 2 клика), написать комманду (наследование + реализация целых двух методов)? У меня для вас плохие новости…
— про бойлерплейт: не хотите писать очередной CRUD? Не проблема, возможно открою тайну, но есть замечательные стандартные кодогенераторы!
— тормозит Assetic при использовании бутстрапа из less + десятка файлов с bower-a? Может дело не в нём, а в вас? Может не стоит смешивать backend и frontend в крупном проекте? Может проще написать отдельно RESTFull backend и одностраничный frontend на angular/ember/...?
— не нравится сложность аннотирования доктрины при создании табличного наследования? Бегом читать дядюшку Фаулера, да-да те 3 здоровые главы, вторые по объёму после блокировок + сами блокировки + IdentityMap + UnitOfWork + MetadataMapping + ..., а после осознания прочитанного, думаем ещё раз на тему «Так ли сложно прописать две аннотация, чтоб доктрина сделала всё за меня?»! Да, и вспоминая Yii, не напомните есть ли там такое вообще?
— про «возможность измения только на бумаге» (ветка ниже): заменить можно (!) любой компонент, не сильно много усилий прилагая (спасибо DI), другой вопрос нужно ли это или это просто очередной случай невнимательного чтения документации?
— ну и наконец про порог вхождения и сложность: это не у Symfony высокий порог вхождения, а у PHP низкий, любой нормальный программист, знакомый с ООП не только как с расшифровкой, способен писать на Symfony после (!) недели вкуривания документации, а ежели ещё и с SOA знаком, то после пары дней, а в некоторых случаях сразу (IDE — наше всё). А вот фреймворки с одним God-Singleton-ом (Yii 1) или десятком статических фасадов/singleton-ов (Yii 2 / Laravel) способствуют написанию неподдерживаемого быдлокода, хоть и идеальны для новичков (крайне низкий порог вхождения, ООП знать совсем не обязательно чтоб на них писать [личный опыт]). Отсюда и понятия «взрослых» фреймворков: Zend / Phalcon / Symfony, где большей частью возрастом нужно считать опыт программиста.
Всё, я выговорился, можете минусовать.PerlPower Автор
23.04.2015 19:09Дело не в нормальности/ненормальности, а в здравом смысле:
— те же, ненавидимые вами, формы можно радостно использовать и для быстрого написания CRUD, и для REST-сервисов, и для действительно сложных динамических форм без особых проблем;
Вы правы, для простых форм Forms идеальны и экономят много времени на создание крудов к моделям. На больших формах все уже не так однозначно — зависит от наличия динамических полей.
— про то, как доктрина упрощает жизнь вероятно даже говорить не стоит, как-никак DataMapping всегда был лучше конкурентов в ORM, а ежели не согласны, то попробуйте-ка прикрутить Bidirectional Many-To-Many к ActiveRecord в том же самом Yii (да это была одна из причин перехода на Symfony, ибо вменяемо к Yii прикрутить что-либо практически невозможно, да даже с их extensions);
Опять же, для простых крудов доктрина хороша. Для сложных запросов уже придется помучаться с DQL, для использования хранимок тоже придется с ним помучаться.
— даже при том, что GodObject это плохо, вам ни что не мешает сотворить его в Symfony (Singleton как сервис с call на метод установки контейнера), другой вопрос что проект через год будет проще переписать, чем рефакторить/поддерживать (что и случается с Yii{1,2}/Laravel);
Если вы почитаете комментарии, то увидите, что люди ставят в плюс Symfony готовую структуру и предсказуемость кода, и если я буду лепить нечто свое поверх фреймворка, то это будет встречено крайне неоднозначно. Вы можете менять фреймворк на свое усмотрение только в двух случаях: если вы тимлид или если вы пишите проект в одиночку.
— про память: не можете запомнить как создать репозиторий (простое наследование + одна аннотация/строчка в конфиге), добавить роль (просто одна строчка в конфиге, с содержимым в виде названия этой роли), добавить трансформер (реализовать один интерфейс), обявить сервис (даже IDE это умеет через 2 клика), написать комманду (наследование + реализация целых двух методов)? У меня для вас плохие новости…
Вы пишите еще на чем-то кроме PHP и Symfony? Так чтобы не на уровне hello-world и вводных туториалов. Если пишите, и у вас при этом все не вылетает из головы, то могу только позавидовать вашей памяти.
— про бойлерплейт: не хотите писать очередной CRUD? Не проблема, возможно открою тайну, но есть замечательные стандартные кодогенераторы!
Бойлерплейт также усложняет восприятие кода — меньше кода, проще читать. Кстати вам известно в каких случаях в 2.3 репозитории генерируются по doctrine:generate:entities, а в каких — нет? Только честно, не гугля.
— тормозит Assetic при использовании бутстрапа из less + десятка файлов с bower-a? Может дело не в нём, а в вас? Может не стоит смешивать backend и frontend в крупном проекте? Может проще написать отдельно RESTFull backend и одностраничный frontend на angular/ember/...?
Совершенно верно. Только assetic это де-факто стандарт. Его знают все, он во всех легаси проектах, он используется и в новых проектах, когда люди думают, что проект не вырастет. В общем от ассетика часто никуда не деться.
— не нравится сложность аннотирования доктрины при создании табличного наследования? Бегом читать дядюшку Фаулера, да-да те 3 здоровые главы, вторые по объёму после блокировок + сами блокировки + IdentityMap + UnitOfWork + MetadataMapping + ..., а после осознания прочитанного, думаем ещё раз на тему «Так ли сложно прописать две аннотация, чтоб доктрина сделала всё за меня?»! Да, и вспоминая Yii, не напомните есть ли там такое вообще?
Замечательно, что вы читали Фаулера. Судя по тому, что помните размер и название глав, делали это недавно. Теперь удосужтесь потратить хотя бы год, чтобы уложилось в голове, а потом еще несколько лет, чтобы вдумчиво разобраться всегда ли стоит их городить. Я не спорю, что такие вещи как IdentityMap и UnitOfWork это важно, но с тем, что их реализация нужна значительному числу пользователей Doctrine, вынужден не согласиться.
— про «возможность измения только на бумаге» (ветка ниже): заменить можно (!) любой компонент, не сильно много усилий прилагая (спасибо DI), другой вопрос нужно ли это или это просто очередной случай невнимательного чтения документации?
Верно, но вам все равно придется знать дефолтные компоненты Symfony и костыли к ним, потому что если вы придете на собеседование по Symfony и скажете, что вместо Doctrine вы использовали например Idiorm, то ваши шансы на прием на работу уменьшаться.
— ну и наконец про порог вхождения и сложность: это не у Symfony высокий порог вхождения, а у PHP низкий, любой нормальный программист, знакомый с ООП не только как с расшифровкой, способен писать на Symfony после (!) недели вкуривания документации, а ежели ещё и с SOA знаком, то после пары дней, а в некоторых случаях сразу (IDE — наше всё). А вот фреймворки с одним God-Singleton-ом (Yii 1) или десятком статических фасадов/singleton-ов (Yii 2 / Laravel) способствуют написанию неподдерживаемого быдлокода, хоть и идеальны для новичков (крайне низкий порог вхождения, ООП знать совсем не обязательно чтоб на них писать [личный опыт]). Отсюда и понятия «взрослых» фреймворков: Zend / Phalcon / Symfony, где большей частью возрастом нужно считать опыт программиста.
Всё, я выговорился, можете минусовать.
Если вы не соврали относительно вашего года рождения, то скорее всего Symfony — ваш первый фреймворк, или же первый среди тех, в какие вы серьезно вникали. Или у вас было относительно немного проектов и мест работы, в которых Symfony более менее подходил. Если нет, то поделитесь пожалуйста информацией о том сколько и где вы его использовали.saksmt
23.04.2015 21:10+1Вы правы, для простых форм Forms идеальны и экономят много времени на создание крудов к моделям. На больших формах все уже не так однозначно — зависит от наличия динамических полей.
Чтож это так, но не стоит их обливать по чём зря, при условии, что динамические поля являются проблемой абсолютно везде.
Опять же, для простых крудов доктрина хороша. Для сложных запросов уже придется помучаться с DQL, для использования хранимок тоже придется с ним помучаться.
Не припомню запроса, где бы с я мучался с доктриной, скорее наоборот, она частенько спасает. Что же касается хранимок, не буду врать в реальной жизни мне не приходилось с ними сталкиваться, более того я даже не могу представить ситуацию в которой они бы мне пригодились, но тем не менее ничто не мешает их использовать через нативные запросы с каким-нибудь хитрым гидратором. И опять-таки всё свелось к тому, что доктрина не плохая, а просто не идеальна (что собственно вполне логично).
Если вы почитаете комментарии, то увидите, что люди ставят в плюс Symfony готовую структуру и предсказуемость кода, и если я буду лепить нечто свое поверх фреймворка, то это будет встречено крайне неоднозначно. Вы можете менять фреймворк на свое усмотрение только в двух случаях: если вы тимлид или если вы пишите проект в одиночку.
Тут вы правы, но может тогда стоит выдвигать претензии не к инструменту, а к тимлиду, т.е. нормально с ним поговорить о существующих проблемах, сотворить решение, задокументировать в Confluence или другой местной вики и радоваться жизни?
Вы пишите еще на чем-то кроме PHP и Symfony? Так чтобы не на уровне hello-world и вводных туториалов. Если пишите, и у вас при этом все не вылетает из головы, то могу только позавидовать вашей памяти.
Ну, для начала к чему этот вопрос? Если вы не постоянный разработчик на Symfony или даже PHP, то зачем вообще было писать эту статью? Но тем не менее: да помимо Symfony я вполне способен писать на codeigniter, vanilla; помимо PHP я достаточно активно пишу на JS (но как видно по рейтингу моей статьи, это нужно только мне :) ), без bash/shell/zsh + grep/sed мне в принципе трудно живётся, ну и наконец я изредка пишу на lua и это только то, что не на уровне «потыкать ради интереса», а немного серьёзнее, и да я большую часть названий методов/классов/… помню + я достаточно не плохо помню синтаксис десятка языков программирования/разметки. Но речь ведь не о том, самое важное, что я помню как что делать в Symfony+PHP, не забывая при этом, например, angular или socketIO. А в целом эта претензия может быть с тем же успехом предъявлена к абсолютно любому, хоть сколько-то большому, инструменту.
Бойлерплейт также усложняет восприятие кода — меньше кода, проще читать. Кстати вам известно в каких случаях в 2.3 репозитории генерируются по doctrine:generate:entities, а в каких — нет? Только честно, не гугля.
- Это не тот объём + что вам мешает сотворить один контроллер как сервис и делегировать ему весь CRUD для всех простых сущностей меняя лишь роуты в конфиге? К тому же, для быстрого разбора в хорошо написанном коде (т.е. без сохранения сущностей внутри FormTypeInterface::buildForm()) совсем не сложно разобраться в коде просто пробежавшись по структуре классов через встроенные средства IDE.
- Не встречал случая, чтобы они вообще генерировались при этой комманде, хотя этому есть разумное объяснение: Я не использую эту комманду, как минимум потому, что мне не сложно при описании новой сущности потыкать Alt+Enter и Enter на «Generate accessors...» + это не создаст путаницы у меня в комментариях к методам (не переношу длинные записи названий типов [integer, boolean]).
Совершенно верно. Только assetic это де-факто стандарт. Его знают все, он во всех легаси проектах, он используется и в новых проектах, когда люди думают, что проект не вырастет. В общем от ассетика часто никуда не деться.
В таком случае это всё же не проблема ассетика, а проблема legacy (частенько это наименьшая проблема в втаких проектах). Но от него совсем просто можно отказаться и перейти на gulp или что-либо ещё, ведь выпилить из кода все вхождения "{% javascripts %}"/"{% stylesheets %}" совсем не сложно, даже простой регуляркой.
Замечательно, что вы читали Фаулера. Судя по тому, что помните размер и название глав, делали это недавно. Теперь удосужтесь потратить хотя бы год, чтобы уложилось в голове, а потом еще несколько лет, чтобы вдумчиво разобраться всегда ли стоит их городить. Я не спорю, что такие вещи как IdentityMap и UnitOfWork это важно, но с тем, что их реализация нужна значительному числу пользователей Doctrine, вынужден не согласиться.
- Читал я его примерно год назад, а объём помнится из-за сложности тем, что касается названий глав это необходимый словарь, посему я его достаточно неплохо помню. Никто не спорит, что злоупотребление паттернами есть зло, иногда даже худшее, чем антипаттерны, но я же не предлагаю создавать блокировки для однопользовательской системы и тем более не предлагаю использовать IdentityMap для хранения скаляров в яве ради оптимизации, не говоря уже о SpecialCase для каждого состояния объекта.
- Да, для немалой части операций с данными в PHP это оверкилл, но этот оверкилл окупается за счёт того небольшого процента сэкономленных запросов к БД (помним что это стоит дорого) и чрезвычайно удобного управления объектами. И опять-таки это из разряда «не идеального», а не плохого + Symfony тут прямо скажем не причём.
Верно, но вам все равно придется знать дефолтные компоненты Symfony и костыли к ним, потому что если вы придете на собеседование по Symfony и скажете, что вместо Doctrine вы использовали например Idiorm, то ваши шансы на прием на работу уменьшаться.
- Это уже зависит от работодателя.
- Не припоминаю необходимости пилить какие-либо костыли.
- С каких это пор в мире ИТ стало модно мало знать?
- Зато представьте, какой бонус вам будет, если на собеседовании вы скажете что умеете использовать и Doctrine, и Idiorm, и Propel, да ещё и в курсе в каком случае что лучше использовать и где какие есть проблемы и тем более понимаете как это всё прикрутить к симфони!
- Собственно претензия больше к людям, а не к инструментам, я вас правильно понимаю?
Если вы не соврали относительно вашего года рождения, то скорее всего Symfony — ваш первый фреймворк, или же первый среди тех, в какие вы серьезно вникали. Или у вас было относительно немного проектов и мест работы, в которых Symfony более менее подходил. Если нет, то поделитесь пожалуйста информацией о том сколько и где вы его использовали.
Я не вижу смысла врать, тем более так. Symfony — мой первый «взрослый» фреймворк, были попытки и на CodeIgniter (Я честно пытался вникнуть в него, но он слишком «не то»), и на Yii (как раз перед Symfony, вот как раз тогда ваш комментарий был бы актуален [его хотелось радостно защищать и восхвалять, пока не наткнулся на проблемы с поддержкой и беды с БД]), и попытки «потыкать» Laravel (уже после Symfony, пары старых умных книг, осознания ООП и паттернов), и попытки написать свои велосипеды (куда ж без этого); у всего этого лишь один плюс — опыт + я выработал для себя идеальный способ изучения новых технологий. Что касается опыта использования Symfony — он не так велик, всего с пяток коммерческих проектов (1 — legacy, 2 — CRUD, 2 — много бизнес логики, много данных) + разнообразная лабуда для личного интереса + изучение исходников FOSUserBundle + дохлые попытки портировать некоторые наиболее интересные куски Symfony для NodeJS (мало толку для ноды, но много толка для понимания работы Symfony), но пока все трудности решались чуть более вдумчивым чтениеPerlPower Автор
23.04.2015 21:38Как итог: какие у вас претензии конкретно к Symfony, не к доктрине, не к людям, которые не дают вам достаточно свободы для продуктивной работы, не к legacy-проектам, где нагорожено непойми что, и удивительно как оно вообще работало, а конкретно к Symfony?
Symfony, вернее ее документация и ее сообщество провоцирует людей на оверинжениринг. А вообще какие могут претензии к набору байтов? Нужно рассматривать явление в целом.
Ну, для начала к чему этот вопрос? Если вы не постоянный разработчик на Symfony или даже PHP, то зачем вообще было писать эту статью?
Вот именно поэтому я ее написал. И отдельно выделил абзац Symfony-only developer, потому что за счет перерывов в работе «со-стороны» мне были особенно заметны сложности, возникающие с этим фреймворком. По-моему опыту на сколь угодно проблемном языке и фреймворке можно эффективно работать, если «привыкнуть», и многие склонны путать привыкание с эффективностью самой технологии.saksmt
23.04.2015 22:07Symfony, вернее ее документация и ее сообщество провоцирует людей на оверинжениринг. А вообще какие могут претензии к набору байтов? Нужно рассматривать явление в целом.
Кхм, можно выдержку из документации? Я бы назвал это не «оверинженеринг», а дрессировкой до понимания концепций программирования в целом (при условии какая общая масса пишет на PHP — это необходимо), а когда человек понимает, что он вполне разобрался, то он лезет в «Best Practice», где чёрным по белому написано избегать лишней сложности. Что касается явления, то может стоит критиковать его, а не «чрезмерную сложность» Symfony?
Вот именно поэтому я ее написал. И отдельно выделил абзац Symfony-only developer, потому что за счет перерывов в работе «со-стороны» мне были особенно заметны сложности, возникающие с этим фреймворком.
Тут бы важно уточнить с какой стороны, мне бы тоже пожалуй казалось что всё в императивных языках слишком сложное, трудное к запоминанию и запутанное, попиши я годик-другой на хаскеле. Тут вопрос точки зрения, и невозможно сказать точно какая из них объективна. Прям «Здоровое Общество» Фромма…
По-моему опыту на сколь угодно проблемном языке и фреймворке можно эффективно работать, если «привыкнуть», и многие склонны путать привыкание с эффективностью самой технологии.
Так а в чём тогда проблема-то? Если можно эффективно работать, создавая вменяемый код, пусть даже и под действием «привыкания», то все ведь должны быть довольны, разве нет?
shmaltorhbooks
23.04.2015 21:22вставлю свои пять копеек в вашу дискуссию с замечанием насчет доктрины. Мое мнение таково: да, она отвратительна, она неповоротлива, она часто неудобна, местами сложна и не очевидна, запутана и «оверинжинерена» (есть такое слово?). но это лучшая ORM для PHP из существующих и с этим (как по мне, опять таки) приходится мириться.
Fesor
23.04.2015 21:23Ну с 2.5 уже можно жить как по мне.
shmaltorhbooks
23.04.2015 21:26личных проектов сейчас нет, а на рабочих как-то стрёмно обновляться, учитывая, что прошлые обновления до dev версий 2.5 на личных проектах приводили к печальным последствиям от откату до 2.4 :)
потому, собственно, сказать про 2.5 нечего — не успел посмотреть :)saksmt
23.04.2015 21:51+1Там наконец добавили ValueObject, теперь, наконец, не придётся делать из класса пользователя швейцарский нож.
Что касается монструозности и т.п., радует что оно не единомоментно разом всё грузится, да ещё и с кешем.
Что касается отвратительности и неочевидности: можете привести пример? (просто на моей памяти она себя так ведёт только с глубоко вложенными коллекциями, там с ленивостью немного переборщили, что приходится общаться с PersistentCollection и Proxy на сущность напрямую, дабы загрузить некоторые данные + весёлый баг больше относящийся к кодогенератору, но всё же: забираем дату, меням, запихиваем, пытаемся сохранить и получаем кукиш ибо это один и тот же объект и UnitOfWork посчитал его не изменившимся, а решается проблема через clone в аксессорах)
neolink
23.04.2015 22:59про нож — странная фраза такое ощущение что вам были нужны трейты?
про дату — это скорее бага php что ValueObject даты является изменяемымsaksmt
23.04.2015 23:24Некогда было пытаться выяснить можно ли доктрину мапнуть к полю трейта + это не решило бы проблему использования класса пользователя в тайп хинтах, где нужны лишь несколько его методов, а тогда тем более было не до создания/выделения интерфейсов.
Действительно, после модификации объекта даты «spl_object_hash» возращает то же значение, что и до неё.neolink
24.04.2015 01:38Да можно, вторую часть откровенно не понял.
да, с 5.5 есть такие php.net/manual/ru/class.datetimeimmutable.php, но использовать из тяжело, т.к. никто не проверяет DateTimeInterface, все проверяют DateTime
Fesor
23.04.2015 23:27Трейты не помогут решить проблему отсутствия VO.
neolink
24.04.2015 01:47да мы поняли уже что VO наше всё и без них всё не то.
Можете привести реальные примеры использования? Ну разве что кроме MoneyFesor
24.04.2015 13:09<?php namespace App\Domain; // VO типа этого можно реализовать один раз для всех своих проектов // так же как Money, DateRange и т.д. class Email { private $email; public function __construct($email) { // обычно логика сложнее, ибо filter_var не покрывает все кейсы if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { throw new \InvalidArgumentException(); } $this->email = $email; } public function __toString() { return $this->email; } } class Address { private $postcode; private $city; private $address; public function __construct($postcode, $city, $address); } // делаем модель пользователя, удовлетворяющую следующим бизнес правилам: // - пользователь всегда должен иметь валидный email // - пользователь всегда должен указывать адрес class User { private $email; private $address; private $password; public function __construct(Email $email, $password, Address $address) { $this->email = $email; $this->setPassword($password); $this->address = $address; } public function changeAddress(Address $address) { ... } public function setPassword($password) { // эту штуку тоже можно сделать VO, что было бы правильнее // ибо пользователь ничего не должен знать о том как хэшируется пароль... $this-password = password_hash($password, PASSWORD_BCRYPT); } }
Как итог, нам не нужна валидация, так как мы не можем загнать модель в невалидное состояние.neolink
24.04.2015 13:43валидация через ексепшены это еще холивара на 5 страниц.
email и до 2.5 можно было так сделать, вопрос только зачем?! Если вам хочется чтобы всё было объектами есть же Java.
про пароль, опять же VO тоже не должен знать как хешируются пароли, максимум что ему нужно это функции сравнения с другим hash за константное время
про адрес вариант конечно интересный, вот вам пример из реальной жизни — postcode у нас зависит не только от того где ваш адрес, но и от того являетесь вы юр. лицом или нет. То есть накрутив такой embed (это уже не оч. похоже на VO) postcode все равно придется считать от user, а если сделать trait можно сделать это даже красиво
опять же в реляциях адрес можно и сущностью сделать, тем более там обычно на порядок больше полей.Fesor
24.04.2015 15:15+1валидация через ексепшены это еще холивара на 5 страниц.
Это не валидация, в том то и проблема. Это исключения и все. Я считаю что это более чем нормально бросать исключения на ситуации не подподающие под наши бизнес правила. Вы можете валидировать DTO которое приходит вам перед тем как отдать это дело на обработку, и там будет старая добрая валидация со списком ошибок. Но если что-то плохое добралось до ваших бизнес объектов — а это последняя линяя обороны, то лучше жестко кинуть исключение.
Если вам хочется чтобы всё было объектами есть же Java.
Да, есть Джава, а еще есть C# который лично мне нравится больше чем Java, а еще есть PHP со схожей объектной моделью, который прекрасно подходит для подобного, и намного проще в эксплуатации. А теперь ответте, если язык A полностью удовлетворяет моим требованиям, зачем мне выбирать язык B? Только потому что там эти подходы общеприняты а в PHP все просто *башат код?
про пароль, опять же VO тоже не должен знать как хешируются пароли
Почему же? Это как сказать что DateTime не должен ничего знать о том как работать с датами.
про адрес вариант конечно интересный, вот вам пример из реальной жизни — postcode у нас зависит не только от того где ваш адрес, но и от того являетесь вы юр. лицом или нет.
и мы имеем 2 VO для физического и юридического адреса.
это уже не оч. похоже на VO
Почему же? Он иммутабельный и содержит в себе только то что относится к адресу. Можно еще и посткод тот же в VO завернуть… По умолчанию — все должно быть VO. Если наша логика не удовлетворяет этому условию (например нужно ID вводить, значит это уже мутабельная штука с идентификатором, стало быть сущность) — то можно уже думать в сторону сущностей, сервисов уровня домена и т.д. Ну и есть еще здравый смысл, не стоит делать все по книжке ибо иначе много времени будет тратиться на академические истины а не на реализацию бизнес логики. Если у вас домен покрыт тестами то можно потом будет смело улучшать и править.
а если сделать trait можно сделать это даже красиво
трэйты должны быть мега тупыми штуками, что-то содержащее мегатупой код, например, делигирующий ответственность другому классу. Для чего-то сложнее использовать трэйты — плохо. Если вы считаете иначе — значит вы не пишите тестов. Более того, использование трейтов не устраняет проблемы что ваши сущности станут жирным швейцарским ножом, что они будут слишком много знать и т.д. Трейты будут это просто прятать.
Но опять же, если вы не работали с VO то вас трудно будет убедить насколько это классно. Проще попробовать на домашнем проектике каком.neolink
24.04.2015 16:59> Только потому что там эти подходы общеприняты а в PHP все просто *башат код?
В Java и C# VO вписываются, а PHP не заточен под VO — вы не можете сделать значение и совсем спрятать его от другого кода. это все равно будет объект с парой магических методов, да вы даже сравнить их по человечески не можете.
> Это как сказать что DateTime не должен ничего знать о том как работать с датами.
не совсем, с датами понятно как с ними работать, и даты хранят даты, а хеши, хеши и как я и писал с хешами можно сделать компараторы, а вот их генерацию все делают по разному, алгоритмы, кол-во итераций, соль и т.п. слишком дофига контекста для объекта который хранит уже хешированный пароль.
> и мы имеем 2 VO для физического и юридического адреса.
в embed это точно не ляжет, можно через отношения, да и вообще если они по полям отличаться не будут, то зачем? Или определение PostCode предлагает тоже в рамках этих классов делать? Фактический/Юридический адрес тоже по сущностям делить?
> Не стоит делать все по книжке ибо иначе много времени будет тратиться на академические истины а не на реализацию бизнес логики
> Если вы считаете иначе — значит вы не пишите тестов
нуну. Кстати абстрактные классы вы тоже не тестируете?
Вообще абзац про трейты странен, трейты это добавляемое поведение, например захотели вы Update/Create себе в сущность взяли и добавили. Если это поведение предполагает например коллекцию чего-то, то естественно там будут и методы работы с ней.
> Но опять же, если вы не работали с VO
> (например нужно ID вводить, значит это уже мутабельная штука с идентификатором, стало быть сущность)
Мне показалось или для вас VO это любой immutable объект?
Как вы считаете если у пользователя выше сделать email как PK и убрать сеттеры, то он тоже будет VO или нет?Fesor
24.04.2015 18:20В Java и C# VO вписываются, а PHP не заточен под VO
Это как так?
не совсем, с датами понятно как с ними работать
С паролем все не столь однозначно, это точно. Я использую тупой вариант ибо у меня нет необходимостей в усложнении. Соль и вообще все хэндлится password_hash, BCRYPT вообще единственный вменяемый вариант из того что я вижу… Ну а если делать VO — можно реазовать метод фабрику и через дабл диспатч использовать там сервис-хэшер.
в embed это точно не ляжет
Ляжет, в конце концов и пользователи у нас для каждого типа будут иметь свой класс. А там уже можно разрулить.
нуну. Кстати абстрактные классы вы тоже не тестируете?
Нет, я тестирую только реализацию. Я не держу абстрактные классы без реализаций, а если мы и мувнули дублирующийся код в базовый абстрактный класс (хотя я стараюсь избегать подобного) — то он всеравно будет покрыт тестами.
Как вы считаете если у пользователя выше сделать email как PK и убрать сеттеры, то он тоже будет VO или нет?
Что именно? email так и останется VO, у него ж идентити нет никакого. А так это распространенная практика делать PK как VO (UUID/GUID)
saksmt
24.04.2015 16:14+1Не буду расписывать код, но если просто на словах, то:
- Есть проект в котором существенны сложные курсы валют, т.е. код валюты, название валюты (просто подгружается из API центробанка), добавочный процент (итоговые записи для пользователя — «CBE + 5%»), собственно сам курс (тоже из API) и дата. Вот как раз эту логику я был бы очень не прочь вынести в VO, но пока это реализовано через наследование от некоторого CurrencyHolder и это здоровенный костыль. И да это не Money, ибо здесь нет собственно количества.
- Есть другой проект, где пользователь имеет несколько кошельков (разные неконвертируемые внутренние деньги), на текущий момент это реализовано через то самое место: 4 метода — «payWithCoins(amount)», «payWithDollars(amount)», «replenishCoins(amount)», «replenishDollars(amount)». Но это лучше вынести в 2 VO, реализующих некоторый «WalletInterface» и код станет значительно чище (на 400 строчек меньше в классе пользователя, уберутся use-ы класса пользователя, оттуда где от него требуется только кошелёк и т.д.). Кстати, в этом случае валидацию на количество денег я бы сделал через исключения, а не через "@Assert" и это было бы очень даже логично.
MrLoki
20.04.2015 01:35+5Вы пишете, что работаете с Syfmony 4 года, но в разделе Symfony-only developer, приводите достаточно простые операции. Я знаю, как делается примерно половина из этого, а вторую половину загуглю за 15 минут. И с чистой симфони я ни разу серьезно не работал, единственный раз, лёжа в больнице от нечего делать написал хелловорд. У меня для вас плохие новости.
Да, симфони как правило сложен. Не трогайте его больше. Он вам не нужен. Вы не испытываете проблем, которые призван решать этот фреймворк.
Одна из таких проблем — отсутствие необходимости во фреймворке. Я могу разобрать симфони, и получить механизм способный решать конкретные задачи лучше чем любой другой фреймворк, и объём написаного кода будет меньше трёх сотен строк. Я выкину ненужный Doctrine, систему контроллеров, ассеты, ацл, и различные консольные приблуды, и буду работать только с тем, что мне нужно. Если что-то мне понадобится, я без проблем верну это, написав ещё 100 строк. И благодаря соглашениям и философии симфони, другой программист пришедший на проект быстро разберется в коде. В отличии от ужасных в этом плане микрофреймворков в которых черт ногу сломит.
Статья выглядит как попытка получить индульгенцию от толпы. Отсутствие конкретных выводов, подтверждает моё предположение :) Я года полтора назад тоже хотел написать такую статью, про то как тяжело жить с непредсказуемым Yii, потом понял, не тяжело. Просто нужно правильно выбирать инструмент для задачи. Статью так и не написал)PerlPower Автор
20.04.2015 01:52+1И вас совершенно не напрягает, что такие рутинные операции приходится гуглить?
И понимаете, я тоже могу разобрать фреймворк и сделать что-то свое, но на всех собеседованиях что я был, меня гоняли по стандартным компонентам. И собственно этим Symfony и отличается от микрофреймворков, которые вы не любите, там все уже в какой-то мере пришито, а возможность поменять это только на бумаге. Но если вы работаете в одиночку или тимлид, то вы правы. Только по-моему ваш вариант и является по сути микрофеймворком.MrLoki
20.04.2015 02:17+7И вас совершенно не напрягает, что такие рутинные операции приходится гуглить?
В любом наборе компонентов вам придётся что-то гуглить. Это нормально.
И понимаете, я тоже могу разобрать фреймворк и сделать что-то свое, но на всех собеседованиях что я был, меня гоняли по стандартным компонентам.
А меня нет. Меня в большинстве случаев вообще не гоняли по фреймворку, спрашивали более общие вещи.
Но если вы работаете в одиночку или тимлид, то вы правы.
Я работаю в достаточно большой команде. На данный момент, не тимлид.
Только по-моему ваш вариант и является по сути микрофеймворком.
По размеру — да, по определению — нет, микрофреймворк традиционно представляет собой роутер и DI без обвеса. Мой вариант — произвольный набор компонентов. Это не так важно в общем-то. Я к тому, что если понимаешь что делаешь, вообще не важно что используешь. Всегда придётся прикладывать какой-то процент усилий на борьбу с абстракциями окружения. Мне удобно с symfony-like стилем, вам нет — ок. Это холивар, правильного ответа нет)PerlPower Автор
20.04.2015 02:28В любом наборе компонентов вам придётся что-то гуглить. Это нормально.
Ну в случае Symfony это на мой взгляд очень уж часто. Хотя тоже непонятно о чем мы спорим — судя по постам выше у вас уже «свой» фреймворк, и я не знаю что именно из него вы активно используете.
По размеру — да, по определению — нет, микрофреймворк традиционно представляет собой роутер и DI без обвеса. Мой вариант — произвольный набор компонентов. Это не так важно в общем-то. Я к тому, что если понимаешь что делаешь, вообще не важно что используешь.
Я и веду к тому, что ваша версия Symfony не отличается от микрофреймворка в том смысле что практически все, кроме совсем уж оголтелых минималистов, все равно обвешивают любой микрофреймворк так, что в итоге выходит тот же fullstack.
Lailore
20.04.2015 03:20+7Кхм, Di это преимущество, а не недостаток, в проектах, которые живут дольше недели. В принципе, вся эта цитата — преимущества.
и dependency injection, когда даже родную мать можно объявить сервисом, была бы пустая строчка в конфиге, и ORM по сложности сравнимый с Hibernate, и аннотации, которые были больше чем аннотации, и, в качестве завершающего штриха, сверхмодульная структура, дико дробленая на файлы и пытающаяся выжать все из возможностей ООП в PHP.
neolink
20.04.2015 04:03+11Doctrine и Assetic это не части фреймворка — это хоть и имеющие встроенную интеграцию (doctrine), но сторонние компоненты которые можно выкинуть.
В тексте по сути только 1 проблемы именно Symfony — не очень удачная security, которая и правда получилась сложная и запутанная.
Остальной текст сплошной поток ненависти и обиды. Про dump() — начните пользоваться отладчиком.
Про память и код — если что-то нужно всегда можно открыть доку, если знаешь что искать конечно.
ЗЫ acl не использую (не смотря на свою стандартность его нужно включать отдельно, что как бы намекает), assetic тоже, doctrine классная, forms рулят, symfony лучшее что случилось с php.PerlPower Автор
20.04.2015 11:07-1Doctrine и Assetic это не части фреймворка — это хоть и имеющие встроенную интеграцию (doctrine), но сторонние компоненты которые можно выкинуть.
Как не части фреймворка? А откуда они в стандартной поставке? Или вы про ядро Symfony в голом виде? Ну так большинство пользуется стандартными бандлами из полного состава.
Про dump() — начните пользоваться отладчиком.
Выходит для дампинга компонент зря добавили, а симфонию пишут те, кто не умеет пользоваться отладчиком?
Про память и код — если что-то нужно всегда можно открыть доку, если знаешь что искать конечно.
Вопрос в частоте открываний. Симфония — это первый фреймворк, где я не смог отделаться просто сниппетами для бойлерплейта, тут нужно еще помнить как эти куски бойлерплейта взаимодействуют между собой.
acl не использую (не смотря на свою стандартность его нужно включать отдельно, что как бы намекает)
А что вы используете?
assetic тоже,
Т.е. у вас фронтенда или нет вообще или же он наборот настолько сложный, что у вас там grunt и ко.
doctrine классная, forms рулят
Я уже больше склоняюсь к тому, что фронтенда у вас нет, поскольку для простого круда связка доктрины с формами и правда дает хороший результат. Если не секрет как будете реализовывать форму с загрузкой нескольких файлов с предпросмотром и возможностью удаления файлов на лету?
symfony лучшее что случилось с php.
PHP не настолько плохой язык, чтобы говорить такое.Fesor
20.04.2015 11:12+2Я уже больше склоняюсь к тому, что фронтенда у вас нет, поскольку для простого круда связка доктрины с формами и правда дает хороший результат. Если не секрет как будете реализовывать форму с загрузкой нескольких файлов с предпросмотром и возможностью удаления файлов на лету?
Ну справедливости ради стоит сказать что это не одна форма. Это чисто реализация на фронтэнде, а на сервере — разные запросы. Какие-то ID файлов которые выходят потом уже разруливать через формы. Да и доктрина тут не причем.
p.s. последние года весь фронтэнд на проектах реализую на AngularJS, на бэкэнде только REST.
neolink
20.04.2015 11:50+2> А что вы используете?
по сути роли + свои voter'ы например реагирующие на ownerableTrait и т.п.
> Т.е. у вас фронтенда или нет вообще или же он наборот настолько сложный, что у вас там grunt и ко.
он не сложный но собирается не assetic
> с загрузкой нескольких файлов с предпросмотром и возможностью удаления файлов на лету?
недавно такое делал, прекрасно делается своим типом форм и сущностью File, загрука асинхронная — в форму по сути приходят только id загруженных файлов, на doctrine events идет подсчет ссылок на каждый файл, по крону файлы удаляются
(если совсем с 0 делать то на пару дней работы, потом еще в других проектах можно использовать будет)
> PHP не настолько плохой язык, чтобы говорить такое.
ну вот опять, это все размыто, такой, не такой, хороший, плохой.
Давайте так — если есть реальные примеры (вроде загрузки файлов), можем устроить тут мини-филиал stackoverflow.PerlPower Автор
20.04.2015 12:28-1О, спасибо. Вы напомнили мне о том, что в Symfony есть Voters. Еще одно живое подтверждение того, что книга незапоминаема.
недавно такое делал, прекрасно делается своим типом форм и сущностью File, загрука асинхронная — в форму по сути приходят только id загруженных файлов, на doctrine events идет подсчет ссылок на каждый файл, по крону файлы удаляются
(если совсем с 0 делать то на пару дней работы, потом еще в других проектах можно использовать будет)
Вам не кажется что то, что вы описали — слишком сложно для загрузки файлов? Если нет, то скажите пожалуйста где вы работаете и на каких проектах, и какова их частота? Какие фреймворки до этого использовали и как долго?
Давайте так — если есть реальные примеры (вроде загрузки файлов), можем устроить тут мини-филиал stackoverflow.
Любая проблема имеет решение, но мой посыл в том, что Symfony изначально создает очень много проблем, которые не будь ее решать бы не пришлось.Fesor
20.04.2015 12:36+1Вам не кажется что то, что вы описали — слишком сложно для загрузки файлов?
просто для загрузки файлов — да, сложнова-то. Но вы же не просто кейс «выбираем файл — загружаем» предложили. Там уже есть жирный фронтэнд. Ну или предложите свое решение.
Symfony изначально создает очень много проблем
Symfony не создает проблем, проблемы создают люди. Ну и опять же, может вам стоило тогда посмотреть в сторону Laravel? 5-ая версия (если в нее вклинить доктрину) выглядит весьма ничего.
neolink
20.04.2015 13:04Не кажется. Сложность оценивать нужно прежде всего по тому как это используется (теги не разрешено, уж извините):
/**
* это вынесено в трейт, но в принципе без разницы
* ORM\ManyToOne(targetEntity=«StorageBundle:Bucket», cascade={«persist»})
* ORM\JoinColumn(name=«bucket_id», nullable=true)
*/
private $files;
// а это в форму
$builder->add('files', 'storage_bucket', [
'label' => 'Файлы',
]);
// в рендере форме ничего дополнительно не нужно (js подключится сам, css соберется в один файл), а вообще обычно просто {{ form_widget(form) }}
по моему достаточно просто, этот пример кстати со стороны браузера требует только jquery.fileupload
я по НДА не могу говорить про проекты над которыми тружусь, но full time если вы о этом. Ну и к истории про адовость Symfony это имеет мало отношения.
> Symfony изначально создает очень много проблем
Symfony Framework это уж извините за тавтологию фреймворк, он не то чтобы создает проблемы, он их решает, создавая определенную инфраструктуру, чтобы вам уже реальные проблемы бизнеса решать проше было.
Да поначалу кажется что всё не так, но читайте исходники, книги и много станет понятнее, зачем и почему оно так сделано.
Не припомню случая, чтобы мне пришлось что-то прям сломать в symfony — любой компонент можно переопределить расширить и т.п. в этом и прелесть, ну и как с любым другим фреймворком с ним надо дружить, а не воевать.PerlPower Автор
20.04.2015 13:24-1Сложность оценивать нужно прежде всего по тому как это используется
Это очень сильно зависит от характера работы. Иногда затраты на реализацию могут не окупить повторного использования, иногда могут. Поэтому мы плавно переходим к:
Ну и к истории про адовость Symfony это имеет мало отношения.
Когда я месяцами активно работал над проектом с Symfony у меня в голове появлялась уверенность, что фреймворк очень хорош и на нем возможно все, и при большой интенсивности работы то что ты нагуглил просто не успевало вылетать из головы. В таком режиме фреймворк можно эффективно использовать. А вот в режиме вялой поддержки требуется слишком много телодвижений даже для простейших правок.
Другой пример — я каждые полгода-год кочую с проекта на проект, я не знаю какой будет уровень команды в новом проекте, какая версия фреймворка, какой политика в отношении сторонних бандлов, и конечно же не знаю характера проекта. Или я прихожу в большой проект и там пишу тесты или делаю мелкие правки — все уже решено до меня. В таких условиях делать что-то реюзабельное бессмысленно. Но если вы работаете в веб-студии, и точно знаете что вы будете делать завтра и видите, что ваши проекты однотипны, то тут ситуация другая.
Если вы сидите на зарплате, то можно не напрягаясь улучшать код, изучая как бы получше это сделать в Symfony. Если у вас почасовая ставка, то вам просто не выгодно тратить время на изощренности и нужно сделать максимально просто.
Так что хотя бы примерное описание характера вашей работы даст ответ на вопрос кому подходит Symfony.neolink
20.04.2015 13:41если это такой соц. опрос, но стоило бы его голосованием вынести, вроде «использую symfony, работаю в веб студии, нравится» и т.п.
зачем однотипность проектов, для нормальных решений — переиспользовать код можно даже в рамках одного проекта. Конкретно про файлы — от Symfony тут только формы и без симфони я делал бы ровно тоже, потому что перемещать файлы из модели это моветон, делать это каждый раз в контроллере тоже.
Ну и нормальные события вроде — «у нас сохранились новые файлы», позволяют добавлять действия вроде, а давайте добавим текстовый индекс на эти файлы, а для docx ещё pdf вариант для скачивания.
«День потеряем, за час долетим!»
neolink
20.04.2015 12:07+1> Как не части фреймворка?
не часть, github.com/symfony/symfony/search?utf8=%E2%9C%93&q=assetic
symfony-standart это такой example, вы же добавляете туда зависимости, почему их нельзя оттуда удалять?
> Выходит для дампинга компонент зря добавили, а симфонию пишут те, кто не умеет пользоваться отладчиком?
это в вас обида говорит, а добавили чтобы было и для тех кто отладчиком не пользуется
> тут нужно еще помнить как эти куски бойлерплейта взаимодействуют между собой.
Если приведёте пример будет проще, я начинал работать с symfony летом 2010 года, на стадии alpha версии, тогда ни документации ни форм в текущем виде не было. И symfony один из немногих фреймворков того времени исходники которого можно было бы читать без боли.
Если под рукой нет примера для copy-paste (а взять можно не только из проекта ведь, вся инфраструктура стандартизована можно из vendor взять), и знаешь что искать, то это просто гуглеж примера кода из доки.PerlPower Автор
20.04.2015 13:32-1Ну формально вы правы. Но 90% людей качают standard edition и на ней же потом и остаются. А искатели прекрасного, вроде вас, немногочисленны.
Если приведёте пример будет проще, я начинал работать с symfony летом 2010 года, на стадии alpha версии, тогда ни документации ни форм в текущем виде не было.
Пример был в статье — добавления поля формы.neolink
20.04.2015 13:53ну эти проценты с потолка, да и все остальные как бы не делают мир хуже, начали использовать фреймворк, уже хорошо. Может научатся новым штукам — если тебе что-то не нравится лучше же найти решение чтобы нравилось, ну или продолжать есть кактус.
про форму у вас смешаны 2 момента — добавление поля в модель и в форму, можно сюда еще написание миграций добавить и тестирование того что получилось.
опять же если у вас есть все данные то new FormType если нужны зависимости, то сервис. про рендер — если проект начинаю делать и контролирую я, то как я уже писал, рендер всей формы выглядит как {{ form_widget(form) }} (стилизация через form_theme — которые прекрасно оформляются списком он более общих к более конкретным для страницы/формы)
ну и хочется спросить — «а как вы хотели?», чтобы выполнить задачу нужно что-то сделать, что знают только прогеры, да если бы всё можно было бы делать без нас то профессия бы уже погибла
Fesor
20.04.2015 11:13Про dump() — начните пользоваться отладчиком.
если логика приложения сильно привязана ко времени — лучше dump-ом собрать как меняются данные и потом проанализировать.neolink
20.04.2015 12:21я обычно таймауты поднимал просто, все таки breakpoints удобнее ставить чем добавлять/удалять строчки var_dump() и т.п.
а так согласен в связке с профайлером можно же собирать без вывода
youlose
20.04.2015 08:21Судя по нику, у вас проблема не в Symfony, а в переходе с Perl на PHP, Perl более гибкий в плане синтаксиса и метапрограммирования и на нём можно писать более компактный и эффективный код. У PHP с этим всё существенно сложнее и корявость Symfony в основном обусловлена именно тем что ООП они скопировали с Java, я не знаю фреймворков на PHP на которых можно быстро и эффективно писать код как на RoR, например, они все даже на миллиметр не пододвинулись к его простоте и мощи. Наверное вам нужно или искать проекты на Perl или переходить на другие языки/технологии не связанные с PHP (предлагаю посмотреть в сторону Ruby + RoR (или Sinatra для маленьких проектов)).
PerlPower Автор
20.04.2015 11:09+1Синтаксис это дело десятое, у меня проблема со структурно-архитектурным подходом, который предлагает Symfony. Впрочем, судя по опросу, не только у меня.
Fesor
20.04.2015 11:15+1А какой структурно-архитектурный подход предлагает вам Symfony? Бандлы — можно и без них жить неплохо. Ну а все остальное — на откуп вам. Хотите SOA — на тебе SOA, хотите гексаганальную архитектуру — вот вам нате, CQRS — есть даже готовые бандлы добавляющую все что нужно, начиная с Doctrine2.5 можно перестать делать сущности как просто структуры с геттерами/сеттерами и начать делать дела нормально…
Нужно просто меньше сваливать на фреймворк и тогда можно жить.neolink
20.04.2015 12:26+1а про Doctrine2.5 вы что имели ввиду?
Fesor
20.04.2015 12:37До 2.5 в доктрине не особо удобно было использовать Value Objects. А теперь с этим все ништяк.
some_x
20.04.2015 09:00+1Позвольте вопрос со стороны: судя по статьям в мире php есть тенденция заимствовать подходы принятые в asp.net/java: DI, ООП, строго типизированный код (zephir) и т.д.
А почему не использовать ASP.NET/java, чего не хватает из того что есть в php?Fesor
20.04.2015 10:35+2Эта тенденция вполне себе объяснима. Объектная модель PHP сложа и по сути была позаимствована у Java/C# так что и практики из этих языков ложатся на пых очень хорошо. Статическую типизацию никто в PHP не добавлял, не путайте с тайп хинтингом. Зефир никакого отношения к PHP к слову не имеют. Лучше б они комилятор PHP7 strict mode замутили.
То есть перенос практик свойственных скажем Ruby, у которого своя специфика, в PHP, у вас батхерта не вызывает?
NightTiger
20.04.2015 10:07+3Статья сделала мое утро ) Тем не менее, хочу отметить, что фреймворк действительно весьма непростой, на изучение его принципов работы требуется весьма немалое количество времени. Но если вы постигли DI-контейнер, то это открывает колоссальные возможности по построению сложного и управляемого кода, что как нельзя лучше подходит для Enterprise-решений.
У меня имеется на руках колоссальный позитивный опыт использования этого фреймоврка для построения распределенной SOA-архитектуры в рамках компании — и можете мне поверить, что модульная архитектура и гибкость фреймворка являются важными критериями успеха не только IT-подразделений, но и бизнеса. Но за эту гибкость надо платить временем и нервами, потому что эффект от внедрения Symfony2 можно будет получить через несколько лет, когда вся команда выйдет на профессиональный уровень разработки.
P.S. Если у кого-то имеется желание разобраться в премудростях этого фреймворка — приглашаю в User-группу, а также на наши митапы, которые проходят раз в месяц в неформальной обстановке с пиццей и чаем )
beono
27.04.2015 11:30на наши митапы, которые проходят раз в месяц в неформальной обстановке с пиццей и чае
Точно раз месяц? Судя по твиттеру реже.
zk-zeka
20.04.2015 10:10+3А что это за проблема такая — «приходится заглядывать в документацию»?
Возможно ли выполнить любой (сколько — нибудь сложный) проект отключив доступ в сеть?PerlPower Автор
20.04.2015 10:40-5Проблема в том, что такие заглядывания в случае документации Symfony очень частые, и в том, что даже зная как сделать без гугления я все равно вынужден гуглить, чтобы писать код так как принято в Symfony. Т.е. большую часть времени приходится гуглить не информацию, а правила приличия. А если я не могу так долго запомнить эти правила, то они скорее всего контринтуитивны, что тоже не есть хорошо.
voidMan
27.04.2015 05:48Если бы каждый писал как хотел, проект в скором времени превратился бы в лоскутное одеяло :)
darkstar
20.04.2015 10:14+3Я тоже пытался поднять тему низкой производительности, разработки на symfony, как надо (ведь зачем писать в обход правилам и брать для это symfony), но проекты на symfony это рай для аутсорса, клиент сам настаивает на symfony, потом платит за оверэстимейты и сомнительное качество интерфейсов, утешая себя тем, что под капотом strong/production level/high quality решение. Этот самообман работает, очень похожие проблемы описывались в статье с критикой angularjs, и эта «замечательная» связка — UI на angular.js, а API на symfony очень популярная.
Все кто пишет на symfony знают, что основным источником решений является stackoverflow, потому что документация очень типовая, там практически все примеры это 2+2=4, разобрать гигантское кол-во абстракций очень долго(всмысле просто понять по коду), и зачастую знаешь как реализовать тот или иной функционал, но сначала надо сделать бандл, в нем конфиги, сервисы и т.д. К примеру Facebook API, бандл не поддерживается, используйте бандл, где 100500 адаптеров для oauth, намного проще просто через композер подтянуть последнюю версию sdk и сделать сервис-обертку, а конфиги прокинуть из parameters.yml, но ведь это не правильно…
dim_s
20.04.2015 10:16+1Со стороны кажется, что Symfony сложнее многих Java фреймворков (например сложнее Spring MVC). Есть ряд замечаний, особенно на счет форм. Многие фреймворки имеют функционал для форм из коробки и мне всегда приходится его выкидывать, при проектировании сложных форм. По мне, так лучше чтобы фреймворк вообще не предоставлял такой возможности из коробки. Assetic из того же ряда, фреймворкам нужно забыть о таком понятии из коробки, пусть этим занимаются более подходящие технологии на фронте, например grunt.
Fesor
20.04.2015 10:30+1Assetic я лично уже давно выкинул и заменил на gulp. Крайне неудобный инструмент этот ассэтик.
Что до Symfony/Forms — вот тут не соглашусь. Это пожалуй один из самых продуманных, но и самый сложный компонент всей симфони. Если в нем разобраться можно делать такие клевые штуки… и все это легко покрывать тестами и расширять.
faost
20.04.2015 10:53+1Когда Assetic появился в симфони frontend tools не были еще так популярны. Сейчас вполне логично использовать другие инструменты.
PerlPower Автор
20.04.2015 13:37-1Согласен с вами. Если бы было побольше таких людей как Fesor и neolink, то Symfony был бы по факту Symfony, а не Symfony Standard Edition. Но большинство идет по пути наименьшего сопротивления и в итоге если хочешь нормально зарабатывать и быть конвертируемым на рынке труда, то приходится ориентироваться прежде всего на использование стандартных компонентов.
Fesor
20.04.2015 10:26+5Хотя применение ORM такого как Doctrine в корпоративных проектах вообще крайне сомнительно — длинные запросы на DQL по десяткам таблиц это то, что не приснится даже в самых худших кошмарах.
Оукей, DQL по десяткам таблиц… давайте задумаемся что это значит. Это значит что на DQL где-то в каком-то репозитории у вас был жирный запрос. Именно в репозитории, а не в сервисах или контроллерах. Далее, в контексте DQL мы работаем не с таблицами а с коллекциями сущностей. И это круто, потому как то как у нас организованы данные в приложении может совсем не совпадать с тем что у нас творится в базе. Более того, отдельные таблицы могут вовсе храниться в других СУБД, хотя это уже немного другой лэвл. Ну и еще — если бы это была другая ORM сложность запроса видимо бы не изменилась, и у вас была бы куча любого другого DSL, кучи вызовов билдеров, кучи SQL для решения этих проблем. То есть проблема доктрины явно не в этом.
А теперь давайте о том, что нам дает доктрина в противовес Active Record:
— persistence ignorance и POPO (Plain Old PHP Objects) — ваши сущности ничто иное как объекты вашего приложения и им крайне плевать кто и как и где их хранит. С точки зрения приложения, вы один раз на всю жизнь этой сущности сделали ей new MyEntity и половижили куда-то в память, периодически подергивая их от-туда. Все взаимодействие с хранилищем данных происходит в репозиториях, и вы можете определить свои репозитории со своими интерфейсами. Так, если внезапно вы захотите сменить хранилище — у вас только один слой который потребуется менять. Все остальное можно оставить без изменений. То есть наша логика работы с данными полностью отделена от слоя хранения данных.
Единственное что до версии 2.5 доктрины можно было нормально работать только с анемичной сущностью, так что реальные плюшки POPO, а именно использование Value Object-ов можно получить только обновившись на 2.5. До этого что-то серьезное чисто на энтитях доктрины, ровно как что-то серьезное на Active Record, сделать можно было, но только с болью и только объявив кастомные гидраторы и т.д.
— unit-of-work — это то, чем не умеет пользоваться подавляющее количество разработчиков на Symfony. Грубо говоря идея то проста, логика нашего приложения ничего не должна значть о том, что там как потом надо хранить между запросами. И на помощь приходит UoW, который запоминает с какими сущностями мы работали, и при flush пытается понять что ж мы там сделали с ними и что надо делать в базе (обернув все это в транзакцию). Если упростить — UoW предоставляет нам область сущностей являющуюся агрегатом. Приложение работает с какой-то сущностью, та дергает методы у себя и у связанных сущностей, и потом, в самом конце (я обычно это делаю перед отправкой респонса на ивентах системных) делают flush всех изменений.
Ну то есть если вы пишите блог, то да, Active Record будет проще. А если у вас приложение со сложной бизнес логикой, постоянно меняются требования, то вам нужны Data Mapper, Unit-of-work и еще чего про DDD почитать.
С Active Record большие приложения делать тоже можно, но тогда модели AR будут не более чем DTO для данных между моделью и базой.
Если вы таки помните все это наизусть, то поздравляю — у вас феноменальная память.
ну я из вашего списка помню только то с чем работал последним. Аннотации я использую только в контроллере, для мэппинга мой PhpStorm может даже что-то подсказывать (плагины), хотя обычно я просто не парюсь и гуглю. У меня это занимает не так много времени а забивать голову всякой сущью я не хочу.
Изоляция компонентов по файлам и указание зависимостей одних компонентов от других тоже со временем превращается в головную боль.
И тут единственный плюс Laravel который я для себя нашел — нормальный IoC. Справедливости ради стоит заметить что заменить DIC в симфони более чем реально, можно поставить PHP-DI и радоваться автоконфигурации и т.д. Можно написать compile-pass для стандартного DI что бы тот собирал все зависимости и ругался только если сам не может разрулить все… а обычно у него есть достаточно инфы что бы все самому разрулить.
Что до конфигов — они полностью отделены друг от друга и это хорошо. Есть еще идея unified resource discovery которую проталкивал автор symfony/forms, но я как-то не слежу за этим.
Для бизнес-логики это, на мой взгляд, вызывает излишние сложности.
Да ну? Вообще ваша бизнес логика должна быть максимально отделена от фреймворка, а так для нее действуют все те же правила. Мне кажется у вас реально какое-то испорченное виденье мира. И вот этот вопрос стоило бы раскрыть чуть больше. Что для вас бизнес логика и где она должна лежать?
Короче мой посыл — нет в мире совершенства.PerlPower Автор
20.04.2015 11:22-1Это значит что на DQL где-то в каком-то репозитории у вас был жирный запрос. Именно в репозитории, а не в сервисах или контроллерах.
Раньше я тоже писал в стиле «контроллер дергает репозиторий, репозиторий делает запрос», но там в репозитории я мог использовать SQL, что многое упрощало. В Symfony я делаю то же самое, но на куцом языке запросов. Расширять этот язык целое дело. Все остальное, что вы написали я вообще не знаю тут причем.Fesor
20.04.2015 11:35+2ну вы можете и SQL внутри репозиториев использовать. Просто это сложнее, так как с DQL вы оперируете именно коллекцией объектов, не сильно завязываясь на архитектуру базы данных. Что до расширения DQL… ну… не соглашусь… Это не так часто нужно обычно. Можете привести кейс когда этот самый DQL вам мешает? Скажем мне приходилось расширять DQL только когда нужно было использовать очень специфичные вещи из СУБД или для DRY (например работа с координатами, но выходили вполне себе реюзабельные решения, один раз сделал, покрыл тестами и просто подключаешь из проекта в проект если нужно).
PerlPower Автор
20.04.2015 12:48-1Можно, но порицаемо. Про завязанность на архитектуру БД, проекты которые переросли фазу прототипирования очень, очень редко меняют движок БД. Возможность легко сменить СУБД очень переоценена.
По поводу примеров — специфичные функции для СУБД, да.
Вы лучше расскажите где вы работаете и какой поток проектов какого размера через вас проходит?
hanovruslan
20.04.2015 10:30+3Без конкретики сложно (нужно ли вообще?) комментировать боль, которая добре разлита в данном посте, поэтому попробую сосредоточиться на чем-то конкретном.
Про гугление
В условиях, когда инет толстый и документация постоянно обновляется (что не совсем правда про библиотеки и фреймворки), чтение документации постепенно и уверенно прячется за фасадом «погуглить». Я лично четко наблюдаю подмену понятий, найти решение <-> где-то по гуглиить. Типичные задачи, которые описаны в блоке «Symfony-only developer», решаются знанием документации с сайта самой симфони и с доктрины. Не уверен, правда, насчет загрузки файла. Разработчики обоих систем предоставляют онлайн и оффлайн документацию. Далее всё сводится к необходимости\умению команды прикрутить конкретные компоненты к приложению.
Про кастомизацию
Старое доброе «вы просто не умеете их готовить» про сущности, связанные с БД. Думаю, бОльшая часть разработчиков (на любом языке программирования), использующих модели, которые связаны с каким-то постоянным хранилищем, согласится, что активная бизнес-логика (типа, юзер\статья сделай что-то поленое и сохранись), не должна (не «не может») располагаться в подобных моделях. Это логичнее и удобнее держать в сервисе, который несет ответственность за данную часть DSL. В терминологии symfony — это сервис, который непосредственно связан с определенным ресурсом приложения. Отсюда и «проблемы». Сделайте\используейте подходящий сервис, который инкапсулирует в себе нужный репозиторий и менеджер моделей, и не надо будет делать такой крюк с переопределением вендорных сервисов
Про сложности symfony
Компонент security пока что лично у меня вызывает боль. Как и Form. Но тоже относительно. Заявленные возможности работают как описано в документации. Если есть необходимость часто использовать динамические формы, то, наверное, имеет смысл подумать о написании своего бандла, который будет в себе инкапсулировать вашу боль.
Я до сих пор имею к стэку компонентов symfony (кроме уже озвученных security и form) только одну претензию: Контроллеры не являются честными сервисами. Нельзя просто так взять и переопределить какой-то контроллер со своими экшенами. Надо либо использовать compiler pass, либо перегружать бандл. Может быть, можно как-то перехватить постоение стэка роутов и внедриьт туда свой перегруженный контроллер\экшен. Конечно же, это не так, если используется бандл, контроллеры в котором пеут быть перегруженными (Sylius). И всё равно, это не мешает использовать symfony.
Если абстрагироваться от конкретных возможностей фреймворка, я думаю, что успех symfony не в последнюю очередь связан с DSL уровня обобщенного приложения (веб, консоль, демон). Речь не о full stack приложении, а о наборе компонентов.Fesor
20.04.2015 10:41+5Добавлю еще… Symfony был первым фреймворком на базе компонентов. Более того, авторы позицианируют сам фреймворк как просто надстрока над этими компонентами, вы можете спокойно на базе этих компонентов собрать свой фреймворк. Скажем тот же Laravel основан на компонентах Symfony. Именно разбиение на компоненты привело к созданию composer-а, и это дало большой толчек в развитии PHP сообщества. И инвестировали средства не в фреймворк а в экосистему, то есть развитие компонентов и инфраструктуры.
hanovruslan
20.04.2015 11:09«контроллеры в котором пеут быть перегруженными» => «контроллеры в котором вполне вероятно могут быть перегруженными»
hanovruslan
20.04.2015 10:56-1А я еще добавлю ) но это больше к самому PHP относится, а не к symfony. Мне не очень нравится, что на расширение DSL как правило надо писать несколько новых классов + провязывать их в DI. Хотя скорее всего, это связано с моим уровнем программирования (сейчас запоем читаю paulgraham.com/articles.html ). Вероятно, в большом долгоиграющем приложении есть шанс и необходимость писать такие сервисы или даже компоненты, которые из конфигурации приложения обеспечат ядро приложения + надо будет на базе их (своих компонентов в частности и вендорных вообще) реализовать какие-то исключительные случаи.
skobkin
20.04.2015 11:39+1Очень хочется поинтересоваться (именно поинтересоваться, а не саркастически спросить) у тех, кто голосовал за то, что Symfony неоправданно усложнена, почему они считают, что она усложнена именно неоправданно?
PerlPower Автор
20.04.2015 13:06В смысле что сложности с ее изучением не оправдывают той эффективности, которую она приносит.
Fesor
20.04.2015 15:13все проблем из-за отсутствия рефакторинга и ретроспективы, а не фреймворка. Все стараются продумать все наперед, это выходит тольк оооочень простыми задачами. Ну и естественно все на свете должен решать фреймворк а не разработчик, это тоже я считаю довольно распространенной и ошибочной идеей.
faost
20.04.2015 11:54+4несмотря на его адову кривизну в 2011 году
У меня крутится проект, который я делал на какой-то RC-версии в 2011, успешно поддерживал его раз в месяц добавляю функционал и через пару лет в (2013) перевел на LTS 2.3 буквально за пол дня. Вы о чем вообще?
Но Symfony подразумевает огромные времязатраты на обучение, есть вполне официальная занудная книга по ней, которая раскрывает тонкости чуть менее, чем никак.
Занудная книга? Вы об этой доке или о чем? Читал множество мануалов по разным фреймворкам и языкам и дока симфони — одна из лучших что я видел, все четко и написано простым языком.
Т.е. сами формы вещь отличная, но вот переход от простого фронтенда к сложному не продуман
Мы же говорим о фреймворке для серверного языка или я что-то путаю? Для фронтенда используются как бы другие технологии.
компонент для дампа рекурсивных структур данных появился только в версии 2.6, уже после выпуска первой LTS ветки
Меня вот с 1го семестра учили пользоваться отладчиком. Вот вы своим дампом распечатали что-то и поняли что вам нужны данные на несколько вложенностей выше — как вы это вообще делаете? print_r + die до победного конца втыкиваете?
В отладчике переключился в стеке вызовов куда нужно, посмотрел значения переменных нужных, через watch попробовал другие варианты.
Ну и погуглив 5 мин нашли бы Ladybug тот же, ему уже года 3.
Для круда Symfony Forms божественны, для CRUD с парой-тройкой динамический полей они терпимы, для сколько-то серьезной клиентской логики форму проще выкинуть и спроектировать заново. Валидацию и сохранение данных переделать придется тоже.
Формы вообще одна из самых сложных тем для любого веб-фреймворка. Эти две ссылки покрывают 98% вопросов по формам в Symfony.
И кстати что не так с валидацией и что за проблемы с сохранением данных?PerlPower Автор
20.04.2015 13:47-7
Это походу бесполезно. С фреймворком все отлично, не обращайте внимания, я не осилил.faost
20.04.2015 15:45Пишите статью на 23к символов, но не можете осилить комментарий к ней на 1.8к (с учетом цитат)?
PerlPower Автор
20.04.2015 15:54-1Ваш комментарий можно свести к «у меня все работает» и «так и должно быть». У меня ситуация противоположная — работает не все и я не считаю, что так должно быть. Ну и о чем тут говорить?
redc0de
20.04.2015 12:37Коммьюнити сказало мне, что у меня низкий уровень интеллекта из-за чего я не способен эффективно оперировать сложными абстракциями
Сомневаюсь. Коммьюнити все таки заинтересовано во фреймворке и самом коммьюнити тоже как ни странно, если там всем будут говорить что кто-то умственно отсталый, то все уйдут делать свои велосипеды с блекджеком и сертификатами.
Что автор думает по поводу DX-initiative, которая добавляет некоторые плюшки, тем самым делая многострочные и толстые моменты — более тонкими? По сути дела это облегчение жизни как разработчикам так и постигающим сабж
И да что же насчёт REST сервисов на symfony? Формами пущай занимается фронтэнд, про ассетики можете забыть — они не нужны более (терпеть их не могу ибо всегда натыкаюсь на проблемы), можно прикрутить там какой-нибудь пропель если не нравиться доктрина и жить себе на здоровье. Вполне себе ничего.
JSmitty
20.04.2015 12:54Комментарии симфонистов хорошо иллюстрируют тезисы автора о сообществе.
Далёк от всех разборок по фреймворкам, но, у Вас замечательный слог, думаю, стоит попробовать себя хотя бы в жанре публицистики.neolink
20.04.2015 13:13ну да, то есть (ардуино из ваших тегов взял):
— я пишу статью ардуино отстой, я пытался делать как раньше делал — припаялся прямо к ногам МК сжег 2 платы, на форуме сказали что я делал не правильно — «зомбированные сволочи!»
— в комментариях мне пишут постой, есть же распаянные площадки используй их.
— ага вот видите они и тут меня достали!PerlPower Автор
20.04.2015 14:03+1Ну смотрите сами, 2/3 считают что симфония могла бы быть и попроще. Я тоже. Возможно мы просто своими мозгами не дотягиваем до уровня этого фреймворка, такое бывает. Но ведь если комфортно может пользоваться технологией только треть от программистов, то это плохо. Perl и Scala — замечательные языки, но у многих они вызывают сложности, что делает их непригодными для промышленной разработки в той мере как более простые PHP и Java, потому что язык на котором тяжело найти программиста не будет популярен у заказчиков. Symfony это даже не всегда enterprise, это оголтелое крудолепство, а выглядит так будто мы ракеты в космос запускаем.
neolink
20.04.2015 14:22Но опять же если делать проще, то тогда 1/3 прогеров скажут что им приходится ломать всё чтобы делать крутые штуки, тут всем не угодишь.
На проекты обычно и берется команда в которой разные прогеры, совсем уж мясные части с кучей неявных зависимостей делают сеньеры или лиды (например для распределенных команд). Штуки про crud джуны, мидлам можно сказать посмотри я там делал, можешь также сделать.
В том что в Symfony пытаются видеть аналог друпала (cms, чтобы сразу были ответы почти на все вопросы), частично виноват и Фабьен (недавно вообще предлагал исталлятор(!) для php фреймворка на go (!) написать) — по хорошему она не должна отвечать на все вопросы, Symfony Framework стандартная инфраструктура, это клей для кода, прежде всего стороннего кода.
Для CRUD есть генераторы и публичные штуки вроде SonataAdminBundle, но у нас обычно либо стандартный CRUD либо спецефичные обертки для проекта.
В самом простом случае в форме описал что нужно редактировать (просто списком, тип подставится от валидатора), в контроллере 20 строк стандартных добавил, просто поменяв type hints для экшенов, в шаблоне, 2 блока — заголовок страницы и form_widget, по сути во внутренних сервисах у нас так и написано.
Zeliret
20.04.2015 13:25+2Пишу на Silex последнее время. Использую компоненты Symfony2. В общем и целом автор прав. Симфони ужасно сложная. И дело не в пороге входа, а именно в количестве абстракций, паттернов и т.д. Тяжко в общем и целом.
У нас вообще проект небольшой, поэтому сайлекс + некоторые компоненты на сервере — ок. А клиент можно делать на всяких Angular/Ember. Тогда можно выкинуть шаблонизаторы, формы, аскетик и т.д.
В общем тот же зенд такой же монстр.
Мне кажется, что создание фреймворка для всего, но который будет проще пареной репы — утопия.
hospect
20.04.2015 14:34можно было бы выкинуть Assetic, Forms, Doctrine, а также Good Practices и использовать как Symfony как нормальный микрофреймворк из коробки
Именно для этих целей был создан Silex. Другое дело, что на склеивание нужных именно Вам частей симфонии также уйдет время (и это вполне возможно вызовет гугление и последующий баттхерт). Плюс дока этого микрофреймворка не обновлена для 2.0 пока.
И да, спасибо за статью. Холивар получился вполне неплохой :)
AmdY
20.04.2015 14:38Долго искал идеальный фреймворк, писал свои, но с годами пришёл к простой для меня истине — выбирать надо не лучшее, а наименее противное. Нужно выбросить свой перфекционизм и начать жить.
Статья очень хороша, пригодиться для тех, кто рвётся к symfony любой ценой, хотя левел не позволяет и пишут на нём как на yii. На поддержку приходил проект на SF1, ребята не осилели доктрину, подключили котеровскую либу для работы с БД, но часть команды видимо и её не осилило, наклепали запросов без плейсхолдеров с данными прямо с GET. Дело не во фреймворке, а в руках и головах тех, кто с ними работает.
ZhukV
20.04.2015 16:18+1Очень даже интересное высказываения.
Все верно, Symfony2 очень плохо подходит для мелких сайтов, таких как блоги, сайти визитки. Но уж здесь простите, тогда только WordPress Вам сможет помочь.
Очень интересны высказывания автора, а именно:
В попытках сделать архитектуру фреймворка максимально гибкой была нагорожена тонна абстракций, требующих бойлерплейта и времени на то, чтобы заставить полезный код работать в рамках этих абстракций.
Есть пара паралельных вопросов:
1. Работали ли Вы с компонентами (как Вы пишете с абстрактными) RoutingLoader, FirewallListener, ControllerParser, AsseticLoader, etc..., которые очень хорошо грузят динамеческие ресурсы? Или Вы предпочитаете по старинке все это грузить с одном файлике (environment.php)?
2. Использовали ли Вы DependencyInjection на всю его мощь (Extension system, Compiler Pass)?
Избавиться от этого нет никакой возможности — отход от стандартной идеологии крайне не одобряем сообществом.
Да, здесь с этим не поспоришь. Ну ведь верно. Или Вы хотите получить точно тоже, что было с Zend, когда берешь проект, а там… вообще не понятно, что где, и как оно вообще работает. Здесь же есть жесткие правила, и если мне дадут новый проект на СФ, то я точно буду знать, где что находиться.
Если вы захотите выкинуть Doctrine из своего проекта, то вам придется потом долго и нудно объяснять каждому встречному, почему вы это сделали под укоризненное качание головы
Откуда Вы это взяли? На самом деле, очень много кто выпиливает ее в своих проектах. Да и объяснять не надо. Вы бывали на конференциях по Симфони (SymfonyCampUA к примеру)? Лично я могу сказать, что нет, так как этот вопрос там очень часто обсуждается и все только уши раскроют и будут слушать как Вы это сделали!
Даже для незначительных изменений приходится ворошить кучу файлов. Например, если вы добавляете в форму поле, для этого нужно:
Хм… Если все для Вас так плохо, тогда наверное надо посмотреть на ряд других фреймворков, которым нужно только указать названия поля и тип, и а то, что там объект, вас абсолютно пофигу… А не задумывались на счет того, зачем это сделано?
Ну и напоследок:
Я знаю, что мне сейчас здесь просто… будет, и куча минусов, НО! Автор, дайте ответ пожалуйста:
1. Какой самый большой проект на PHP Вы сделали за всю свою жизнь? Фреймворк значения не имеет.
2. Работали ли вы с DDD? Именно вот здесь очень круто ляжет и формы, и свои типы в доктрине которые Вы так «обосрали» в своем посте.
3. Использовали, или даже «Изучали ли» EDA А ведь практически вся СФ на нем устроена, и Вам нет необходимости влезать в «ядро», чтобы добавить свою логику на любом этапе.
P.S. Эта тема скорее принесет куча холивара, который можно услышать на каждой PHP конфе, чем реально какую-то пользу определенным людям, да и принесет куча негатива начинающим в СФ, которые еще пока стоят на распутье дорог. Автору ресспект за столько текста, а вот к сожалению, реального смысла статьи я так и не увидел…
PerlPower Автор
20.04.2015 16:59Вообще-то Symfony я только и использую для всякой мелочи — когда поддерживаешь сайт сам, то не должен перед кем-то отчитываться что и как ты делаешь.
Описанные вами компоненты кроме FireWall Listener я не использовал. DI я использую чтобы получать нужные мне сервисы. В кишках фреймворка не копаюсь. Использую стандартные 2 environment.
Про DDD и EDA впервые слышу, наверное это очередные общие концепции, которые каждый понимает как хочет и притягивает за уши к своему опыту.
А не задумывались на счет того, зачем это сделано?
Очень хороший вопрос. Symfony обобщает опыт разработки Фабиена и его взгляды на то, каким должен быть фреймворк. Люди могут ошибаться, или пытаться объять необъятное, или пытаться сделать кальку с джава-мира, или же вообще вынашивать планы по подсаживанию на свой сложный продукт.neolink
20.04.2015 17:11по поводу видения Фабьена это не совсем так, многие вещи сделаны другими людьми github.com/symfony/symfony/graphs/contributors
вообще открытость к принятию чужого кода тоже явилась немаловажным фактором успеха
Fesor
20.04.2015 17:15+3Про DDD и EDA впервые слышу, наверное это очередные общие концепции
Это печально… Но вполне логично. Скажем если вы никогда не слышали о DDD то значит и проектов со сложной бизнес логикой у вас небыло. А если так, то избыточность Symfony вам не нужна. И лично для вас, для ваших задач, Symfony это большой оверхэд.
Про DDD можете либо почитать Эрика Эванса, либо в качестве тизера (да и просто посмотреть что еще предлагает народ) посмотреть что-то вот из этого: раз, два, три.
Вообще оставлю тут ссылочку… github.com/phptodayorg/php-must-watchPerlPower Автор
20.04.2015 17:27Ну или это значит, что я простой исполнитель, которому спускают уже формализованые требования, дают тикеты в Jira и т.п.
А вообще поделитесь что вы понимаете под сложной бизнес логикой?
neolink
20.04.2015 17:43+1Вы бы не поленились и написали аббревиатуры полностью — Domain-driven design и Event-driven architecture, может люди бы меньше пугались.
И кстати прелесть всех design/architecture что:
— даже не слышав о них ты можешь им следовать, как чисто сам (менее вероятно), так и подталкиваемый выбранным инструментов (например фреймворком)
— если где-то не попал можно найти другой design/architecture и сказать, что тут сознательно выбрал (и почти не соврал) т.к. «нет в мире совершенства»
ZhukV
20.04.2015 17:08+1Вообще-то Symfony я только и использую для всякой мелочи
Вы уж простите, но мне кажеться, это и есть самая главная проблема. Так как Симфони совсем не для мелочей. Имхо.
Описанные вами компоненты кроме FireWall Listener я не использовал. DI я использую чтобы получать нужные мне сервисы. В кишках фреймворка не копаюсь. Использую стандартные 2 environment.
Не пожалейте время, и все таки попробуйте их заюзать. Тот же самый DI в разрезе Compiler Pass. Готов заверить, впечетления улучшаться.
Про DDD и EDA впервые слышу, наверное это очередные общие концепции, которые каждый понимает как хочет и притягивает за уши к своему опыту.
Да, все верно, это общепринятые концепции, но на этих основах заложена вся система. Вы много чего не могли понять, как оно работает, в большинстве случаев просто потому, что не понимали, что это за концепция.
Symfony обобщает опыт разработки Фабиена и его взгляды на то, каким должен быть фреймворк.
Мне кажется, что Вы здесь ошибаетесь. Очень много на Packagist пакетов, с очень даже похожими архитектурами.
P.S. Лично мой Вам совет: покопайтесь в нем на большом проекте, а не пилите какие-то «мелочи». Для мелочей есть совсем другие подходы. Имхо, Симфони это монстр, и Ваша попытка прировнять Льва к мыши, думаю недопустима.PerlPower Автор
20.04.2015 17:18-1Вы уж простите, но мне кажеться, это и есть самая главная проблема. Так как Симфони совсем не для мелочей. Имхо.
Вы не поняли Symfony я использую для мелочей и для основной работы — у меня есть опыт работы на ней в больших проектах. Во всяком случае в средних.
Не пожалейте время, и все таки попробуйте их заюзать. Тот же самый DI в разрезе Compiler Pass. Готов заверить, впечетления улучшаться.
Я раз в год освежаю свое знание Symfony Book, поверьте, если бы я бы столкнулся с тем, что мне может пригодиться на практике, я бы это применил.
В общем ваши советы мимо.
Suntechnic
20.04.2015 18:25Чем дальше, тем чаще мне начинает казаться, что ООП вообще не подходит для web'а. Я не знаю что подходит — я не теоретик, но вот такое вот ощущение есть.
Что же касается форм, то нормальной работы с ними я не видел нигде. Был на моей памяти один проект, где был полностью самодельный фреймворк созданный автором и там было некое приближение к тому, что можно было бы назвать удобным на практике с некоторой натяжкой, но не более того. Может кто-то подскажет в каком фреймворке работа с формами проста и удобна?
prolong
20.04.2015 23:55+8Я также наверно из тех, кто тоже считает, что symfony2 — это лучшее что случилось на данный момент с php :)
Считаю выбор symfony2 оправдан для проектов с большим жизненным циклом разработки и поддержки,
на мой взгляд все проблемы большого входного порога надуманы и с лихвой окупаются стоимостью поддержки кода в дальнейшем.
Слабо связанная архитектура основанная на di делает разработку и отладку удовольствием. Паттерны используемые в симфони это же плюс, а не минус :))
Тут уже не однократно говорили, что если пугают тонны абстракций то можно посмотреть в сторону того laravel (symfony2 с человеческим лицом)
Про себя могу сказать, что на реализацию типового проекта на symfony2 или на любом другом более простом фреймворке у меня уйдет примерно сопоставимое время. Однако на поддержку и развитие проекта на symfony2 будет уходить на порядок меньше времени.
karser
21.04.2015 20:59+3Я уже давно смотрю на симфони как набор независимых компонентов и инструментов, которые повсеместно используются и в других php фреймворках, и это очень хорошо.
Если кажется, что SymfonyStandard слишком громоздка, ничто не мешает создать composer.json в новой директории MySimpleSymfony и добавить туда только то, что считаете нужным.
Бывало, начинал проект в Silex и потом там получался симфони =)
shoomyst
26.04.2015 13:48+2Вот блин, такой эпичный тред пропустил.
Мои 5 копеек:
Пост полезен, что поднимает данную тему — фреймворк подойдет далеко не всем, есть достаточно верные заключения — сложный security (к слову разрабы фреймворка даже сами советуют НЕ использовать сложный ACL), ОЧЕНЬ сложный компонент форм для форм с более чем пятью простыми полями, ассетик это страшный фейл на сегодняшний день, когда есть grunt/gulp, но на небольших проектах еще терпим.
Решение (многое уже озвучено):
* Не используем ACL. Если совсем радикально — написать свой слой security — при всей бредовости этой идеи, но для больших проектов мне видится это неплохим решением: можно решить проблемы с UserInterface, в котором зачем-то обязательным сделали username и прочие бредни. Ну и при ровных руках собственное решение должно быть посекьюрнее, т.к. в отличие от стандартного компонента вашу реализацию никто не будет знать. Но это решение отсекает использование бандлов, которые завязаны на стандартный security.
* По формам сложно что-то советовать — либо разбираться (проще всего по исходникам), либо менять подход при работе с формами. При всей сложности этого компонента он тем не менее является МОЩНЕЙШИМ инструментом, но не все успевают это осознать прежде чем проклясть его.
* Слежу за тегом symfony в тостере, очень много вопросов по доктриновской орм. В своем проекте я его благополучно выпилил и использую только DBAL. Вообще считаю, что orm это первый кандидат на выпил в сколько-нибудь большом проекте: он очень удобен, но когда-нибудь вся эта магия вылезет боком.
В общем все ваши жалобы решаются выпилом всего, что вас не устраивает и написанием своего, и это неоспоримое преимущество Symfony, который собственно с такими идеями и проектировался. Многие справедливо упрекнут: нафига такой фреймворк, в котором надо что-то выпиливать и писать свое. На это я могу ответить тем, что нет ни одного языка/фреймворка, который бы устраивал абсолютно полностью, и тут есть 3 варианта: менять фреймворк, страдать, используя стандартный компонент или заменять стандартный самописанным. Если вы выбираете последний вариант, то попробуйте это проделать в сильносвязанном фреймворке — вы быстро поймете, зачем нужна вся эта абстракция и академичность в архитектуре.
Вожусь с симфони года с 2012, перелопатил код большинства компонентов, но до сих пор не могу сказать, что вижу цельную картину происходящего :)
От себя добавлю еще: на фоне остальных сложноват компонент Config в связке с DIC, сам DIC достаточно сложен, но очень функционален. Периодические проблемы с Intl/Locale, вроде как незаметные для конечных разработчиков, но что-то у Бернхарда там постоянные проблемы с ICU :)
Ну и в заключение скажу, что всегда говорю по этой теме:
Не все смогут писать на симфони и понять его. Тут должно быть особенное мышление (звучит словно я пишу о некой элитной касте разработчиков :)), но то же касается и ZF — просто должно что-то щелкнуть в голове и тогда можно будет проникнуться их философией. Если ты пишешь на Yii и тебе это нравится, большая вероятность, что ты не поймешь Symfony/ZF. Верно и обратное: если проникнулся Sf/ZF, сложно будет работать с Yii/Kohana/… Мне как-то довелось поддерживать проект на Yii — это было больно и опасно для моей психики. Это не значит, что я пытаюсь как-то унизить Yii-разработчиков, а просто хочу сказать, что и у всех просто разные взгляды/задачи в данный момент времени.shoomyst
26.04.2015 13:56Хотел еще добавить про итоги голосования: лишь единицы тут могут объективно оценить оправданность усложнений (себя я к ним не отношу) — это надо быть как минимум активным участником комьюнити, а лучше контрибьютором, следить за всеми обсуждениями на гитхабе/irc/твиттере.
А так это голосование тех, кто пишет на симфони против тех, кто не смог разобраться в нем за один воскресный вечерPerlPower Автор
26.04.2015 15:09-1Хорошее мнение, жаль конечно, что оно аппелирует к авторитету, как и вообще практически вся риторика в пользу Symfony. И к сожалению аргументация вида «видишь проблемы — значит не осилил» неопровержима в принципе, что попахивает демагогией.
neolink
26.04.2015 14:11> в котором зачем-то обязательным сделали username
это «имя использованное для авторизации», можете там email возвращать и всё что угодно.
> в отличие от стандартного компонента вашу реализацию никто не будет знать
это стандартное заблуждение приводящее к печальным последствиям
> но когда-нибудь вся эта магия вылезет боком.
orm это не магия, это слой абстракции который в больших проектах как раз необходим
> сложноват компонент Config
TreeBuilder да своеобразная штука конечно, по сути так или иначе всё сводится к курению конфигураторов вендорных бандловshoomyst
26.04.2015 14:20это «имя использованное для авторизации», можете там email возвращать и всё что угодно.
Это всё понятно, что можно закостылить. Но мое мнение, что компонент не лучшим образом продуман.
это стандартное заблуждение приводящее к печальным последствиям
Поподробнее давайте уже)
Мне сразу вспоминается случай со взломом какого-то популярного сайта, в голове крутится cnet, кто-то их хакнул, но никто не знает как — автор взлома заявлял, что под угрозой все сайты на симфони. Потом правда выяснилось, что они деплоили в том числе app_dev.php :DFesor
26.04.2015 15:51Ну по поводу UserInterface меня лично больше расстраивает getSalt и eraseCredentials. Появление первого объясняется довольно просто, password api в PHP появился только в версии 5.5, который сам заботится о соли. А вот eraseCredentials как по мне провоцирует разработчика делать что-то плохое в сущностях. Хотя опять же, для 2010/2011-ого года и это было круто.
Что до getUsername — соглашусь.
По поводу ACL — в симфони с ним проблем не сильно больше чем и в других фреймворках. Для чего-то простого — норм, но вообще мне очень нравятся воутеры. С ними все как-то чуть проще, как в плане осознания так и в плане поддержки кода.
В любом случае symfony/security дает вам очень продуманные интерфейсы (UserInterface не в счет) и не плохое API, а уж имплементацию можно и свою запилить. Ну и выкинуть его так же без проблем можно. На бизнес логику компоненты фреймворка, по моему мнению, вообще влиять не должны. А так как в Symfony модели нет, можно воспринимать это все просто как кучу компонентов и бойлерплейт для связи всего этого воедино. Неплохой такой почти готовый Framework Layer для нашего приложения. А для простых CRUD апликачек, без бизнес логики, это все оверхэд конечно.shoomyst
26.04.2015 17:13У меня сложилось впечатление, что как JMS ушел, никто не знает, с какой стороны лучше подступиться к security, что-то пытаются рефакторить, но с другой стороны держатся правила «работает — не трогай»
PerlPower Автор
26.04.2015 15:13-1Тут должно быть особенное мышление
Верно подмечено, так, например, очень хорошо видно, когда PHP код пишет джавист — в коде может быть куча ляпов и логических ошибок, но архитектура и паттерны всегда будут на месте. Меня это поначалу удивляло, потом привык, причин этого до сих пор не знаю.Fesor
26.04.2015 15:37Справедливо для обычных PHP-шников (не для всех, для большинства), куча ляпов и логических ошибок, и никакой архитектуры и паттернов. А главное нет тестов. И как следствие — регрессии, регрессии, регрессии… Любопытно было бы получить статистику, какой процент PHP разработчиков использует юнит/интеграционные/функциональные тесты.
seyfer
27.04.2015 08:10+1Мне кажется, что если бы автор сего поста пробовал бы писать на Zend Framework 2 — он бы в итоге родил такую же статью про Zend.
В классических (уже) книгах по качеству и чистоте кода пишется повсеметстно, что разница между средними и лучшими программистами в 10 раз обуславливается как раз таки способностью понимать и строить сложные абстракции.
Если программист более ориентирвоан на решение бизнес логики и грабли — надо брать фреймворк попроще и не ныть. :)
Лично мне на моем опыте известно, что взяв фреймворк попроще придется неизбежно столкнуться со сложностью поддержки и расширения при росте проекта. Все дело в главном императиве — борьба со сложностью. Энтерпрайз на то и энтерпрайз — чтобы предлагать готовые решения и правила для большого и сложного. Это касается как организации кода, так и всяких паттернов, технологий, методологий.
Если не нравится писать большие энтерпрайз проекты со взрослыми фреймворками — не надо писать. Автор мог бы взять тот же Laravel или набросать свое на компонентах Symfony и к чему вся эта критика?
Но в целом я согласен с выводом, тк. пришел к тому же сам, когда выбирал между Zend и Symfony, что Symfony это больше для клепания сайтов.
Zend мне нравится больше, т.к. позволяет писать больше своей бизнес логики с меньшим принуждением использовать yml и twig.
p.s.
Теги повеселили.m_z
27.04.2015 12:10-2> что разница между средними и лучшими программистами в 10 раз обуславливается как раз таки способностью понимать и строить сложные абстракции.
> Все дело в главном императиве — борьба со сложностью.
Противоречие. Разница между средними и лучшими, наоборот, обуславливается способностью строить простые и понятные всем абстракции.
После нескольких лет с симфони попробовал развернуть веб-приложение на ASP.NET MVC (тру энтерпрайз). Делать что-то на одно удовольствие: всё очевидно и просто, и дело не в похожих концепциях, а именно в их реализации. Может энтерпрайзу не так уж и нужна лишняя сложность?Fesor
27.04.2015 12:22Ммм, вот честно, а есть какие-то координальные различия (с точки зрения концепций) между ASP.NET MVC и Symfony/Zend? Ну да, есть конечно по мелочам, но в общем случае архитектура довольно проста.
Что до «сложности» — речь идет об управлении сложностью. Это разделение проекта на слои (фреймворк и его компоненты представляют только один слой, ну и еще чуток задевают persistance layer), SOA… разделяй и властвуй. Ну а далее уже идут всякие там DDD, model-driven design, дистилляция модели и прочие штуки, которые позволяют более грамотно реализовать бизнес логику. Но это для реально больших и сложных проектов со сложным доменом. Реализовать все правильно с первого раза в таких проектах бывает трудно, потому то и появились всякие там экстримальные программирования и аджайлы с их ретроспективой.PerlPower Автор
27.04.2015 16:06-4Обычно я стараюсь не обращать внимания на то, кто мой собеседник. Но господин Fesor — это особый случай. В свои неполные 23 года он выдает столько терминов, что просто физически бы не успел узнать, что скрывается за всеми ними. Просто не хватило бы времени, чтобы досконально изучить то, о чем он говорит и применить на практике, поняв, что из этого стоящие вещи, а что представляет чисто академический интерес. Возможно он вундеркинд или у него просто был очень хороший наставник, который пропихивал его на работу туда, где он, несмотря на возраст, мог приобщиться к опыту коммерческой разработки. Может быть он правда понимает все о чем говорит, но я не верю, что человек с такой страничкой во вконтакте способен на такое.
Если посмотреть на его github, то среди множества пустых и заброшенных репозиториев можно найти единственную полезную вещь: github.com/fesor/json_matcher. Это простая библиотека, которая позволяет сравнивать куски json в красивом стиле. И там на 2/3 это бойлерплейт, причем в стиле Java.
Т.е. перед нами вчерашний, а возможно и сегодняшний студент, который знает как писать корпоративные приложения, и готовый оправдать любой маразм тем, что это делается для преодоления мифической сложности. Такие студенты есть, но они не работают по 4 года в одной компании, пока в ней параллельно меняется почти весь состав. И ладно мой пост тянет на беспруфное кукареканье, но то, что пишет господин Fesor — это именно что кукареканье, причем с пруфами того, что это именно кукареканье, а не что либо иное.Fesor
27.04.2015 17:09+2Что вам не нравится в моей страничке? расчлененка, блэк, мопсы, блины… ну и мызыка, что еще для счастья надо?
Что до моего гитхаба — а у вас много там полезного? Мне вот не хватало матчера для json нормального, увидел у рубистов, портировал на PHP. Чисто для себя. Просто так контрибьютить как-то не особо интересно, да и во времени я ограничен. Что до бойлерплейта в стиле Java — вообще не понимаю о чем вы говорите. Там вопервых не особо много бойлерплейта, а во вторых это простая библиотечка в несколько классов. Спасибо за рекламу к слову. Вы еще мой профиль на тостере вспомните.
Ну а с «наставниками», а точнее с коллегами мне действительно повезло, наставили на путь истенный. Так же с ВУЗом и преподавателями повезло. Ну и еще есть митапы, конференции, где тоже можно с интересными людьми познакомиться. + в мои неполные 23 года программированием я занимаюсь уже лет 8 (помимо 8-ми часового рабочего дня еще возня в домашних проектиках, постоянная ретроспектива проделанной работы, куча книг и т.д.), и если не заниматься однотипной фигней то в принципе не вижу ничего удивительного в этом. Я знаю людей немногим старше (24-25 лет) у которых уже с десяток лет опыта, и которые уже зарекомендовали себя как крутые разработчики/тимлиды/техлиды. И напротив, знаю людей которые последние лет 5 клепали сайты на вордпрессе/магенту и им было норм. ИМХО возраст это вообще не показатель и редко коррелируется с опытом в этой сфере.PerlPower Автор
27.04.2015 20:14-2Что вам не нравится в моей страничке? расчлененка, блэк, мопсы, блины… ну и мызыка, что еще для счастья надо?
У вас страничка заурядного студента, что никак не вяжется со способностями человека, который может в 23 года на полном серьезе обсуждать что надо делать в архитектуре, а что не надо. Ваша самоуверенность тоже не вяжется с глубокими знаниями. То, что вы 4 года просидели на одном месте, причем на одной должности, причем пока параллельно была большая текучка, тоже говорит о том, что ваши способности не тянут на то, чтобы правда быть в курсе всего того, о чем вы рассуждаете.
Что до бойлерплейта в стиле Java — вообще не понимаю о чем вы говорите. Там вопервых не особо много бойлерплейта, а во вторых это простая библиотечка в несколько классов. Спасибо за рекламу к слову.
Там все-таки много бойлерплейта как для такой простой библиотеки, если вы этого в упор не видите, значит вы не особо вникали в другие подходы и языки, что не характеризует вас как опытного разработчика. То, что у вас много пустых проектов, на мой взгляд, говорит о неумении планировать задачи и рассчитывать силы, все это не вяжется у меня с образом опытного разработчика.
Вы еще мой профиль на тостере вспомните.
Тостер и нужен для того, чтобы спрашивать то, чего не знаешь.
Если бы вы правда были настолько одарены, то заметили бы разницу в способностях между собой и вашими коллегами. И заметили, что технологии, которые может нормально использовать меньшинство, очень плохо подходят для коммерческой разработки, если нужна легкость поддержки и взаимозаменямость сотрудников. Но вы этой разницы в способностях не видите, раз не делаете выводов. Следовательно, либо разницы нет вовсе, и вы типичный программист, который в 23 года не может знать и понимать то, о чем вы рассуждаете. Либо же вы ее не замечаете(но с вашим самомнением заметили бы), что означает, что вы настолько глупы, что не понимаете насколько умны. Как-то противоречиво выходит.
В общем я хочу сказать, что ваш непробиваемый позитив по отношению к Symfony вызван или синдромом утенка, или тем, что вы только с ней последние годы непрерывно работаете — т.е. банально привыкли. Но никак не тем, что вы видели рождения и провалы больших проектов, делали из них выводы, анализировали различные подходы к разработке, применяли различные архитектрные приемы и т.п. И то, что вы как лезете как затычка в каждую дырку в комментариях тоже проще объясняется вашим уязвленным самолюбием чем профессионализмом. Контрибутуить вам не интересно, а отстаивать честь одного из десятков PHP-фреймворков интересно. К слову насколько я разобрался в портфолио вашей компании Intellectsoft — вы там большую часть времени лепите промо сайты и мобильные приложения к ним же, даже если учесть что вы делаете эти сайты с социальной составляющей, то это все равно не то, что называется большие проекты со сложной архитектурой.
И я пишу это не вам, Fesor, а тем, кто ваши комментарии читать будет, чтобы люди понимали, кто им рассказывает, что Symfony офигенная. Что это не опытный тимлид у которого за плечами несколько сложных самостоятельных проектов, а вчерашний студент, не работавший никем кроме рядовогоPHP- разработчика в бодишопе, который за низкий прайс скидывает типовые проекты на исполнение в СНГ.Fesor
27.04.2015 20:59+3У вас страничка заурядного студента
Ну ок, и что?
на одной должности
Тип… инженер-программист? Ну а куда мне по вашему, в дизайнеры? CTO? Для CTO опыта у меня на самом деле не достаточно, в тимлиды не хочу больше, в техлиды можно, но нет необходимости в отдельной позиции оного. Вообще на лицо какие-то комплексы. У меня в команде есть ребята которые работают со мной не сильно меньше. Есть люди которые ушли в продукт, но сидят в том же офисе, так что можно холиварить по вечерам. Не вижу с этим проблем. Интересных задач хватает, когда станет скучно или задумаю что-то свое, тогда буду думать. Словом мне не понятны ваши представления о мире.
23 года на полном серьезе обсуждать что надо делать в архитектуре, а что не надо.
А когда это на полном серьезе обсуждают люди 28-30 лет, у которых за плечами столько же опыта сколько у 23-х летнего? + у них семья и тратить кучу свободного времени на собственное развитие у них уже не выходит. Ну и т.д.
Там все-таки много бойлерплейта как для такой простой библиотеки
Если вы укажите конкретно где что по вашему лишнее/оверхэд — буду признателен. Сразу скажу что JsonMatcherFactory попало туда просто что бы дополнить все варианты использования (ну и в Behat так удобнее). Больше бойлерплейта и нет. JsonHelper я написал где-то за несколько месяцев до самой библиотеки потому мерджить ее не стал. Ну и опять же — я не горжусь качеством этой библиотеки, но допилить руки не доходят. И что самое главное — она работает и ладно, ну и ее можно спокойно рефакторить.
Если бы вы правда были настолько одарены, то заметили бы разницу в способностях между собой и вашими коллегами.
Ну ок, я разницу вижу и пытаюсь подтягивать чуваков если вижу что нужно. Скажем в вопросах оптимизации баз данных я откровенно слаб, всего знать нельзя. Эксплейны запросов читать могу но что-то сложное на процедурах делать — нет. Зато в команде есть пара прошаренных в этом деле ребят, с коими я периодически советуюсь о сложных вещах. Мне кажется это нормальное течение дел.
вы там большую часть времени лепите промо сайты и мобильные приложения к ним же
круто, а я не знал. Я даже не припомню когда мы делали сайты…
Что это не опытный тимлид у которого за плечами несколько сложных самостоятельных проектов, а вчерашний студент, не работавший никем кроме рядовогоPHP- разработчика в бодишопе, который за низкий прайс скидывает типовые проекты на исполнение в СНГ.
Вы очень надежный источник, John Dow. Я бы на месте читающих мои комментарии или ответы на тостере прислушался бы.neolink
27.04.2015 21:09+3> А когда это на полном серьезе обсуждают люди 28-30 лет, у которых за плечами столько же опыта сколько у 23-х летнего? + у них семья и тратить кучу свободного времени на собственное развитие у них уже не выходит. Ну и т.д.
Это кстати тоже возрастной шовинизм
в общем я предлагаю вам разойтись миром, так как каких-то аргументов вы врятли сможете друг-другу предложить или обменяться телефона/email/skype и т.п. для более тесного обмена любезностями.
neolink
27.04.2015 21:04+3да ладно вам по аватарке в соц. сетях и ЧСВ выше среднего делать далекоидующие выводы.
такое ощущение, что от того, что кто-то прочтет комментарий и решит, что надо бы попробовать Symfony у него жизнь под откос пойдет. Да и есть в ваших комментариях противоречие — то симфони для избранных, а то в ней и «вчерашний студент» с полпика разберется.
Вообще ни разу не видел проекты фейл в которых можно было бы объяснить выбранными технологиями. Даже если это был Code Igniter. Всё равно основные проблемы обычно в людях.
ЗЫ Вообще у меня скорее негативный опыт общения с людьми которые указывают на опыт с 15 лет, в 25 это уже 10 лет опыта (ды-да), зачастую (у меня это 100%) это лукавство, причем бывало, что реальный опыт около 0. Эффект Даннинга — Крюгера как бы тоже никто не отменял.
Но даже если это так это не повод из-за неприязни к фреймворку выплескивать это на конкретного человека.
ЗЫЗЫ совсем недавно в youtube попался ролик www.youtube.com/watch?v=w1e4kffwaus — о том насколько наши суждения зависят от внутренних установок.PerlPower Автор
27.04.2015 22:21-2Да и есть в ваших комментариях противоречие — то симфони для избранных, а то в ней и «вчерашний студент» с полпика разберется.
Это не противоречие, а разные случаи использования. Студент может ее «заучить», и использовать, другое дело, что он будет городить паттерны не понимая зачем он их там городит, в итоге архитектура будет с элементами сюрреализма. А вот чтобы пользоваться симфонией не избегая ее компонентов и не создавая ненужных абстракций нужно быть профессионалом, ну или как писали выше человеком с определенным складом мышления.Fesor
27.04.2015 23:21+3Студент может ее «заучить», и использовать, другое дело, что он будет городить паттерны не понимая зачем он их там городит, в итоге архитектура будет с элементами сюрреализма.
Если я вам скажу что пару лет назад проходил этот период, вам будет спокойнее? Так бывает, когда огромная масса теоретических знаний поступает слишком быстро, без возможности обкатать все на практике и как-то утрясти все это в более общую картину.
Я лично не знаю ни одного человека, который бы сразу делал все правильно на протяжении своей карьеры, да и не думаю что такие люди существуют. Более того, я не думаю что существует это «правильно», всегда есть варианты. Факапы с паттернами и оверинжениринг обычно случаются когда это все применяется просто… что бы применить. Программирование ради программирования так сказать. Я страдал этой ересью и, надеюсь, переболел. И не могу сказать что так уж давно. Я видел достаточно проектов и проблем с архитектурой, у меня была куча своих граблей… и все это сформировало у меня в голове мое виденье того, как готовить проекты.
Что до моего «твердолобого позитива от Symfony»… простите что возвращаюсь к этом теме, просто хотелось бы прояснить. Я вроде как нигде ничего не говорил «Symfony обожаю юзаю все все все и бла бла бла какжемненравитсясимфони». Просто альтернативы то особо и нет. Как вы уже заметили — я работаю в аутсорсе. А это значит что часть проектов будут поддерживать уже другие разработчики. Так же для аутсорсинговых компаний ротация кадров довольно обычное дело. А это значит что проект который писал Вася Пупкин год назад вполне себе может достаться на следующую итерацию кому-нибудь другому, и он должен понимать как там что и иметь возможность быстро разобраться в проекте и решить поставленную задачу. И тут как бы логично использование более простых инструментов… или более простых подходов… В контексте вашей статьи выбор Symfony2 в качестве основного фреймворка может казаться странным, но оно работает. До этого был Yii, который при сложности хоть чуть чуть выходящий за пределы простого CRUD уже вставлял палки в колеса и добавлял сложности. Проекты обрастали кастылями и т.д. С Symfony если вы начинаете бороться с фреймворком, то стоит остановиться на секунду и попробовать свернуть в другом направлении.
Да, конечно волшебные штуки, типа того же JmsSerializer могут вставлять свои палки в колеса, но никто же не заставляет использовать его в своих проектах. Или всеми любимый FosRestBundle (кто его знает что он там внутри делает, если смотреть на контроллеры приложения то как-то не очевидно не зная FosRest как оно и почему так). Но это все дело вкуса. Был период когда на проектах юзалось все перечисленное вместе. И могу я вам сказать, что как и в случае с Yii, при увеличении сложности сразу начинались проблемы.
Мне по сути для счастья от симфони нужны доктрина (потому что нет альтернативы нормальной, во всяком случае пока), HttpKernel и маршрутизация. Все остальное — ну так… Symfony/security меня не напрягает, хоть я и использую от силы половину того что предоставляет этот компонент. Формы я не использую уже давно (для апишек оно и не нужно, а админки можно делать на ангуляре получая это этого профит), вот думаю отказываться и от symfony/validate (пока тяжко, ибо опять же есть команда, у которой нет опыта работы по такой схеме, и приходится с этим считаться, объяснять и т.д + это не те вещи которые стоит делать сразу и везде). дэбак-панель в симфони мне нравится. ее еще оставить можно. Ну и от symfony/di никуда не деться, хоть после PHP-DI он меня и напрягает.
Если же отказаться от анемичной модели, перестать плодить сущности с сеттерами, размазывать бизнес логику по сервисам и научиться готовить нормально модель предметной области, со всеми этими SOLID и GRASP, то по сути большая часть нашего symfony-приложения будет написано на старом добром PHP. Модель ничего не будет знать о компонентах фреймворка и тогда уже будет плевать, Symfony или что-то другое у нас под копотом. И для того что бы посадить человека пилить бизнес логику, этому человеку нужно будет всего-то знать PHP и ООП (всего-то)).
MrLoki
27.04.2015 23:48+2
Вы по аватарке уже расписали как это человек пишет код, какие выводы он делает из разных ситуаций, какие паттерны и почему он использует. При этом о себе вы видимо совершенно противоположного мнения. Вы не студент, не любите паттерны, при этом знаете что является оверхедом в ситуации вашего оппонента, а что нет (в отличии от него самого). При этом вы не стесняясь перешли на личности. Я удивлён что Fesor продолжил вам отвечать.
Ваше поведение неимоверно смешно, и невероятно глупо, извините…PerlPower Автор
28.04.2015 00:28Ну посудите сами — вот я написал статью почти без аргументов, без терминов, одни общие слова. И тут выходит Fesor и все по умному расписывает — во всяком случае у него есть куча терминов и такой тон, будто он не рассказывает о некоторых решениях в своей работе, а о нерушимых стандартах отрасли. Если бы я не был знаком с Symfony, то занял бы сторону Fesor. И посчитал бы, что 65% людей в опросе — неосиляторы. А для неопытных людей все эти аббревиатуры звучат как заклинания, независимо от того насколько общи и применимы концепции, скрывающиеся за ними. Поэтому я посчитал нужным напомнить кто именно защищает Symfony, и почему к его словам нужно относиться с осторожностью.
Fesor
28.04.2015 00:46+2Ну… значит я плохо выражаю свои мысли, бывает. Суть не в терминах и уж тем более в «нерушимых стандартах отрасли», а в том что Symfony и его компоненты — лишь инструмент (а точнее набор инструментов), инструмент не идеален (идеальных нет), но он работает, а главное он стабильный и предсказуемый (в плане релизов и изменений). Все остальное — на выбор разработчику. А то так выходит что для того что бы забить пару гвоздей люди специально должны брать набор всевозможных молотков, отверток и прочего. Конечно потом возникает путаница в духе «а какой молоток лучше? Как держать руку?». Ну а все советы и прочее почему-то воспринимаются буквально, как правила а не как советы. Опять же если кто-то выкладывает статью вида «а я вот делаю вот так» или «а мне вот так не нравится», то это так же наносит вред, так как впечатлительных разработчиков без собственного мнения хватает. Выходит какой-то культ карго. Где-то увидел и повторяет бездумно.
К слову вот наткнулся на видео по поводу сложности Symfony и что планируется с этим делать к третьей версии: vimeo.com/125331483 может будет интересноFesor
28.04.2015 01:05Да, для тех кто перейдет по ссылке в надежде увидеть что-то подробнее, сразу расстрою. Основная мысль видео — о сложности симфони все разработчики самой симфони вкурсе и они пытаются что-то с этим делать. И что ради этого они даже могут чуть чуть нарушить те самые «нерушимые правила и стандарты», если это конечно не ломает BC
Fedot
28.04.2015 02:47Хочется спросить, а что вы хотели прочитать в комментариях к своей статье?
Fesor с аргументами высказал точку зрения с которой судя по всему согласны, ни много ни мало, 35% опрошенных.
После этого вы зачем-то пытаетесь переходить на личности утверждая что только ваш опыт может служить адекватной оценкой сложности и нужности паттернов используемых где бы то ни было. А этот студент сыпет терминами и не ведает о чём он.
Я могу сказать что с моей колокольни те мысли и тезисы что высказывал Fesor, адекватны, понятны и более того подтверждены опытом многих проектов.PerlPower Автор
28.04.2015 03:01Не помню, чтобы я писал про лично свой опыт, ткните пожалуйста, дам подробный ответ. И кстати с какими именно тезисами Fesor вы согласны, и как именно они были подтверждены опытом? Расскажите пожалуйста о ваших проектах и к каким выводам вы пришли.
saksmt
28.04.2015 05:46+1Вы, конечно, молодец, что пытались написать статью о Symfony не используя тучи терминов, но IMHO лучше не подпускать к «взрослым фреймворкам» (и тем более не пытаться объяснять все «за» и «против») людей, которые понимают меньше ~70% этих терминов. В противном случае в коде внезапно может оказаться лишний (aka бесполезный) слой абстракций над стандартным функционалом или отмазы от использования готовых решений с мотивацией «заказчик не велел использовать {библиотеку, фреймворк} X» (и это-то на фрилансе), в худшем же случае может появиться что-то такое или даже такое. (и да это всё примеры из жизни)
К тому же, термины — это тоже просто абстракция (да-да вспоминаем, что паттерны задумывались как словарь) которая сокращает количество слов необходимых для передачи смысла. А т.к. это всё-таки хабр, то аудитории, которая это читает, следует быть готовыми к такой терминологии.
PerlPower Автор
27.04.2015 14:12-1Лично мне на моем опыте известно, что взяв фреймворк попроще придется неизбежно столкнуться со сложностью поддержки и расширения при росте проекта. Все дело в главном императиве — борьба со сложностью. Энтерпрайз на то и энтерпрайз — чтобы предлагать готовые решения и правила для большого и сложного. Это касается как организации кода, так и всяких паттернов, технологий, методологий.
Не могу с вами согласиться ввиду того, что видел большие проекты, где фреймворка не было вообще, но вхождение в них все равно было простым. Сложность и запутанность бизнес логики вообще мало коррелирует с иcпользуемым фреймворком, тут имеет значение предметная область. Приведите пожалуйста пример сложностей с которыми вы столнетесь при расширении проекта без Symfony.poxu
27.04.2015 16:10+1Если в проекте нет фреймворка — это может означать две вещи — его нет вообще или он есть, но только самописный. Если самописный фреймворк хороший или хотя бы средний, это естественным образом снимает кучу проблем, однако существует определённый набор граблей, на который систематически натыкаются проекты, не использующие сторонние фреймворки
— смена СУБД
— изменение структуры БД (как правило проводится руками)
— горизонтальное масштабирование
— многоязычность
— перенос в другое окружение (обновление вообще любого компонента системы)PerlPower Автор
27.04.2015 16:31-1Ну это не грабли в моем понимании, а попытки сделать из одного проекта другой проект. Когда из фургончика хотят сделать двадцатитонную фуру, это уже по сути решение другой задачи, а не той, что ставилась изначально. А проектировать так, чтобы все лекго менялось в случае чего тоже накладно.
Да и тут никакой фреймворк не поможет — в конечном счете все равно все сводится к обкладыванию текущего кода тестами и переписыванию под новые требования. Но если знаете про волшебную таблетку, которая позволит этого избежать, то расскажите.poxu
28.04.2015 14:26+1Ну вопрос был собственно про сложности расширения проекта. Это они и есть.
Насчёт того, что никакой фреймворк не поможет — это не совсем так.
Конкретно вот с этими проблемами — поможет.
Фреймворки позволяют абстрагироваться от СУБД.
Фреймворки как правило имеют средтва миграции структуры данных (также абстрагированные от СУБД)
Фреймворки помогают структурировать код так, чтобы горизонтальное масштабирование впринципе было возможно.
Фреймворки зачастую имеют средства для поддержки многоязычности.
Фреймворки помогают с автоматизацией деплоя приложения.
Если фреймворка нет, то да, приложение наверняка придётся переписывать. Если фреймворк есть, а в бизнес логике — каша — тоже придётся. Но если с бизнес логикой всё хорошо, то можно отделаться малой кровью.Fesor
28.04.2015 15:39Фреймворки позволяют абстрагироваться от СУБД.
За это отвечает DBAL и только он. То как вы отделяете бизнес логику от логики хранения данных это лично ваше дело.
Фреймворки как правило имеют средтва миграции структуры данных
Большинство популярных решений не привязаны к фреймворкам и их можно юзать как хочешь.
Фреймворки помогают структурировать код так, чтобы горизонтальное масштабирование впринципе было возможно.
Опять же нет. Фреймворки никак не будут намекать чуваку что для его проекта SOA это круто.
Фреймворки зачастую имеют средства для поддержки многоязычности.
это можно решить отдельными компонентами
Фреймворки помогают с автоматизацией деплоя приложения.
Ммм… да не особо. Вот штуки типа Docker это да.
Фишка в том что Symfony с его ядром в виде набора компонентов как раз таки дали толчок к качественному развитию всего комьюнити. Появление composer вместо богомерзкого pear, использование отдельных компонентов вместо монолитных решений… Ну и опять же популяризация практик принятых в enterprise приложениях. Сейчас этим всем удивить сложно, но в те не столь давние времена это было круто.poxu
28.04.2015 16:26Фреймвор — он и есть сборка из библиотек, которую надо использовать согласно рекомендациям создателя фреймворка. Если самостоятельно применить все эти библиотеки правильным образом — у вас будет фреймворк собственного изготовления.
Fesor
28.04.2015 16:52надо использовать согласно рекомендациям создателя фреймворка
то есть воспринимать рекомендации как правила? Обезьянка видит — обезьянка делает? Есть конечно отдельный вопрос что прежде чем наплевать на рекомендации и делать все по своему нужно полностью отдавать себе отчет в том что ты делаешь. И стадию обезьянка видит обезьянка делает пройти все-равно придется.poxu
28.04.2015 17:40Рекомендации надо воспринимать как рекомендации. Создатели фреймворка формулируют их специально, чтобы разработчик мог избежать попадания на целый набор граблей.
druidvav
Непонятно, а вывод-то какой? Про каждый из фреймворков можно найти с десяток подобных статей, непонятно только что же делать, куда бежать.
hardtop
Какой вывод… Только искать тот фреймвок, что Вам подходит больше всего. Все они сложноваты, прямо скажем. Очень много решает документация.
PerlPower Автор
Для себя я сделал вывод, что тему сложности симфонии нужно осторожно поднимать в каждой команде, и если большинство склоняется к тому, что гайды дядюшки Фабиена представляют скорее литературно-академический интерес, нежели руководство к действию, то нужно перестраивать рабочий процесс. Никто обычно не осмеливается поднять тему того, что фреймворк проблемный, и в результате все ходят и делают вид, что пишут хороший правильный код, не понимая при этом чем код хорош и зачем они это делают. Эдакий голый король.
druidvav
Хотел написать про то, какие у вас поверхностные доводы, но решил, что лучше не нужно. Вместо этого задам простой вопрос: вот подняли вы проблему, а решение какое, хотя бы направление? Я на хабре читаю уже не первую статью про то, что N — плохой фреймворк, X — плохой язык и т.п. Обычно это именно такие вот статьи ни о чем: находится пара сомнительных доводов, накручиваются эмоции и не предлагается решение.
hudson
Поддерживаю. Про то что X это Y — в любом контексте и с любым градусом ненависти можно найти массу статей. А вот предложи свою дорогу в ад… Нет? Следующий…