Laravel Чем вызван взрывной интерес к Лярве?

[Absinthe]

А почему Homestead был эпическим провалом ?

Эта надстройка над надстройкой (vagrant) на VM, которая уничтожает плюсы первой настройки (vagrant).

Почему бы новичкам просто не использовать голую VM в таком случае? Сконфигурированную.
А если человек уже использует vagrant, то он удобнее без Homestead.

Саму идею вагранта извратили: виртуалка одна на все проекты, а не попроектная. И плюс вагранта в виде заточенной виртуалки под проект теряется. Теряется и плюс с распространением проекта между разработчиками.
В итоге растеряли все плюсы вагранта. А минусы есть в глупом и бессмысленном усложнении средств разработки.

 

[Redjik]

Вернемся к Лярве, я хорошенько поковырял ее, 4ую ветку.
Может я чего не понимаю... но, почему все так печально с DIC?

Он вроде какбе есть, но конфигурация и зависимости размазаны по 100500 конфигам, бандлы фигачат свои заивисмотси прямо в коде в сервис провайдерах... и вообще ад и израиль...

Я знаю, что конфиги симфони тоже подразмазаны, но все же не настолько.

Короче пертензии такие:

1) Интерфейсы? Не не - не слышал.
2) Чтобы узнать все зависимости нужно очень долго ковыряться, ОЧЕНЬ.

из всего этого выползает следствие, Tight coupling
например, я решил выкинуть полностью View (не добавить расширение, а именно выкинуть и заменить), я уверен, что буду дебажить 100500 лет.

+ все эти бандлы, мелкая ошибка в одном из них - и дебаг на пол дня

Я не пытаюсь развести холивар, может я просто чото не понимаю? Обьясните мне как правильно его готовить, ибо по мне, Ларавель жесть жесткачная

 

[Вурдалак]

Я Redjik'а не кусал.

 

[Redjik]

Вурдалак, я просто стал твоим фанатом видимо, вот так, от ненависти до любви...
Как оказалось ты в 99% прав

1% спишем на ПМС

 

[флоппик]

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

 

[grigori]

Быстро собрать проект из кучи симфониевских компонентов, не пригружая самим симфони, и с удобным AR - это хороший вариант для MVP.
С учетом того, что из MVP что-то вырастает в 0.5% случаев - это в целом выгодно.

Дальше при росте стоимость владения выходит высоковата, ну что ж теперь.

 

[флоппик]

grigori, ну так имея MVP, можно начать зарабатывать деньги, а разница в стоимости владения мне кажется будет невелика в процентном отношении.

 

[grigori]

Велика - надо поддерживать текущие процессы и переписывать своим кодом, а чтобы спрыгнуть надо дублировать разработку.

Когда компонентов много, а конфигурация размазана, bus-factor встает в полный рост, и сроки/стоимость глубокой доработки увеличивается в разы.
На костылях можно прожить год-два, но потом сайты начинают просто лежать, и никто ничего не может сделать.
Мы в прошлом году таким занимались - реанимировали проект от любителей накидать 100500 сторонних расширений на все случаи жизни, с непредсказуемыми зависимостями.
Я просто понимаю о чем Redjik.

Бывает и хуже, когда нет никакого фреймворка и никаких правил.

 

[флоппик]

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

 

[grigori]

Когда конфигурации размазаны - зависимости становятся неявными, приложение становится хрупким, и дорабатывать его с ростом становится все сложнее.
Что-то изменил - упало, сиди ищи где же это описано.

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

 

[флоппик]

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

 

[grigori]

Жизнь - она не логичная. Выкатывают MVP как можно дешевле, зарабатывают, потом нанимают тех, кто может обеспечить рост.

Laravel хорош чтобы быстро писать с нуля. Но иногда проекты разрастаются, команды меняются, а стоимость разработки растет геометрически. Короче, красиво было на бумаге, но реанимировать эти выжившие проекты через несколько будет жестко. А ведь, может, придется, работа у меня такая.

 

[Вурдалак]

MVP не означает, что там будет/должен быть говнокод. Если не иметь прямой зависимости от конкретных инструментов, просто введя интерфейсы на нужные приложению сервисы, иметь чёткое разделение кода самого приложения и инфраструктурной составляющей, то потом будет жить гораздо легче.

Не понравилась библиотека, плохо себя показала — нах её. Не справляется Redis с большими нагрузками для очередей — нах, можно прозрачно перейти на RabbitMQ и т.д. Просто нужен скилл у руководителя разработки.

 

[grigori]

конечно, не означает, но в жизни он там обычно есть
он есть даже в своих проектах 3-летней давности

Не понравилась библиотека, плохо себя показала — нах её.

не укладываемся в согласованный план - нах его, не нравятся дедлайны - нах ту зарплату )))

Если не иметь прямой зависимости от конкретных инструментов, просто введя интерфейсы

еще раз.

почему все так печально с DIC?
1) Интерфейсы? Не не - не слышал.

 

[Вурдалак]

Просто сижу, жму F5 и наблюдаю за эволюцией сообщения grigori, которое редактируется в 5-й (?) раз.

 

[grigori]

да я всегда так пишу
дописываю по ходу чтения сообщения, на которое отвечаю, но суть не меняю

 

[grigori]

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

 

[fixxxer]

grigori,

почему все так печально с DIC?
1) Интерфейсы? Не не - не слышал.

Ну уж ты то бы не повторял, сам не проверив. Все там есть.

 

[AmdY]

например, я решил выкинуть полностью View (не добавить расширение, а именно выкинуть и заменить), я уверен, что буду дебажить 100500 лет.

В этом и суть, вам шашечки или ехать. БМВ - гавно машина, я решил не поменять, выбросить колёса, так она после этого не едет, интерфейсов нет, мотор от жигулей на влезает, а когда полез в электрику так там фиг разберёшься с зависимостями.

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

 

[AmdY]

@fixxxer в пакетах поголовно привязываются к реализации, а не интерфейсу. Это правда.