Не завидую разрабам, которые к вам будут приходить или от вас уходить. Весь мир пишет по PSR.
Не в поддержку конвенций описанных в статье, но PSR это лишь рекомендации, которые можно соблюдать, а можно и не соблюдать. Некоторые из них хороши, некоторые так себе или не подходят конкретному проекту, некоторые пора пересмотреть.
И нет ничего плохого в отклонении от них в рамках конкретного проекта, или использовании своих, даже если они и противоречат PSR.
P.S. Хабр упорно перемещает мой комментарий не в ту ветку, написал в саппорт.
Хоть бы кто посоветовал учить базу вместо того, чтобы гнаться за новыми технологиями.
Как пример, один раз поняв что такое MVC можно использовать любой web-framework на любом языке, тк они все одинаковые.
Ну, если на то пошло, MVC который Трюгве описал 50 лет назад никакого отношения к современным веб-фреймворками не имеет. Такая себе база :)
А с основным тезисом согласен. Люди учат «как сделано», вместо того чтобы изучать «почему сделано», и основные стабильные концепты упускают.
Так я и говорю что наличие проверки в рантайме гарантируется на стадии компиляции, но если на стадии компиляции всё известно, то проверку в рантайм можно не добавлять.
Реальный индекс может быть известен только в рантайме. Но гарантируя наличие проверки мы гарантируем что выхода за границы при обращении не будет.
С осторожностью стоит к опкэшу подходить — 6 багов только в пятничной 7.4.2 пофиксили, ещё некоторое количество висит, а винду вообще дропнули т.к. без поломки BC не починить.
Без него всё хорошо, как мне кажется.
Например, общение со сторонним провайдером данных, который эти самын данные генерирует левой пяткой.
Мы не можем гарантировать корректность внешней системы, внешнего мира.
В случае получения данных от внешней системы нам в любом случае придётся проверять их на уровне нашего приложения, а там уже некорректность обнаружится и обработается как предполагается.
Больше статических гарантий — это очень хорошо, но в реальном мире у нас бизнес-логика все время лезет в ансейф, и все гарантии именно в трудных местах — идут лесом.
Бизнес логика это весьма неоднозначное понятие, потому я не могу судить, о каких конкретно ограничениях вы говорите. Можете привести примеры?
Договорённости конечно решают, и если такое соглашение на проекте есть то всё ок.
Но их частенько нет, а UserService, UserManager и прочие абсолютно неиформативные названия есть, обычно из-за человеческой лени и нежелания думать над неймингом, а это важно.
Иначе в один момент проект просто превращается в гору *Service и бесконтрольных связей.
Хорошо — давать нормальные имена классам, которые будут давать примерное представление что в этих классах находится.
А «Service» это что?
Если класс называется UserService в него всё-равно в итоге напихают всего, что хоть как-то связано с пользователем.
Заголовок спойлера
Раз уж взялись за связность, привели бы примеры уменьшения от связности — геттеры, например, повыпиливать, которые вы советовали делать в предыдущей статье.
Видимо, веб-разрабочики не сталкивались с проблемами и не пытались их решить, всё-таки большинство работ довольно рутинные
Разработчики без минимального понимания зачем они что-то выбирают, не сталкиваются, да, они их создают.
Ну и изначально я как раз опровергал тезис о том что в веб-разработке есть какой-то зоопарк фреймворков/паттернов или ещё чего-то.
(Нету зоопарка, порог входа низкий. Результаты, увы, соответствующие)
Паттерны эти сами по себе имеют смысл только в попытках побороть определенные проблемы.
Не я начал про паттерны, но всё же:
AR / Repository / Gateway / UoW — это, вобщем-то, штуки которые используются часто(в любом проекте), и часто используются не по назначению / без понимания.
А ООП / MVC и пр. — мне не нравится то что люди очень любят об этом говорить и не особо вкладываются в изчение. Мода и всё.
Проблема узкого кругозора в том что разработчики не видят тот момент когда что-то идёт не так и что-то стоит улучшить.
Если разработчик не понимает Coupling/Cohesion — по каким принципам он вообще проектирует программу?
Обычно это сомнительные бест практики и то самое шаблонное клепание сервисов, что превращается в слабо-поддерживаемое легаси уже на 50-100к строк.
Плохо только то, что многие сознательно игнорируют best inductry practices, дескать намудрили эти джависты лишнего (питонисты добавляют «из-за ограниченности их языка»). Вот это неполезное распространенное явление, и встречается далеко не только в Web.
А можно пример этих «best industry practices»?
А то есть мысль что «Java Best Practices» действительно чушь в 99% случаев.
А тут человеку пишут о явном баге, а он уходит хлопнув дверью.
Просто цель автора в данном случае не быстрый и гаранитированно безопасный веб-сервер, а быстрый веб сервер который готов жертвовать UB ради скорости. Вот и всё.
Фреймворки — это мелочи, в основном знания утяжеляют всякие «паттерны энтерпрайз разработки» и вот это всё.
Так в том и дело, что много разработчиков останавливаются на шаблонном написании процедур в сервисах на каком-нибудь фреймворке, и этого хватает чтобы на работу брали.
А паттерны… Спросите у какого-нибудь веб-разработчика, в чём разница AR и Row Data Gateway, Repository и Gateway, REST и RPC, MVC и MVA, Coupling и Cohesion, ООП и ПП/ФП, зачем какой-нибудь UoW нужен — в лучшем случае теоретиком далёким от разработки не обзовут.
Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Так суть как раз в том чтобы не рассматривать http vs queue как две разных реализации транспорта, а делать меньше запросов за данными, получая и сохраняя информацию заранее у себя через всякие Event Notification и Event-Carried State Transfer.
Но у меня такие вопросы потому что я микросервисы рассматриваю как более явные границы и лучшую изоляцию именно для независимой разработки, если разработчиков много и это действительно нужно.
Иначе я не представляю зачем, да и тот же монолит получается.
в микроконтроллерах меньше учить надо. там нет такого дикого зоопарка фреймворков
Там же зоопарк микроконтроллеров, или нет?
А мейнстрим PHP-фреймворков всего 2 — Symfony и Laravel, и самому молодому из них уже 8 лет, не говоря уже о количестве всяких Laravel-девелоперов(или даже древнего Yii), которые клепают всё на нём и ничего более не умеют.
Да и вообще, давно фреймворки стали чем то сложнее чем набор готовых компонентов реализующих 20-30 лет назад изобретённые паттерны?
У меня стоит полсотни плагинов, Vim запускается почти мгновенно (пол сотни, которые расширяют функционал, более сотни, включая поддержку многих языков и цветовые схемы)
Остальное я даже комментировать не буду, глупости одни.
Ну то есть раз у вас так, значит у всех так? Ясно. Демагогия.
Не в поддержку конвенций описанных в статье, но PSR это лишь рекомендации, которые можно соблюдать, а можно и не соблюдать. Некоторые из них хороши, некоторые так себе или не подходят конкретному проекту, некоторые пора пересмотреть.
И нет ничего плохого в отклонении от них в рамках конкретного проекта, или использовании своих, даже если они и противоречат PSR.
P.S. Хабр упорно перемещает мой комментарий не в ту ветку, написал в саппорт.
Ну, если на то пошло, MVC который Трюгве описал 50 лет назад никакого отношения к современным веб-фреймворками не имеет. Такая себе база :)
А с основным тезисом согласен. Люди учат «как сделано», вместо того чтобы изучать «почему сделано», и основные стабильные концепты упускают.
Реальный индекс может быть известен только в рантайме. Но гарантируя наличие проверки мы гарантируем что выхода за границы при обращении не будет.
Без него всё хорошо, как мне кажется.
А они разве противоречат друг другу?
Мы не можем гарантировать корректность внешней системы, внешнего мира.
В случае получения данных от внешней системы нам в любом случае придётся проверять их на уровне нашего приложения, а там уже некорректность обнаружится и обработается как предполагается.
Бизнес логика это весьма неоднозначное понятие, потому я не могу судить, о каких конкретно ограничениях вы говорите. Можете привести примеры?
Потому что позволяет получать больше статических гарантий, способы получения которых с адекватными трудозатратами и обсуждаются в этой статье.
У вас есть какие-то причины, почему они могут не быть полезны?)
Но их частенько нет, а UserService, UserManager и прочие абсолютно неиформативные названия есть, обычно из-за человеческой лени и нежелания думать над неймингом, а это важно.
Иначе в один момент проект просто превращается в гору *Service и бесконтрольных связей.
Хорошо — давать нормальные имена классам, которые будут давать примерное представление что в этих классах находится.
А «Service» это что?
Если класс называется UserService в него всё-равно в итоге напихают всего, что хоть как-то связано с пользователем.
Разработчики без минимального понимания зачем они что-то выбирают, не сталкиваются, да, они их создают.
Ну и изначально я как раз опровергал тезис о том что в веб-разработке есть какой-то зоопарк фреймворков/паттернов или ещё чего-то.
(Нету зоопарка, порог входа низкий. Результаты, увы, соответствующие)
Не я начал про паттерны, но всё же:
AR / Repository / Gateway / UoW — это, вобщем-то, штуки которые используются часто(в любом проекте), и часто используются не по назначению / без понимания.
А ООП / MVC и пр. — мне не нравится то что люди очень любят об этом говорить и не особо вкладываются в изчение. Мода и всё.
Проблема узкого кругозора в том что разработчики не видят тот момент когда что-то идёт не так и что-то стоит улучшить.
Если разработчик не понимает Coupling/Cohesion — по каким принципам он вообще проектирует программу?
Обычно это сомнительные бест практики и то самое шаблонное клепание сервисов, что превращается в слабо-поддерживаемое легаси уже на 50-100к строк.
А можно пример этих «best industry practices»?
А то есть мысль что «Java Best Practices» действительно чушь в 99% случаев.
*Готов жертвовать некоторыми гарантиями используя unsafe ради скорости, а не UB конечно же, UB оперативно фиксятся, как следует из текста.
Просто цель автора в данном случае не быстрый и гаранитированно безопасный веб-сервер, а быстрый веб сервер который готов жертвовать UB ради скорости. Вот и всё.
Так в том и дело, что много разработчиков останавливаются на шаблонном написании процедур в сервисах на каком-нибудь фреймворке, и этого хватает чтобы на работу брали.
А паттерны… Спросите у какого-нибудь веб-разработчика, в чём разница AR и Row Data Gateway, Repository и Gateway, REST и RPC, MVC и MVA, Coupling и Cohesion, ООП и ПП/ФП, зачем какой-нибудь UoW нужен — в лучшем случае теоретиком далёким от разработки не обзовут.
Так суть как раз в том чтобы не рассматривать http vs queue как две разных реализации транспорта, а делать меньше запросов за данными, получая и сохраняя информацию заранее у себя через всякие Event Notification и Event-Carried State Transfer.
Но у меня такие вопросы потому что я микросервисы рассматриваю как более явные границы и лучшую изоляцию именно для независимой разработки, если разработчиков много и это действительно нужно.
Иначе я не представляю зачем, да и тот же монолит получается.
Так зарабатывает он на платном )
Как и другие фреймворки, вобщем то — экосистема, сертификации.
Там же зоопарк микроконтроллеров, или нет?
А мейнстрим PHP-фреймворков всего 2 — Symfony и Laravel, и самому молодому из них уже 8 лет, не говоря уже о количестве всяких Laravel-девелоперов(или даже древнего Yii), которые клепают всё на нём и ничего более не умеют.
Да и вообще, давно фреймворки стали чем то сложнее чем набор готовых компонентов реализующих 20-30 лет назад изобретённые паттерны?
Ну то есть раз у вас так, значит у всех так? Ясно. Демагогия.