PHP: хорошие практики. Наименования и экспрессивность.

[@alexeydorosh955]

Насчет применения DRY к названиям интерфейсов я бы поспорил: Да, идешка отмечает интерфесы значком, но, ведь, мы интерфейсы делаем не для значков. Да, в полном пути к интерфейсу однажды встретиться либо Interface, либо Api, либо еще что-то, исходя из чего мы точно можем понять, что это интерфейс, но: мы почти всегда используем сущность через импорт (use) Где мы используем указание типа сущности: - типизация - обращение к статичным полям (константы) И там и там делать это через полные пути - это смертоубийство Также существует практика, когда в папку, скажем, Api выносятся интерфейсы, которые мы как бы позволяем использовать другим вендорам. Таким образом мы как бы говорим, что этот интерфейс скорее всего не поменяется, а если и поменяется - то это будет постепенно через аннотацию @deprecated. В то время как интерфейсы для классов внутреннего использования обычно кладутся рядом с самими классами в том же неймспейсе. И тут возникает две проблемы: - два файла с одним именем рядом существовать не могут - в случае разнесения интерфейса и имплементации по разным папкам - мы всё еще будем сталкиваться с тем, что интерфейс и имплементация называются одинаково. А это значит, что внутри имплементации обращаться к интерфейсу нам придется либо по полному пути, либо через алиас use as, что, как бы, тоже лишняя работа. Касательно эксепшенов: Глядя на InvalidArgumentException я точно знаю, что это эксепшен. Глядя на InvalidArgument - я скорее предположу, что это какой-то класс, который как-то обрабатывает не валидный аргумент. Да, идешка имеет отдельный значок для эксепшенов, но мы же в коде смотрим не на значки...

[@АнтонВогусов]

Очень хороший канал. Отличная подача, актуальные вопросы рассматриваются. Я подобного тут не видел. Спасибо))

[@ВикторШавкутенко-м8э]

Дяку, теж сильно оцінив!

[@ProgramEnginer]

Ваууууу, это супер материал! Очень понравилось видео. Сам сейчас на php работаю. Хочется улучшить качество своего кода. С вами, думаю, это получится)

[@lordaz1652]

однозначно лайк. хороший материал.

[@zhurov95]

Спасибо большое!!! Очень круто объясняешь, а главное, показываешь наглядно! Это прям мега круто!!!😊

[@АлександрЖуков-с3ь1л]

Лучший просто, ну почему ты не снимаешь ещё видео?

[@ruslanm.1120]

С интерфейсом - это спорное утверждение, такая подпись нужна, чтобы увидеть от чего наследуем. Как и с приватными свойствами $_private - чтобы визуально облегчить жизнь.

[@bigloafef]

интерфейс не наследуется ...

[@Dmitriy-webdev]

Классный канал! Посмотрел десяток видео подряд и все пролайкал. Респект Вам, Андрей!

[@INONEI]

Андрей, продолжай снимать видео! Буду очень благодарен! И думаю не один я.

[@QwerTy-jn4ex]

Очень лаконично, внятно, понятно ... Короче очень классное видео! Нужно больше видео! )

[@Vi-wv5xc]

Довольно спорный и дискуссионный момент насчет суффиксов Interface, Exception и прочих. К сожалению, тут нету серебренной пули и в итоге все договариваются как писать для конкретного проекта

[@awwarez]

или по поводу namespace \Domain\User\Action\Create.php и \Domain\Deal\Action\Create.php и вот в какой-то точке у вас встречаются эти 2 класса. Есть кончено алиасы - но это очень больший самообман. Или допустим NotFoundException внутри - та же проблема.

[@Denis-xw4om]

Здравствуйте. Interface в конце добавляют те кто следуют PSR Naming Conventions. Это хорошая практика если вы в принципе следуете PSR

[@АндрейШестаков-н6м]

Да, именно данный пункт PSR и считаю спорным. На практике от него отказываются команды, которые стараются следовать прочим правилам PSR.

[@nice1653]

Мой первый коммент за 20лет своей жизни xD; Вам бы стрим еще вести с такой подачей, очень лаконично и просто; p/s Стрим с донатом ;)

[@АндрейШестаков-н6м]

Обет молчания снят, долго Вы его соблюдали :-) Благодарю за отзыв.

[@ЕвгенийУлитин-ц1й]

Отличные видосы. Андрей, очень хорошо преподносишь информацию. Меня особо интересует разные варианты рефакторинга. Как красиво переформатировать многоуровневые if или switch и тому подобные задачки. Был бы рад видеть на канале подобные уроки. Мне кажется на русском ютубе очень не хватает таких роликов. А то всё про то как на laravel сделать блог за час.

[@darknet106]

А почитать книгу чистый код лень?)

[@ЕвгенийУлитин-ц1й]

@@darknet106 Не лень. Прочитано уже. И рефакторинг гуру просмотрен. Но живых примеров из боевых проектов не хватает. Вообще странно на ютубе советовать книгу прочитать. Так то любая тема уже была в книгах описано.

[@oleksandr_mykhailov]

Насчет switch, if/else - мне помог сильно курс по полиморфизму (хекслет) . Но я бы с удовольствием послушал бы материал в подаче Андрея. Тем обширная есть где разгуляться

[@oleksandr_mykhailov]

Материал годный , спасибо Но вот насчет $i в цикле FOR не вполне согласен Когда я вижу такую переменную в цикле, я однозначно понимаю что это числовой индекс массива, никаких других ассоциаций не возникает

[@MultiKilimangaro]

Согласен, $i уже настолько устоялось, что меня бы напряг больше $petNameIndex. Я бы напрягся лихорадочно просматривая цикл, ожидая какое-то нестандартное поведение.

[@henrykarter5802]

@@MultiKilimangaro согласен. Тут по ситуации. Если $i используется только по своему назначению как итератор, то использование другого имени - будет вводить в заблуждение. И наоборот, если переменная используется еще как-то или нам важно что именно в ней записывается, то имеет смысл использовать другое название, чтобы сделать на этом акцент

[@eisp]

Где-то в глубинах памяти засело, что $i в цикле for означает iterator

[@torburgmax]

такое чувство, будто автор в вузе не учился, если его тянет $i переименовывать...

[@adamsai2864]

Спасибо)

[@mrfriz]

Жду следующее видео. Наконец-то годный контент, а не мегапрофессионалы инфоцигане, которые закидывают инфой о том, что нужно учить абстрактные вещи, вообще не связанные с кодом

[@dmitriykret8938]

спасибо

[@ИльяСунцо]

Было бы интересно посмотреть как из массивов сделать коллекции

[@statdotastaff6193]

Спасибо за контент Был бы признателен если бы подсказали подход к расписанию спортивных матчей, где нужно выводить LIVE статус матча, а стартовать по факту они могут раньше/позже от "прематч" расписания Стоит ли тут использовать сокеты?

[@MrJarkheld]

Спасибо. Дорвался до своих старых проектов?)))

[@ЭдуардЕвдокимов-й1о]

Качественный контент. Лайк заслуженный. Однозначное продолжайте. Вопрос по поводу трудоустройства. Нормально ли работодатели смотрят на прием работника не оффициально? Если знания есть, а с документами проблемы из-за политического положения. Возможно ли договориться или сразу гонят?

[@АндрейШестаков-н6м]

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

[@ЕвгенийУлитин-ц1й]

Если контора небольшая, и зп от 50 до 100. То без проблем могут взять. Сейчас в такой работаю. У меня с доками всё норм, но что бы от налогов уходить работодатель официально не нанимает.

[@darknet106]

Будет урок про названия функции?)

[@darknet106]

Какие перспективы по твоему у php на будущее? Будут ли писать на нём новые,интересные,дорогие проекты? Или он останется на уровне поддержки существующих проектов?

[@АндрейШестаков-н6м]

Вопрос сложный, можно только рассуждать: 1. Огромная база сложных проектов, в том числе уровня facebook, wikipedia, e-commerce сектор в России, популярные CMS - WordPress, 1C-Битрикс говорит о востребованности языка в моменте. Инерция задана, внезапно остановить ее уже сложно. 2. Но full-time язык развивают 3 (!), всего три человека в настоящий момент (говорилось в каком-то докладе) и развитие языка мало спонсируется IT-гигантами. Ближайшие 5 лет язык PHP никуда не уйдет скорее всего, в своей web нише он сидит прочно. Но есть причины не ожидать нового взрывного роста популярности и я не могу быть столь же уверенным, если посмотреть на 10-15 лет вперед.

[@darknet106]

@@АндрейШестаков-н6м спасибо за ответ!

[@ruslanm.1120]

$i - наше всё ) Иногда нужно просто перебрать массив, и проще привычную $i или $k или $key, в качестве индекса массива. А использовать $i для координат - это уже очень плохо и непонятно, уж лучше именно там взять название переменной. Если индекс несет смысловую нагрузку, то, конечно, нужна именованная переменная. Когда односимвольные переменные оправданы? -когда используются формулы.

[@ЕвгенийУлитин-ц1й]

По тавтологии, что думаешь по стандартам www.php-fig.org/bylaws/psr-naming-conventions/ ? И когда через автокомплит ищешь нужную сущность - префиксы и суффиксы удобны.

[@АндрейШестаков-н6м]

PSR - отличные стандарты, но, как раз с первыми пунктами в приведенной ссылке по поводу суффиксов не согласен. Зачем они по факту? Без суффиксный подход встречал во всех крупных компаниях где успел поработать. Про автокомплит не совсем понял, удобно и без суффиксов, есть комбинации быстрых клавиш, если нужно прыгать по интерфейсам и реализациям.

[@VladimirKrygin-j4d]

@@АндрейШестаков-н6м если в проекте или фреймворке следуют PSR, то не стоит игнорировать это. Я думаю, эти рекомендации не спроста написаны.

[@darknet106]

А как думаешь людям которые хорошо писали на php будет ли легко переквалифицироваться на другие языки? Например c#,java,pyton. Если да,то сколько примерно времени займет чтобы начать на новом языке получать среднюю ЗП по рынку?

[@АндрейШестаков-н6м]

Если верно понял вопрос, то переход на иной язык подразумевается с его нулевым знанием изначально, верно? От 1-го года я бы сказал. Но это очень абстрактно, все основные практики и подходы везде схожи, а структуры данных и работа с БД вообще идентичны, различается экосистема. Поэтому , кто-то может сказать что и 6 месяцев упорного изучения будет достаточно при хорошей базе знаний на php - и тоже будет правдой.

[@vik2444]

Интерфейс надо согласно psr писать

[@MultiKilimangaro]

убедил. userHaveSubscribed.

[@statdotastaff6193]

Впервые вижу 0 дизлайков на ролике кста)

[@ЕвгенийУлитин-ц1й]

Андрей Шестаков, Хотел бы у тебя спросить как лучше реализовывать в классе передачу данных между методами. Вариант на гитхабе github.com/ulitin-makeit/test_clean_code/tree/main По типу передачи между методами параметров class BasketProducts { private function getProducts(): array { $basket = Basket::load(BASKET_ID); if ($basket->isEmpty()) { return []; } $productsPrices = $this->applyDiscount($basket); $products = []; foreach ($basket->getBasketItems() as $basketItem) { $products[] = $this->getProductInBasketItem($basketItem, $productsPrices); } return $products; } private function getProductInBasketItem(BasketItem $basketItem, array $productsPrices): array { $priceArray = $productsPrices[$basketItem->getId()]; return [ 'ID' => $basketItem->getId(), 'PRICE' => $priceArray, 'QUANTITY_IN_BASKET' => $basketItem->getQuantity() ]; } private function applyDiscount(Basket $basket): array { // много кода и в результате массив с ценами return $result; } public function getAll() { return $this->getProducts(); } } Или избавлением от параметров и выносом их в свойства class BasketProducts { private $basket; private $prices; private function getProducts(): array { $this->basket = Basket::load(BASKET_ID); if ($this->basket->isEmpty()) { return []; } $this->applyDiscount(); return $this->getProductsInBasket(); } private function getProductsInBasket () { $products= []; foreach ($this->basket->getBasketItems() as $basketItem) { $products[] = $this->getProductInBasketItem($basketItem); } return $products; } private function getProductInBasketItem(BasketItem $basketItem): array { $priceArray = $this->prices[$basketItem->getId()]; return [ 'ID' => $basketItem->getId(), 'PRICE' => $priceArray, 'QUANTITY_IN_BASKET' => $basketItem->getQuantity() ]; } private function applyDiscount(): array { // много кода и в результате массив с ценами $this->prices = $result; } public function getAll() { return $this->getProducts(); } }

[@АндрейШестаков-н6м]

Приветствую. Такое ощущение, что это код под Битрикс, но не суть важно. Нужно смотреть на склиентский код, который использует объект BasketProducts. Но можно предложить следующее: 1. $basket - делать полем, как в варинате № 2, но - либо инициализировать его в конструкторе public function __construct() { $this->basket = Basket::load(BASKET_ID); } - либо прокидывать корзину как зависимость (тоже через конструктор) public function __construct(Basket $basket) { $this->basket = $basket; } Причина: к объекту корзины может затребоваться получаться доступ из других методов тоже, передача по параметру излишнее. Basket для класса BasketProducts - это нечто фундаментальное, то есть прямая зависимость без которой BasketProducts и "не заведется" даже. 2. А вот цены лучше не хранить в поле, а как педевать параметром, как в варианте № 1. Причина: возможность доступа к данным всех внутрених методов, когда по факту данные нужны узкому спектру методов класса - может превести к наступлению на грабли. Цены с скидкой - это результат некого вычисления, поэтому BasketProducts может "жить" без поля. Вот. Во всяком случае такой подходит ближе к идеологии фреймворком symfony, laravel.

[@АндрейШестаков-н6м]

А, да, и точно Битрикс. Тогда вместо конструкта там по-момему есть метод инициализации public function executeComponent() - что-то такое

[@ЕвгенийУлитин-ц1й]

@Андрей Шестаков Спасибо за ответ. Да это битрикс. Он конечно совсем не про ооп, особенно если писать в стиле их компонентов. Но стараюсь и с тем что там есть вести порядок. Скажи, где можно в целом почерпнуть знания о том как распределять логику внутри классов и в целом по коду? Прочитал "php 7 в подлинике", там на 1000 детального знакомства с синтаксисом. Потом книгу по Laravel, но и там тоже только описание структуры фреймворка. По ооп и mvc то же что-то читал, но и там всё по верхам описано было. Сейчас читаю "Чистый код" Р. Мартина, треть прочитал. Очень интересно, но для меня слегка маловато кода в примерах. Возможно нужно с какой-то парадигмой ознакомиться, или есть какие-то углублённые книги по ооп?

[@АндрейШестаков-н6м]

@@ЕвгенийУлитин-ц1й я бы тоже хотел однозначночного ответа на данные вопросы =) Скорее всего информацию можно только аккумулировать из разных источников. Как вариант для затравки: 1. Мэтт Зандстра. "PHP. Объекты, шаблоны и методики программирования" 2. Стив Макконнелл "Совершенный код" Плюс знакомство с фреймворками поможет, взять какой-нибудь популярный открытый проект, на основе symfony/laravel и посмотреть как распределен код по классам, архитектурным слоям, методам, модулям и т.п.