...и последнее, что в этом посте указано из непосредственно программирования, как основной рабочей деятельности, это:
В 1990 году я устроился по контракту в Rational, работая в C++ над первым выпуском Rational Rose. Здесь я познакомился с Гради Бучем и разработал план своей первой книги.
далее лишь изучение новых языков:
Я успел немного позаигрывать с Golang, Elixr и Kotlin, и я с трепетом смотрел на Haskel. Я даже пробовал с Scala и F#.
Расширять кругозор - безусловно, нужно. Но это совершенно не подтверждает наличие хоть какого-либо практического опыта, особенно в энтерпрайз разработке и просто на больших проектах (где как раз становится актуальным SOLID и другие способы снижения сложности кода). Хотя бы в этом тысячелетии, что весьма желательно в стремительно развивающейся отрасли.
Роберт Мартин — известный программист со стажем, реализовал огромное число проектов.
Какие проекты Роберт Мартин "реализовал" как программист? На его сайте об этом ни слова. На википедии следующее:
In 1991, Martin founded Object Mentor, now defunct, which provided instructor-led training on the extreme programming methodology.[citation needed] As of March 2020, he operated two companies:[citation needed]
Uncle Bob Consulting – provides consulting and training services
Clean Coders – which provides training videos
Даже в своем собственном блоге Мартин предпочитал подавать себя прежде всего как консультант. От блога, кстати, я давно отписался по причине огромного количества воды и рекомендаций в стиле "нормально делай - нормально будет".
Снимал в Актау в апреле: банкоматы сбера выдают тенге с рублёвой МИР без проблем. Банкоматы и терминалы Халых банка работать с этой же картой отказались, несмотря на заявленную поддержку.
Да с самой технологией всё хорошо. Вот только, как раз благодаря стабильности WCF — ценность новых helloworld-ов на full .NET не так уж и велика. Например, официальная документация по этой теме — на мой взгляд, куда более читабельная. От Хабра всё-таки ждешь глубины, а не полноэкранных скриншотов пустого окна Студии.
У меня конфигурация похожая на вашу, из упомянутых папок на диске C: осталась только appdata, и то не вся, остальное уехало на RAM-диск, включая некоторые инстансы самой студии. Проблем не испытываю, студия обновляется, сторонние приложения работают — год-полтора уже как.
Читайте спецификации, и мрака не будет. .NET Core 2.0 preview 1 на данный момент поддерживается только в VS 2017 Preview version 15.3, которая устанавливается отдельно. Ничего необычного в этом нет, preview на то и preview.
Вообще-то в статье речь про ASP.NET Core. Где SynchronizationContext отсутствует в принципе. Поэтому ConfigureAwait(false) имеет смысл только из соображений обратной совместимости с classic ASP.NET и проч.
P.S. Подкрепить свои слова ссылкой — и куда более весомо, и куда вежливей, чем посылание в гугл.
Безлимитный, ага. Если куплен Amazon Prime за $99 в год. Раньше у Амазона действительно был дешевый тарифный план (порядка 10-20 долларов в год) с безлимитным хранением фото, включая формат RAW, но этот план закрыли уже с полгода назад.
Никаких Guard'ов, особенно реализованных в каких либо Shared/Common или в сторонних библиотеках
Может вообще сторонним библиотекам не доверять? Убрать из кода Json.NET, Moq, Dapper… они делают не менее критичную работу, чем проверка на null.
Никто не может гарантировать корректную реализацию таких вот сторожей, их правильною доработку/развитие.
А кто гарантирует корректную реализацию остального кода, который вы пишете?
Плюс, как писали выше, с ростом исключительных ситуаций, такие классы начинают разрастаться вширь перегрузками, в которых не разобраться со временем.
Сложно представить проект, в котором набор простейших проверок на null, длины строки и т.п. может быть ощутимо сложнее остальной части кода вплоть до "не разобраться". А если вы поместили в гвард бизнес-логику, то это уже не Guard, и на вас налагаются такие же обязанности по обслуживанию этой логики, как и по отношению к остальной части бизнесового кода.
Особенно проблемы с зависимостями могут проявиться, если такие классы реализованы в других библиотеках.
В другой ветке справедливо заметили, что решение проблемы топикстартера по выпиливанию/рефакторингу гвардов решается решарпером за минуты.
Согласен, но если DI в проекте прописан на уровне соглашений, подобные проверки в конструкторе переводятся из разряда "обязательно" в разряд "возможно".
При этом в библиотеках с вашими сервисами еще и появится лишняя зависимость — Microsoft.Extensions.Options.
Ваша мысль, безусловно, здравая, но, если хочется избежать зависимости от IOptions<T>, что помешает считать конфигурацию в ваш собственный класс и зарегистрировать в контейнере как синглтон? Заметьте, это решение будет работать с любым DI-контейнером, в отличие от вашего Autofac-specific кода.
бОльшую часть вашего ConfigureServices займет код
решается рефакторингом.
P.S. Борьба с "лишними" зависимостями иногда напоминает одержимость примитивными типами.
Точно также разработчик может забыть проставить "разрешающий" атрибут, и обе ситуации проверяются code review и тестами. Атрибут любого такого типа над защищаемым action означает некоторое изменение (усиление, либо ослабление) политики, принятой по-умолчанию. Безусловно, политика по-умолчанию может быть "запрещать всё", и зависит от конкретного приложения: стоит учесть и безопасность, и удобство разработки (чем меньше ручной работы — тем лучше).
+1 к VolCh, применение ORM вовсе не означает, что все ваши SQL-запросы автоматически становятся на порядки медленнее. Напротив, во многих случаях падения производительности по сравнению с хранимыми процедурами вообще нет, особенно для простого CRUD. Для сложных составных запросов — да, расхождения возможны, но вам никто не запрещает переписать обнаруженные узкие места на хранимках и view. Воспринимайте ORM как средство быстрого прототипирования, и не забывайте о известном высказывании касательно предварительной оптимизации.
...и последнее, что в этом посте указано из непосредственно программирования, как основной рабочей деятельности, это:
далее лишь изучение новых языков:
Расширять кругозор - безусловно, нужно. Но это совершенно не подтверждает наличие хоть какого-либо практического опыта, особенно в энтерпрайз разработке и просто на больших проектах (где как раз становится актуальным SOLID и другие способы снижения сложности кода). Хотя бы в этом тысячелетии, что весьма желательно в стремительно развивающейся отрасли.
Почувствуйте разницу, к примеру, с содержимым блога и резюме Mark Seeman https://blog.ploeh.dk/hire-me/
Какие проекты Роберт Мартин "реализовал" как программист? На его сайте об этом ни слова. На википедии следующее:
Даже в своем собственном блоге Мартин предпочитал подавать себя прежде всего как консультант. От блога, кстати, я давно отписался по причине огромного количества воды и рекомендаций в стиле "нормально делай - нормально будет".
Снимал в Актау в апреле: банкоматы сбера выдают тенге с рублёвой МИР без проблем. Банкоматы и терминалы Халых банка работать с этой же картой отказались, несмотря на заявленную поддержку.
Для создания иерархии объектов и разрешения зависимостей можно было просто использовать DI-контейнер. Он для этого и предназначен.
Да с самой технологией всё хорошо. Вот только, как раз благодаря стабильности WCF — ценность новых helloworld-ов на full .NET не так уж и велика. Например, официальная документация по этой теме — на мой взгляд, куда более читабельная. От Хабра всё-таки ждешь глубины, а не полноэкранных скриншотов пустого окна Студии.
и держать для этого отдельный поток с таймером?
У меня конфигурация похожая на вашу, из упомянутых папок на диске C: осталась только appdata, и то не вся, остальное уехало на RAM-диск, включая некоторые инстансы самой студии. Проблем не испытываю, студия обновляется, сторонние приложения работают — год-полтора уже как.
Читайте спецификации, и мрака не будет. .NET Core 2.0 preview 1 на данный момент поддерживается только в VS 2017 Preview version 15.3, которая устанавливается отдельно. Ничего необычного в этом нет, preview на то и preview.
Вообще-то в статье речь про ASP.NET Core. Где SynchronizationContext отсутствует в принципе. Поэтому ConfigureAwait(false) имеет смысл только из соображений обратной совместимости с classic ASP.NET и проч.
P.S. Подкрепить свои слова ссылкой — и куда более весомо, и куда вежливей, чем посылание в гугл.
И подсказывает разные упражнения для глаз.
Может вообще сторонним библиотекам не доверять? Убрать из кода Json.NET, Moq, Dapper… они делают не менее критичную работу, чем проверка на null.
А кто гарантирует корректную реализацию остального кода, который вы пишете?
Сложно представить проект, в котором набор простейших проверок на null, длины строки и т.п. может быть ощутимо сложнее остальной части кода вплоть до "не разобраться". А если вы поместили в гвард бизнес-логику, то это уже не Guard, и на вас налагаются такие же обязанности по обслуживанию этой логики, как и по отношению к остальной части бизнесового кода.
В другой ветке справедливо заметили, что решение проблемы топикстартера по выпиливанию/рефакторингу гвардов решается решарпером за минуты.
Согласен, но если DI в проекте прописан на уровне соглашений, подобные проверки в конструкторе переводятся из разряда "обязательно" в разряд "возможно".
… а получение зависимостей через DI и вовсе делает избыточными null-check в конструкторе.
Ваша мысль, безусловно, здравая, но, если хочется избежать зависимости от
IOptions<T>, что помешает считать конфигурацию в ваш собственный класс и зарегистрировать в контейнере как синглтон? Заметьте, это решение будет работать с любым DI-контейнером, в отличие от вашего Autofac-specific кода.решается рефакторингом.
P.S. Борьба с "лишними" зависимостями иногда напоминает одержимость примитивными типами.
А как же самый простой способ, работающий в Core "из коробки" — передача самих параметров конфигурации через DI при помощи IOptions?
Точно также разработчик может забыть проставить "разрешающий" атрибут, и обе ситуации проверяются code review и тестами. Атрибут любого такого типа над защищаемым action означает некоторое изменение (усиление, либо ослабление) политики, принятой по-умолчанию. Безусловно, политика по-умолчанию может быть "запрещать всё", и зависит от конкретного приложения: стоит учесть и безопасность, и удобство разработки (чем меньше ручной работы — тем лучше).
+1 к VolCh, применение ORM вовсе не означает, что все ваши SQL-запросы автоматически становятся на порядки медленнее. Напротив, во многих случаях падения производительности по сравнению с хранимыми процедурами вообще нет, особенно для простого CRUD. Для сложных составных запросов — да, расхождения возможны, но вам никто не запрещает переписать обнаруженные узкие места на хранимках и view. Воспринимайте ORM как средство быстрого прототипирования, и не забывайте о известном высказывании касательно предварительной оптимизации.