Очень много вопросов по кодстайлу: - много лишних переменных - много лишних строк - каждый->вызов->должен->быть->на->новой->строке - отсутствие тайпхинта в параметрах функций, в полях класса, в возвращаемых типах. Очень сильно бросается в глаза `AdminController` 20-30 строки, по факту все `else` там не нужны, т.к. в условиях return'ы.
4:34 алиас можно прописать в систему, чтобы не прописывать его постоянно если для конкретного пользователя то в файл ~/.bashrc если на для всех польователей то в /etc/bash.bashrc
ну и писать код в контроллере не очень, они становятся жирными. Даже если у вас одностраничный сайт нужно выносить код в отдельные класс, например сервисы, т.к в будущем если проект будет расширятся будет проще, не нужно будет переписывать имеющийся код.
@@Diqeeeeeeeeeei угу только у некоторый принцип solid превращается в сотни мелких классов, один берет рулон бумаги, второй его оттягивает, третий отрывает, четвертый подносит к жопе и только пятый вытирает) В такие проекты сложно выкатывается и кроме геморроя ничего хорошего. Dry штука правильная, но тоже нужно с умом подходить. Например никто не отменяет принцип единой ответственности. Это не значит что все должны дублировать свою лапшу, но в некоторых случаях dry можно пренебречь. Я молчу ещё про разработку модулей, плагинов под различные cms системы. Иной раз специально пилишь свои велосипеды для оснастки, что бы можно было просто портировать ПО переписав системо-зависимый код. Ну kiss тут все понятно. Все принципы хороши, придуманы умными людьми. Но когда им следуют в лоб получается только хуже)
@@semenkuznetsov9413 ну если ты сначала берешь рулон потом оттягиваешь, потом рвешь, ложишь в руку, подносишь к жопе, вытираешь, берешь в другую руку, открываешь мусорку, выкидываешь шматок. Это не совсем solid 🤣. Но это намного лучше кода в 2к + строк в одном контроллере index. Везде есть своя грань с этим я согласен. Но по итогу, даже если ты напишешь 2к строк говнокода и вынесешь его в сервис это гораздо лучше, чем написать его в контроллере. Хотя бы потому, что ты сможешь использовать код где то еще и когда захочешь расширить или посмотреть контроллер тебе не нужно пол дня его листать)
зачем fillable category_id ? он или инкрементится автоматом либо должен заполняться с помощью релейшенов права , роли по мне лучше пользовать Policy всякие переносы скобок , пустые строки и прочее - friendsofphp/php-cs-fixer в помощь
19:17 не очень хорошее решение, если у тебя постов будет больше миллиона, то получение их всех, а потом еще делать sum по лайкам очень затратно по времени и ресурсам.
Почему? withCount - в таком варианте считается на уровне БД, а не считаются замапленные объекты. Это очень лёгкая операция и даже большое количество, не нагрузят БДшку, Или вы о чём-то другом?
@@Skalebro он говорит про вывоз метода sum() после метода get(). Метод get вернет коллекцию и метод sum выполнится на уровне коллекции, а не на уровне бд
Отличная рубрика! Надо чаще
Спасибо, подчеркнул для себя новую информацию)
Крутой разбор. Лайк
Спасибо 🎉
Очень много вопросов по кодстайлу:
- много лишних переменных
- много лишних строк
- каждый->вызов->должен->быть->на->новой->строке
- отсутствие тайпхинта в параметрах функций, в полях класса, в возвращаемых типах.
Очень сильно бросается в глаза `AdminController` 20-30 строки, по факту все `else` там не нужны, т.к. в условиях return'ы.
4:34 алиас можно прописать в систему, чтобы не прописывать его постоянно
если для конкретного пользователя то в файл ~/.bashrc
если на для всех польователей то в /etc/bash.bashrc
у меня такой вопрос почему для алиаса писать столько всего
вроде alias sail='vendor/bin/sail' работает
Привет! Подскажи пожалуйста, какую тему используешь для разработки в phpStorm? Ну либо может, кто-то знает в комментариях, буду благодарен за ответ! 😇
Можно ссилку в соурс-код
Это на linux ?
Подписчики разбирают проект?
ну и писать код в контроллере не очень, они становятся жирными. Даже если у вас одностраничный сайт нужно выносить код в отдельные класс, например сервисы, т.к в будущем если проект будет расширятся будет проще, не нужно будет переписывать имеющийся код.
ключевое - если ... одностраничники = процедурный стиль ван лав
Самое смешное, что код все равно придется , где то писать и что то будет засрано) если не контроллер, то другой класс)
@@semenkuznetsov9413 для этого есть solid это раз. И 2 принципа dry / kiss это два)
@@Diqeeeeeeeeeei угу только у некоторый принцип solid превращается в сотни мелких классов, один берет рулон бумаги, второй его оттягивает, третий отрывает, четвертый подносит к жопе и только пятый вытирает)
В такие проекты сложно выкатывается и кроме геморроя ничего хорошего.
Dry штука правильная, но тоже нужно с умом подходить. Например никто не отменяет принцип единой ответственности. Это не значит что все должны дублировать свою лапшу, но в некоторых случаях dry можно пренебречь.
Я молчу ещё про разработку модулей, плагинов под различные cms системы. Иной раз специально пилишь свои велосипеды для оснастки, что бы можно было просто портировать ПО переписав системо-зависимый код.
Ну kiss тут все понятно.
Все принципы хороши, придуманы умными людьми. Но когда им следуют в лоб получается только хуже)
@@semenkuznetsov9413 ну если ты сначала берешь рулон потом оттягиваешь, потом рвешь, ложишь в руку, подносишь к жопе, вытираешь, берешь в другую руку, открываешь мусорку, выкидываешь шматок. Это не совсем solid 🤣. Но это намного лучше кода в 2к + строк в одном контроллере index. Везде есть своя грань с этим я согласен. Но по итогу, даже если ты напишешь 2к строк говнокода и вынесешь его в сервис это гораздо лучше, чем написать его в контроллере. Хотя бы потому, что ты сможешь использовать код где то еще и когда захочешь расширить или посмотреть контроллер тебе не нужно пол дня его листать)
Сделай пожалуйста видео как ты разрабатываешь небольшое приложение на Laravel
зачем fillable category_id ? он или инкрементится автоматом либо должен заполняться с помощью релейшенов
права , роли по мне лучше пользовать Policy
всякие переносы скобок , пустые строки и прочее - friendsofphp/php-cs-fixer в помощь
19:17 не очень хорошее решение, если у тебя постов будет больше миллиона, то получение их всех, а потом еще делать sum по лайкам очень затратно по времени и ресурсам.
Почему? withCount - в таком варианте считается на уровне БД, а не считаются замапленные объекты. Это очень лёгкая операция и даже большое количество, не нагрузят БДшку, Или вы о чём-то другом?
@@Skalebro он говорит про вывоз метода sum() после метода get(). Метод get вернет коллекцию и метод sum выполнится на уровне коллекции, а не на уровне бд
там вообще метод sum не нужен, так как withCount уже вернет общее количество лайков, суммировать там ничего не нужно))