A
Главная проблема - каждому проекту найти подходящего программиста.
Size: a a a
2020 August 28
А
Главная проблема - каждому проекту найти подходящего программиста.
И вовремя его уволить
A
Для простенького приложения городить кучу абстракций вообще не стоит. Но некоторые делают, потому что хотят писать «красиво»
AB
И вовремя его уволить
ларавель удалить и программистов уволить)
A
Однако для другого приложения такой подход будет в тему.
A
А ларавель... он нормальный. Для простого приложения у него есть куча всего, которое позволяет срезать углы и делать быстро.
A
Для сложного - базовые вещи, типа роуминга и конфига. И вполне можно использовать что угодно
А
А ларавель... он нормальный. Для простого приложения у него есть куча всего, которое позволяет срезать углы и делать быстро.
Конечно нормальный. Симфони-то не дает тебе возможность делать плагины)))
AB
❤️ laravel
A
Но когда какой-нибудь дикий хайлоад - там уже совсем другие проблемы. Люди хотят асинк и чтобы все не умирало каждый раз
A
Конечно нормальный. Симфони-то не дает тебе возможность делать плагины)))
Молчи мне тут)
y
Конечно нормальный. Симфони-то не дает тебе возможность делать плагины)))
хаха
АГ
крч нужна альтернативная дока по ларе)
АГ
без фасадов, хелперов, сервис локатора и магии)
A
без фасадов, хелперов, сервис локатора и магии)
И оставить меня без средств к существованию? Да ну тебя
AB
без фасадов, хелперов, сервис локатора и магии)
приходят в наш хогвартс и говорят отменить магию
АГ
думается разумный баланс где-то в области того, что весь ларавел код должен быть в контролерах, причем бизнес кода там быть не должно. совсем. ну и в консольных командах.
А
Молчи мне тут)
Вот тебе идея для плагина: если человек юзает фасад или хелпер, ты ему окошко показываешь: "а может, лучше <proxyNameService>?".
АГ
т.е. в контроллере / консольной команде создаются нужные объекты и инъектятся в сервисы. дальше уже сервисы все делают по-нормальному, без средств ларавела.