C этим утверждением согласен, поскольку именно Maybe на 100% правильно реализовать через await не удается, об этом сказано в конце статьи. Но, все же вариант с await, мне кажется, лучше, поскольку избавляет нас от лямбд, что положительно сказывается на читабельности программы.
А зачем их видеть в сигнатурах функций? Исключения, должны (в теории) сигнализировать о нештатной работе программы, которая может быть вызвана:
1) Ошибкой программе – тут поможет только выпуск новой версии с исправлением
2) Ошибкой конфигурации – например, неправильный Connection String
3) Внешней проблемой среды — например, отсутствует соединение с сетью или
нехватка памяти.
Все эти сценарии непредсказуемы и могут возникнуть при вызове абсолютно любой функции. Реакцией на них может быть только корректное завершение текущего логического действия (http запрос, событие onclick и т.д.) с извещением пользователя о нештатной ситуации.
В случае же когда ошибки допускаются логикой программы, например ошибка пользовательского ввода, то исключения использоваться не должны. Хотя, к сожалению, в реальности это происходит сплошь и рядом.
Предложенная методика — да, нарушает, но есть вариант который внутри себя использует исключения, и в нем все нормально с using-ами. Единственная его проблема — это, собственно, сам факт использования исключений.
Если GetData() НЕ вернет Mabe.Nothing, то Dispose будет вызван, в противном же случае, вызова Dispose не будет. Об этом есть пара предложений в конце статьи
Кроме того, можно и вовсе забыть сделать проверку возвращаемого значения, и получить какой-нибудь NullReferenceException в Runtime-е (это в лучшем случае)
Я наблюдаю другую картину, новых сотрудников компании вынуждены набирать на основе текущих зарплатных ожиданий которые в разы отличаются от тех, что были 10 лет назад (спасибо курсу рубля и иностранному аутсорсу). Старым же сотрудникам можно дать видимость индексации (несколько процентов в год), либо вообще не поднимать зарплату ссылаясь на "трудные времена".
“Service Locator” is a part of almost any dependency injection library that I know. In most cases it is used implicitly and that mitigates the “anti” part of the pattern, but it has a side effect – all injected dependencies will be always resolved regardless of whether they are needed or not and sometimes that resolving might be resource consuming especially in the case when some dependency has the “per request” lifecycle.
Personally, I think that the “Service Locator” is just as anti-pattern as the “dependency injection” itself.
Привязка своего бизнеса к какому-то одному сервису всегда несет в себе огромное количество рисков. Сколько уже было случаев, когда Эпл или Гугол, часто вообще безосновательно, блокировали приложения ставя компании на грань банкротства. Кроме того, сам сервис может совершенно внезапно перестать существовать. Так что, нужно все тщательно взвесить и если решили использовать некий сервис как основу бизнеса, то нужно продумать, что делать в случае, если сервис внезапно перестанет быть доступным.
Вообще странно, что позицию тим лида рассматривают как промежуточную или даже тупиковую. По моему мнению, это вершина профессионального роста работника из IT сферы после которой наступает лишь деградация, ведь основной признак тим лида — это способность заменить ЛЮБОГО члена команды, пусть и не со 100% эффективностью, то есть своего рода "стволовая клетка " в организме проекта.
И тут есть вопрос, а имеет ли смысл вкладываться в документацию того, что всё равно пойдёт под нож через полгода?
Через полгода или через 10 лет — это сложно предсказать, но любой программный продукт со временем обрастает функционалом который нигде кроме как в коде не описан и который всегда теряется при переписывании, вызывая стойкую неприязнь к различного рода обновлениям и “улучшениям” у большинства пользователей.
Это совершенно логично, когда есть работающий продукт, то бизнесу очевидно ради чего стоит вкладываться (или очевидно, что вкладываться не не нужно). С технической же точки зрения становится видно, каким аспектам надо уделить особое внимание. В общем надо заранее готовиться, что хорошее ПО, скорее всего, надо будет создать дважды.
Ссылка из вашей статьи ведет на страничку в Википедии, где эта ситуация объясняется («Критика принципа Парето»). Можно привести в качестве примера строительство дома, где на проект, коммуникации, фундамент и п.р. тратятся огромные ресурсы, но доход приносит только продажа помещений. Кстати, современная разработка софта как раз напоминает ситуацию, когда сначала строим квартирки, а потом пытаемся подвести под них фундамент и коммуникации, хотя идея была сначала поставить бытовки и если в них кто-то поселился, то уже строить нормальный дом.
Важно отметить, что повторные запросы будут работать только при условии поддержки идемпотентности со стороны сервера. Например (пример утрированный), вы нажимаете кнопку "Купить Пылесос" и в этот момент въезжаете в тоннель, сколько пылесосов у вас будет при выезде из тоннеля? На хабре была статься по этому поводу: "Про стажера Васю" https://m.habr.com/ru/company/yandex/blog/442762/
Typescript, конечно, классная вещь, но хотя некоторые концепции требуют немалого напряжения извилин, так например Mapped Types осознать было не просто, но зато когда, наконец, понимаешь это, то поражаешься, насколько мощный это инструмент. С помощью этих Mapped Types создал свою библиотечку для управления состоянием в Angular, и теперь задумался — может ее и для Vue можно адаптировать.
C этим утверждением согласен, поскольку именно Maybe на 100% правильно реализовать через await не удается, об этом сказано в конце статьи. Но, все же вариант с await, мне кажется, лучше, поскольку избавляет нас от лямбд, что положительно сказывается на читабельности программы.
1) Ошибкой программе – тут поможет только выпуск новой версии с исправлением
2) Ошибкой конфигурации – например, неправильный Connection String
3) Внешней проблемой среды — например, отсутствует соединение с сетью или
нехватка памяти.
Все эти сценарии непредсказуемы и могут возникнуть при вызове абсолютно любой функции. Реакцией на них может быть только корректное завершение текущего логического действия (http запрос, событие onclick и т.д.) с извещением пользователя о нештатной ситуации.
В случае же когда ошибки допускаются логикой программы, например ошибка пользовательского ввода, то исключения использоваться не должны. Хотя, к сожалению, в реальности это происходит сплошь и рядом.
Я наблюдаю другую картину, новых сотрудников компании вынуждены набирать на основе текущих зарплатных ожиданий которые в разы отличаются от тех, что были 10 лет назад (спасибо курсу рубля и иностранному аутсорсу). Старым же сотрудникам можно дать видимость индексации (несколько процентов в год), либо вообще не поднимать зарплату ссылаясь на "трудные времена".
У статьи очень неприятный нравоучительный тон. Обвинения в зазнайстве в таком контексте выглядят, как минимум, странно.
Personally, I think that the “Service Locator” is just as anti-pattern as the “dependency injection” itself.
Вообще странно, что позицию тим лида рассматривают как промежуточную или даже тупиковую. По моему мнению, это вершина профессионального роста работника из IT сферы после которой наступает лишь деградация, ведь основной признак тим лида — это способность заменить ЛЮБОГО члена команды, пусть и не со 100% эффективностью, то есть своего рода "стволовая клетка " в организме проекта.
Через полгода или через 10 лет — это сложно предсказать, но любой программный продукт со временем обрастает функционалом который нигде кроме как в коде не описан и который всегда теряется при переписывании, вызывая стойкую неприязнь к различного рода обновлениям и “улучшениям” у большинства пользователей.
Это совершенно логично, когда есть работающий продукт, то бизнесу очевидно ради чего стоит вкладываться (или очевидно, что вкладываться не не нужно). С технической же точки зрения становится видно, каким аспектам надо уделить особое внимание. В общем надо заранее готовиться, что хорошее ПО, скорее всего, надо будет создать дважды.
Кстати, современная разработка софта как раз напоминает ситуацию, когда сначала строим квартирки, а потом пытаемся подвести под них фундамент и коммуникации, хотя идея была сначала поставить бытовки и если в них кто-то поселился, то уже строить нормальный дом.
Про закон Парето (20/80) — он конечно работает, но загвоздка в том, что усилилий все равно надо затратить 100%
Важно отметить, что повторные запросы будут работать только при условии поддержки идемпотентности со стороны сервера. Например (пример утрированный), вы нажимаете кнопку "Купить Пылесос" и в этот момент въезжаете в тоннель, сколько пылесосов у вас будет при выезде из тоннеля? На хабре была статься по этому поводу: "Про стажера Васю" https://m.habr.com/ru/company/yandex/blog/442762/