Спасибо за Ваш труд. Я студент, если более точно, то филолог-магистрант, который давно использует php в качестве хобби на локальном сервере (как могу разбираюсь), мне очень сложно понимать суть некоторых программных решений, но Ваши видео мне очень нравятся, так как они понятны.
Про техлидов соглашусь, встречал говнокод техлидов))) Но потом совместными усилиями перерабатывали и всё становилось нормально. Главное признать свой код, расти дальше, и писать более качественно, чего всем желаю!)
Очень хороший подход в изложении материала. Пересмотрел ваши все уроки. У меня сейчас возник вопрос пакет для Laravel github.com/nWidart/laravel-modules реализовал тоже Porto, или так по другому все реализовано? Я просто свой проект переписал на nWidart/laravel-modules. Пока не понятно правильно я сделал выбор. Жду след ваших уроков.
Просмотрел весь курс, интересно. Внезапно пришла мысль, и решил задать вопрос. А куда в этой архитектуре кладуться вспомогательные классы? Или куда их кладёте конкретно Вы? Я имею в виду, например, классы, реализующие паттерн "Стратегия", "Команда" и проч.
Следуя заветам "кричащей" архитектуры - именуем правильно папки в зависимости от того классы каких логик будут в них находиться. И помним что не каждая логика должна выделяться в таск или сабЭкшон.
Мда, интересная концепция. Ловлю себя на мысли, что строю свои приложения в похожем ключе. То есть, у меня имеются какие-то глобальные класс, абстракции, хелперы, которые юзают модули. Есть модули, которые предназначены для какого-то одного концептуального действия. Вот только всегда были проблемы с взаимодействием модулей между собой. Если возникает такой момент, что результат работы одного модуля зависит от другого, то просто создаю один большой модуль с общей логикой, в который пихаю два модуля поменьше. Более изящных решений я для себя пока не нашёл. Возможно, эта концепция натолкнёт на новые мысли, либо уже содержит то что нужно
Все решают логичные абстракции. к примеру, начиная от контроллера и заканчивая ответом: request->controller -> service-> action -> subAction -> task -> presenter -> transformer -> response. наделение каждого участника(слоя) смыслом, установление протоколов общения между слоями - рождают общие законы. это все полет мысли в рамках проблем, с которыми сталкивался создатель porto. кстати я уже успел позаимствовать ряд идей из порто и успешно применить)
@@korolisimus несомненно, абстракции решают. Но на уровне реализацим я постоянно нахожусь перед выбором создать ещё одну абстракцию на глобальном уровне, т.к. с ней уже могут работать два модуля, либо оставить как есть. Ну ладно, не самый удачный пример навёл. Действительно сложно, когда один модуль, как я писал, зависит от результатов работы другого. Условно один модуль может корректно отработать свою бизнес логику если рабочая модель находятся в нужном состоянии, а само это состояние определяет другой, не связанный модуль. И тогда нужно в своём модуле дёргать другой модуль, из-за чего модульность приложения идёт к чёрту. В этом примере можно решить проблему через ивент бас, но это не панацея. Всё, всё-таки, упирается, по-моему, в сложность бизнес логики и всех её процессов
Еще минутка размышлений, опять про коробочки с коробочками с коробочками. Современные тренды подталкивают нас разрабатывать приложения так, чтобы большая часть кода вызывала другой код, и лишь небольшая его часть - решала реальную задачу. И тут я вижу 2 проблемы. Первая - как объяснить заказчику, что 2-3-5-10-кратное увеличение времени разработки в угоду эстетике оправдано, его ведь интересует решение бизнес-задачи, а ее любой новичок решит в процедурном стиле гораздо быстрее. Мы-то понимаем, что код надо поддерживать, но заказчику обычно пофиг, он хочет как подешевле. И если так, то приходится либо делать нормально и все время рассказывать заказчику, что задачи на самом деле не так просты, как кажутся, либо делать нормально за бесплатно, либо делать плохо и дешево... Ну а какой тут еще может быть путь? Вторая - не существует идеальных задач, которые после десятков вызовов одним кодом другого кода решались бы одной строчкой. Допустим, в проекте есть модель с парой десятков полей, и их пересчет делается одним методом прямо внутри модели. Пересчет не сложный, допустим, на 100 строк. Такой пересчет монолитный - то есть каждое поле гарантированно будет вычислено на основе только что посчитанных других полей. При чтении кода ты эту логику видишь визуально, строка за строкой. И порядок вычисления полей никогда не будет перепутан. Гипотетически такой пересчет можно разбить на пару десятков коротких методов, которые будут считать каждое поле отдельно или несколько полей за 1-10 строк. Вопрос - всегда ли оправдано разбивать. Я считаю, что не всегда. И среди прочего, при чтении кода для меня важно, сколько действий влазит на 1 экран монитора, а чем больше вызовов - тем меньше полезных строк с логикой можно видеть одновременно без прокручивания. К чему это все. К тому, что выбор определенной архитектуры и стиля продиктован не только грамотностью специалиста, но и бюджетом заказчика и спецификой решаемых задач и обрабатываемых данных. Я сейчас не оправдываю говнокод всегда и везде, но утверждаю, что иногда его написание может быть осознанным взвешенным решением. Что в принципе уже звучало в прошлом видео)
Про заказчиков с Вами согласен. Но тут всё куда проще чем выбрать как сегодня строить новый модуль для своего приложения, главное чтобы опыт общения с заказчиками был. Я лично смотрю сколько времени готов заказчик давать на проект и на сколько чётко формулирует свои требования - чем больше времени и лучше формулировка, тем больше усилий я вкладываю в сторону качества и поддерживаемости кода По поводу дробления кода: нужно дробить тогда, когда в этом есть смысл. К примеру, в том же «Чистом коде» делается упор на читаемость кода (и нами, и другими), сильно раздутые и сложные функции сложно читать, а особенно когда много условных ветвлений (есть утверждение, что ветвления ещё и на производительность негативно влияют). Я считаю что нужно дробить когда много больших вычислений и когда есть дублирование кода внутри функции
Не изобретать велосипеды - сомнительное преимущество. Для меня изобретение велосипедов - одна из прелестей профессии, иначе разработчик был бы просто компилятором решений, а весь код выглядел бы как книга, написанная только цитатами из других книг. Тут скорее суть в том, чтобы изобретаемые тобой велосипеды были похожи на другие и понятны тем, кто пытается в них разобраться. Кстати, про Апиато пытался найти видосы - а их просто нет. Значит, с внедрением его в готовом виде как минимум стоит повременить и посмотреть, наберет ли он популярность. Иначе мало толку внедрять архитектуру, которую потом продолжатели проекта не захотят соблюдать из-за ее малой распространенности.
Для джуов, PORTO - это один из принципов для подхода к реализации проекта - не более. Это не Библия и не Коран. Если вы будете слепо следовать его принципам и законам, то рано или поздно запутаетесь в иерахии классов и тупо файлов на диске. Ну. т.е решать базовые концепции, Вам придётся Вас самим, в своём сознании - без помощи Дмитрия. Я имею в виду, что своей башкой надо прежде всего думать, опираясь на знания старых бородатых людей)))
![Porto: Ship [ Структура Корабля ] ► Архитектурный шаблон Порто №2](http://i.ytimg.com/vi/7oflJrPdbMc/mqdefault.jpg)
![Porto: Ship [ Структура Корабля ] ► Архитектурный шаблон Порто №2](/img/tr.png)
Махмуд одобряет!
twitter.com/Mahmoud_Zalt/status/1347260555069894667
Спасибо за Ваш труд. Я студент, если более точно, то филолог-магистрант, который давно использует php в качестве хобби на локальном сервере (как могу разбираюсь), мне очень сложно понимать суть некоторых программных решений, но Ваши видео мне очень нравятся, так как они понятны.
Жду новых видео больше, чем новую серию Мандалорца.
"Все мы когда-то были начинающими специалистами, а говнокодером может быть даже и сеньйор-помидор , и тимЛид , и техЛид и херЛид" сильно сказано)
Про техлидов соглашусь, встречал говнокод техлидов))) Но потом совместными усилиями перерабатывали и всё становилось нормально. Главное признать свой код, расти дальше, и писать более качественно, чего всем желаю!)
Спасибо за видос, очень жду примеры кода) Параллельно смотрю офф документацию по Порто,
Не даст уснуть, в Сибири уже третий час. Пришлось смотреть. Лайк!
блин) приятно увидеть "родного" человека
Благодарю
Прикольно!
ухх. слюнки текут. с нетерпением жду видосы по порто. очень интересно.
Спасиб!
Спасибо, буду ждать новый видео)))
Сразу ставлю лайк, не глядя.)
Прошло 2 месяца и я наконец-то посмотрел это видео. Как всегда на высшем уровне! Жаль второй раз нельзя лайк поставить)
Благодарю!
Очень хороший подход в изложении материала. Пересмотрел ваши все уроки. У меня сейчас возник вопрос пакет для Laravel github.com/nWidart/laravel-modules реализовал тоже Porto, или так по другому все реализовано? Я просто свой проект переписал на nWidart/laravel-modules. Пока не понятно правильно я сделал выбор. Жду след ваших уроков.
Просмотрел весь курс, интересно. Внезапно пришла мысль, и решил задать вопрос. А куда в этой архитектуре кладуться вспомогательные классы? Или куда их кладёте конкретно Вы? Я имею в виду, например, классы, реализующие паттерн "Стратегия", "Команда" и проч.
Следуя заветам "кричащей" архитектуры - именуем правильно папки в зависимости от того классы каких логик будут в них находиться. И помним что не каждая логика должна выделяться в таск или сабЭкшон.
Ещё видео, про порто, пожалуйста.
весьма любопытный способ разработки ПО
видос агонь, сложно найти нормальную инфу про генераторы, не было ли у тебя в планах запилить урок?)
Какие генераторы?
@@DmitryAfanasyev www.php.net/manual/ru/language.generators.php
Но всё же, почему VSC?
Красавчик, всегда что-то интересное и подкинешь))
Мда, интересная концепция. Ловлю себя на мысли, что строю свои приложения в похожем ключе. То есть, у меня имеются какие-то глобальные класс, абстракции, хелперы, которые юзают модули. Есть модули, которые предназначены для какого-то одного концептуального действия. Вот только всегда были проблемы с взаимодействием модулей между собой. Если возникает такой момент, что результат работы одного модуля зависит от другого, то просто создаю один большой модуль с общей логикой, в который пихаю два модуля поменьше. Более изящных решений я для себя пока не нашёл. Возможно, эта концепция натолкнёт на новые мысли, либо уже содержит то что нужно
Все решают логичные абстракции. к примеру, начиная от контроллера и заканчивая ответом: request->controller -> service-> action -> subAction -> task -> presenter -> transformer -> response. наделение каждого участника(слоя) смыслом, установление протоколов общения между слоями - рождают общие законы. это все полет мысли в рамках проблем, с которыми сталкивался создатель porto. кстати я уже успел позаимствовать ряд идей из порто и успешно применить)
@@korolisimus несомненно, абстракции решают. Но на уровне реализацим я постоянно нахожусь перед выбором создать ещё одну абстракцию на глобальном уровне, т.к. с ней уже могут работать два модуля, либо оставить как есть. Ну ладно, не самый удачный пример навёл. Действительно сложно, когда один модуль, как я писал, зависит от результатов работы другого. Условно один модуль может корректно отработать свою бизнес логику если рабочая модель находятся в нужном состоянии, а само это состояние определяет другой, не связанный модуль. И тогда нужно в своём модуле дёргать другой модуль, из-за чего модульность приложения идёт к чёрту. В этом примере можно решить проблему через ивент бас, но это не панацея. Всё, всё-таки, упирается, по-моему, в сложность бизнес логики и всех её процессов
Еще минутка размышлений, опять про коробочки с коробочками с коробочками. Современные тренды подталкивают нас разрабатывать приложения так, чтобы большая часть кода вызывала другой код, и лишь небольшая его часть - решала реальную задачу. И тут я вижу 2 проблемы.
Первая - как объяснить заказчику, что 2-3-5-10-кратное увеличение времени разработки в угоду эстетике оправдано, его ведь интересует решение бизнес-задачи, а ее любой новичок решит в процедурном стиле гораздо быстрее. Мы-то понимаем, что код надо поддерживать, но заказчику обычно пофиг, он хочет как подешевле. И если так, то приходится либо делать нормально и все время рассказывать заказчику, что задачи на самом деле не так просты, как кажутся, либо делать нормально за бесплатно, либо делать плохо и дешево... Ну а какой тут еще может быть путь?
Вторая - не существует идеальных задач, которые после десятков вызовов одним кодом другого кода решались бы одной строчкой. Допустим, в проекте есть модель с парой десятков полей, и их пересчет делается одним методом прямо внутри модели. Пересчет не сложный, допустим, на 100 строк. Такой пересчет монолитный - то есть каждое поле гарантированно будет вычислено на основе только что посчитанных других полей. При чтении кода ты эту логику видишь визуально, строка за строкой. И порядок вычисления полей никогда не будет перепутан. Гипотетически такой пересчет можно разбить на пару десятков коротких методов, которые будут считать каждое поле отдельно или несколько полей за 1-10 строк. Вопрос - всегда ли оправдано разбивать. Я считаю, что не всегда. И среди прочего, при чтении кода для меня важно, сколько действий влазит на 1 экран монитора, а чем больше вызовов - тем меньше полезных строк с логикой можно видеть одновременно без прокручивания.
К чему это все. К тому, что выбор определенной архитектуры и стиля продиктован не только грамотностью специалиста, но и бюджетом заказчика и спецификой решаемых задач и обрабатываемых данных. Я сейчас не оправдываю говнокод всегда и везде, но утверждаю, что иногда его написание может быть осознанным взвешенным решением. Что в принципе уже звучало в прошлом видео)
Про заказчиков с Вами согласен. Но тут всё куда проще чем выбрать как сегодня строить новый модуль для своего приложения, главное чтобы опыт общения с заказчиками был. Я лично смотрю сколько времени готов заказчик давать на проект и на сколько чётко формулирует свои требования - чем больше времени и лучше формулировка, тем больше усилий я вкладываю в сторону качества и поддерживаемости кода
По поводу дробления кода: нужно дробить тогда, когда в этом есть смысл. К примеру, в том же «Чистом коде» делается упор на читаемость кода (и нами, и другими), сильно раздутые и сложные функции сложно читать, а особенно когда много условных ветвлений (есть утверждение, что ветвления ещё и на производительность негативно влияют). Я считаю что нужно дробить когда много больших вычислений и когда есть дублирование кода внутри функции
Фреймворк во фреймворке получается?
Не совсем... Фреймворк он массу функционала предлагает... А слой корабля ничего из подобного не предлагает.
супер! го код писать!!!!!!
Я херЛид у нас на проекте
Херлид)))
махмуд и "правильное решение" вызывает когнитивный диссонанс
Не изобретать велосипеды - сомнительное преимущество. Для меня изобретение велосипедов - одна из прелестей профессии, иначе разработчик был бы просто компилятором решений, а весь код выглядел бы как книга, написанная только цитатами из других книг. Тут скорее суть в том, чтобы изобретаемые тобой велосипеды были похожи на другие и понятны тем, кто пытается в них разобраться.
Кстати, про Апиато пытался найти видосы - а их просто нет. Значит, с внедрением его в готовом виде как минимум стоит повременить и посмотреть, наберет ли он популярность. Иначе мало толку внедрять архитектуру, которую потом продолжатели проекта не захотят соблюдать из-за ее малой распространенности.
Porto = nuxt.js
Для джуов, PORTO - это один из принципов для подхода к реализации проекта - не более. Это не Библия и не Коран. Если вы будете слепо следовать его принципам и законам, то рано или поздно запутаетесь в иерахии классов и тупо файлов на диске. Ну. т.е решать базовые концепции, Вам придётся Вас самим, в своём сознании - без помощи Дмитрия. Я имею в виду, что своей башкой надо прежде всего думать, опираясь на знания старых бородатых людей)))
Роберт Мартин в помощь