Всё это про «магию». Вечная борьба прямого кода и «магии», которую считают рефакторингом. Но последний делается по факту, а вот «магия» — это часто преждевременная оптимизация.
Автор, переведённой статьи, изобрёл один из небольших разделов «магии» согласно того с чем ему приходится сталкиваться. Она работает на простых проектах. Где модели не содержат сколько-то сложных агрегаторов.
Если принять то, что это «магия» и она может работать в какой-то группе приложения, то я соглашусь с её применением. Когда есть простые модели (контекст laravel, а не DDD) и их связи. Если разработчик один. Пусть.
Но бывает всё сложнее. Бывает нужно передать в сервис несколько репозиториев, а то ещё и другой сервис. После сервиса нужно выполнить нечто инфраструктурное, например, отправить почту и/или пуши, логировать и т.д. на основе успешности выполнения сервиса. Добавим в абстракцию сервиса подписку на события?
Может в сервисе потребоваться дополнительная валидация, так как она нужна не везде, а там где нужна и валидируются не только входящие данные запроса. Её то же повесим абстракцией на сервис?
Но главная проблема — это когда в проекте джуниор или условный мидл начинает писать код по аналогии увиденной «магии», не думая о её востребованности в его части задачи. Ведь понимание чьей-то «магии» так завораживает. Хочется то же стать «магом». Это приятно и побочные эффекты сразу не видны. Причём когда джуниор видит, что «магия» в конкретном случае не работает, то начинается его магия, например, с прямым доступом к моделям (контекст laravel).
Вот тогда задумываешься. С одной стороны можно быстро сделать прототип большой части проекта, а с другой загубить его в самой сложной части.
Может оставить такие вопросы какой-нибудь комиссии стандартизации.
В любом случае можно определится с «чистыми» URI касательно платёжных средств и т.д. Это как маркировка. Понятно что будет куча «не умных» пользователей и «хитрых» бизнесменов. Но можно отстранится от их игр.
Другой вариант подписывать сертификатами целые списки URI, а не только домены. И цветом выделять то что за гранью.
Не обязательно. Просто цветом выделять с когнитивной провокацией домен.Далее после привыкания пользователями к источнику информации можно, что-то более тонко регулировать.
Де факто — латиница уровень один.
Прочие, хоть как на своём языке. Думаю, что для сбера не проблема сайт на латинице.
Здесь дело в чём. Что не латиница — то красим. И пользователей учим, что если радуга — то это не официально.
Что проще всего? Выводить юникод символы цветными (жёлтый) и обозначить требование для серьёзных сайтов необходимость в латинице.
Разделяй, раскрашивай и властвуй через строку браузера!
История с Дарвином не имеет отношения к любопытству. Это чистой воды жадность. Любопытство проявилось, если бы он по очереди совал в рот разных насекомых ради нового опыта.
Самое интересное, что больше всего кислорода в лёгких попадет в кровь при большем количестве углекислого газа во вдыхаемой смеси. Смотрим дыхание по Бутейко.
Когда-то использование Интернета ограничивали интеллектуальный и ценовой ценз. В начале нужно было понимать. Гофер? Ой, что это? Купить и настроить дорогой модем. Платить безумные деньги за не устойчивую связь или мегабайты.
Теперь постепенно уходит интерес. Интернет умрёт как свободное пространство. Но скорее всего возродится как независимые сети для тех, кому они нужны. Всё будет не через сети провайдеров, хотя возможно и через них частично. Непонятный трафик от холодильников и лампочек. На каком основании его фильтровать?
А ещё бываю сайты, на которых при открытии новой вкладки в старой открывается реклама с другого сайта. И как приятно зная это старую вкладку закрыть без напряга для браузера.
Автор, переведённой статьи, изобрёл один из небольших разделов «магии» согласно того с чем ему приходится сталкиваться. Она работает на простых проектах. Где модели не содержат сколько-то сложных агрегаторов.
Если принять то, что это «магия» и она может работать в какой-то группе приложения, то я соглашусь с её применением. Когда есть простые модели (контекст laravel, а не DDD) и их связи. Если разработчик один. Пусть.
Но бывает всё сложнее. Бывает нужно передать в сервис несколько репозиториев, а то ещё и другой сервис. После сервиса нужно выполнить нечто инфраструктурное, например, отправить почту и/или пуши, логировать и т.д. на основе успешности выполнения сервиса. Добавим в абстракцию сервиса подписку на события?
Может в сервисе потребоваться дополнительная валидация, так как она нужна не везде, а там где нужна и валидируются не только входящие данные запроса. Её то же повесим абстракцией на сервис?
Но главная проблема — это когда в проекте джуниор или условный мидл начинает писать код по аналогии увиденной «магии», не думая о её востребованности в его части задачи. Ведь понимание чьей-то «магии» так завораживает. Хочется то же стать «магом». Это приятно и побочные эффекты сразу не видны. Причём когда джуниор видит, что «магия» в конкретном случае не работает, то начинается его магия, например, с прямым доступом к моделям (контекст laravel).
Вот тогда задумываешься. С одной стороны можно быстро сделать прототип большой части проекта, а с другой загубить его в самой сложной части.
И опять же, серебряной пули нет.
В любом случае можно определится с «чистыми» URI касательно платёжных средств и т.д. Это как маркировка. Понятно что будет куча «не умных» пользователей и «хитрых» бизнесменов. Но можно отстранится от их игр.
Другой вариант подписывать сертификатами целые списки URI, а не только домены. И цветом выделять то что за гранью.
Прочие, хоть как на своём языке. Думаю, что для сбера не проблема сайт на латинице.
Здесь дело в чём. Что не латиница — то красим. И пользователей учим, что если радуга — то это не официально.
Разделяй, раскрашивай и властвуй через строку браузера!
Кто меня отхабрит?
Теперь постепенно уходит интерес. Интернет умрёт как свободное пространство. Но скорее всего возродится как независимые сети для тех, кому они нужны. Всё будет не через сети провайдеров, хотя возможно и через них частично. Непонятный трафик от холодильников и лампочек. На каком основании его фильтровать?
Впрочем это другая история.
Даже для игры могут быть количественные правила на выбор опытных игроков. Либо что бы сократить время игры, либо что бы увеличить варианты.
Это ваш личный бизнес или чей-то, а вы наёмный работник?
И сможет ли всё это работать и развиваться без вас?