День 1054. #Карьера
Чему Можно Научиться из Книг «Программист-прагматик» и «Идеальный программист». Часть 4
Часть 1
Часть 2
Часть 3

6. Как справляться с давлением
Этот совет поможет вам и вне разработки программного обеспечения. Рано или поздно вы окажетесь под давлением, и лучший способ справиться с этим - избегать таких ситуаций, когда это возможно, и выдерживать давление, когда его невозможно избежать.

Лучший способ сохранять спокойствие под давлением - избегать ситуаций, вызывающих давление.
— Идеальный программист

В основном вы можете избежать этого, соблюдая обязательства, соблюдая чистоту и следуя правилам. Лучший способ справиться с обязательствами — отказаться от сроков, если вы не уверены, что сможете в них уложиться. Соблюдение чистоты, по сути, означает, что у вас нет беспорядка в ваших системах, коде и дизайне.

Чтобы двигаться быстро и не нарушать сроков, в коде необходимо сохранять чистоту. Профессионал не поддаётся искушению устроить грязь в коде, чтобы быстро двигаться вперед. Грязно — всегда значит медленно!
— Идеальный программист

Следуйте правилам, в которые вы действительно верите, и придерживайтесь их всё время, независимо от ситуации. Придут кризисные времена, и тогда вам нужно будет обратить внимание на то, как вы себя ведёте. Если вы продолжите следовать своим правилам, это означает, что вы уверены в них. Если вы измените своё поведение и не будете следовать своим правилам, это будет означать, что вы на самом деле не верите в свои правила, и вам придётся их изменить, чтобы стать лучше.

Если вы следуете методологии разработки через тестирование в обычное время, но отказываетесь от неё во время кризиса, значит вы не верите в полезность TDD. Если ваш код остаётся чистым в обычное время, а в кризис вы разводите в нем грязь, значит вы не верите, что грязь замедляет вашу работу. Если вы используете парное программирование во время кризиса, но не в обычной ситуации, значит вы полагаете, что парное программирование эффективнее индивидуального.
— Идеальный программист

Но не всегда удается избежать давления, поэтому нужно научиться с ним справляться. Вы можете выдержать его, сохраняя спокойствие, общаясь, следуя своим правилам и прося о помощи. Возьмите свой стресс под контроль. Бессонные ночи не помогут выполнить работу быстрее. Конфликты тоже не помогут. Но худшее, что вы можете сделать, — это спешить! Боритесь с этим искушением любой ценой. Спешка только затянет вас ещё глубже на дно. Наоборот, притормозите и продумайте задачу. Проложите курс к лучшему из возможных решений, а затем двигайтесь по этому курсу в раз-
умном, стабильном темпе. Убедитесь, что вы постоянно общаетесь со своей командой и начальством, и сообщаете им, когда у вас возникают проблемы, чтобы вы могли получать отзывы и рекомендации. Так в итоге ни для кого возможные проблемы не станут сюрпризом.

Избегайте сюрпризов. Ничто не делает людей более злыми и менее рациональными, чем сюрпризы. Сюрпризы умножают давление на десять.
— Идеальный программист

Совет по общению включает в себя обращение за помощью к товарищам по команде, к начальству или к интернет-сайтам и форумам. Но и не забывайте помогать другим, когда они находятся под давлением и нуждаются в помощи.

Продолжение следует…

Источник: https://www.freecodecamp.org/news/lessons-learned-from-the-pragmatic-programmer-and-the-clean-coder/

День 1055. #ЗаметкиНаПолях
Следует ли Абстрагироваться от Базы Данных?
Мнение, что, имея слой абстракции, можно легко переключиться с одной БД на другую широко распространено среди многих программистов. Но даже при том, что оно довольно популярно, оно неверно. Это явление называется ложным мифом об абстрагировании от базы данных.

Давайте проанализируем его и посмотрим, что именно тут не так.

Привязка к поставщику
Основное преимущество абстрагирования вашей БД — это избежание привязки к поставщику. Другими словами, если по какой-либо причине вы захотите отказаться от текущей СУБД, вы легко сможете это сделать. Чтобы сделать возможным такой переход, вы должны спроектировать свой уровень доступа к данным так, чтобы он поддерживал несколько реализаций базы данных. Для этого вы вводите интерфейс, вроде IDataAccess, а затем предлагаете реализацию для вашей текущей СУБД.

Видимое и невидимое
Поначалу это звучит разумно, но, принимая решение, вы должны учитывать обе стороны:
- Желаемые результаты, которые являются видимой частью уравнения.
- Непредвиденные последствия, невидимая часть.

В контексте абстрагирования от базы данных:
- Видимая часть — это преимущества, которые даёт вам абстракция.
- Невидимая часть — это (часто скрытая) стоимость этой абстракции.

Какова же стоимость этой абстракции?
Стоимость — это всё время, которое потребовалось вам для реализации этой возможности. Вот почему абстрагирование от базы данных — это антипаттерн. Люди часто ценят преимущества этой абстракции, потому что они очевидны: тот факт, что переключиться легко, очевиден для всех.
Но они редко учитывают его недостатки, потому что недостатки невидимы. Как только вы вводите дополнительную сложность для абстрагирования от базы данных, вы воспринимаете это как данность. Вам просто не с чем сравнивать, поэтому дополнительное время, которое вам потребовалось для поддержания этой абстракции, остаётся незамеченным.

Но это дополнительное время огромно. Как говорится, «недели программирования могут сэкономить вам часы планирования». Именно это получается, когда кто-то хвастается, что сэкономил 2 дня при переходе на другую базу данных. Вероятно, им потребовалось несколько недель дополнительного времени, чтобы сделать это возможным. И в будущем это будет стоить дороже! Внедрение абстракции — не просто одноразовое действие, вам придётся поддерживать её на протяжении всего проекта, даже если больше никогда не придётся переключаться снова.

Наименьший общий делитель
Другая проблема заключается в том, что вы не сможете использовать расширенные функции, имеющиеся в вашей текущей СУБД. Вы привязаны к наименьшему общему делителю — функциональности, которая присутствует во всех реляционных базах данных, что означает, что вы не можете полностью раскрыть потенциал своей базы данных.
Это не сработает, и вы обнаружите это слишком поздно
Основная проблема заключается в том, что как бы вы ни старались, между разными СУБД будут возникать мелкие, а то и не очень мелкие различия, которые могут кардинально повлиять на то, как будет работать ваше приложение.

Что же делать?
Просто следуйте YAGNI и работайте со своей текущей базой данных, как будто вы никогда не собираетесь отказываться от нее. Скорее всего, вы никогда этого не сделаете, и все ваши абстракции в любом случае пропадут зря.

А если вам всё же нужно переключиться, подходите к процессу переключения не просто как к отказу от одной реализации IDataAccess в пользу другой, а как к портированию: вы портируете своё приложение с одной СУБД на другую.

Главный инструмент, который поможет добиться успеха при портировании, —качественные интеграционные тесты, т.е. тесты, которые не имитируют вашу базу данных, а реально обращаются к ней.

Источник: https://enterprisecraftsmanship.com/posts/should-you-abstract-database/

День 1056. #ЗаметкиНаПолях
Удалите Эти Бесполезные Вызовы File.Exists
Часть можно встретить код, который использует File.Exists(path) перед открытием/записью файла. Этот шаблон очень подозрительный и может привести к неожиданным ошибкам. Рассмотрим следующий код:

if (File.Exists(path))
{
  // Это безопасно?
  using var stream =
    File.Open(path, FileMode.Open);
  // …
}

Есть несколько причин отказаться от этого подхода. На самом деле, другие приложения, работающие на машине, могут изменить файл между проверкой и вызовом File.Open:
- Файл может быть удалён другим приложением (в том числе антивирусом).
- Может отключиться диск или сеть
- и т.п.

Кроме того, даже если файл существует, возможно, вы не сможете его открыть:
- Что там с разрешениями?
- Может файл только для чтения/скрытый?
- Что делать, если файл заблокирован (в общем доступе)?
- Что, если на диске есть ошибка?

File.Exists указывает, существует ли указанный файл на момент его проверки. Возвращённое значение устаревает, как только метод возвращается. Если метод возвращает true, это не означает, что файл всё ещё будет существовать, когда вы попытаетесь его открыть.

Вместо того, чтобы проверять, существует ли файл/каталог перед выполнением действия, просто добавьте обработку ошибок:

try
{
  using var stream = File.Open(path, FileMode.Open);
  // …
}
catch (FileNotFoundException)
{
  // …
}
catch (DirectoryNotFoundException)
{
  // …
}
catch (UnauthorizedAccessException)
{
  // …
}
catch (Exception)
{
  // …
}

То же касается проверки папок. Вместо:

if (!Directory.Exists(path))
{
  Directory.CreateDirectory(path);
}

Должно быть:

Directory.CreateDirectory(path);

Вместо:

if (Directory.Exists(path))
{
  Directory.Delete(path);
}

Должно быть:

try
{
  Directory.Delete(path);
}
catch(DirectoryNotFoundException)
{
  // ОК
}
catch(Exception ex)
{
  // …
}

Заметьте, что это применимо к любому методу доступа к файловой системе: открытие/удаление файла или каталога, перечисление содержимого каталога и т.п.

Итого
File.Exists/Directory.Exists следует использовать только в том случае, если вы хотите знать, существует ли файл/каталог на момент проверки. Например, чтобы избежать каких-либо действий, если файл уже существует. Когда метод возвращается, информация становится устаревшей. Действительно, файл мог быть создан/удалён сразу же другим приложением. Метод File.Exists бесполезен, если вы хотите читать/записывать в этот файл. В этом случае просто выполните необходимую операцию и обработайте исключения. Даже если файл существует, вы можете получить исключения по многим другим причинам.

Источник: https://www.meziantou.net/is-file-exist-path-useless.htm

День 1057. #Книги
Наконец осилил 600-страничную книгу «Внедрение зависимостей на платформе .NET» (Симан, ван Дерсен, 2-е издание. — СПб.: Питер, 2021).

Что? 600 страниц про внедрение зависимостей? Да! Более того, я смело ставлю её в ряд «мастрид» не только для .NET, но и для всех ООП разработчиков. Туда вот, рядом с Рихтером и «Совершенным кодом».

Вы купили одну книгу, а получили три: потрясающее введение в DI на .NET, отличный курс по основам ООП и уникальную книгу по дизайну ПО.
— Миккель Арентефт, Danske Bank

От многих опытных программистов можно услышать, что главная буква в SOLID – буква D. И эта книга в подробностях описывает, почему. Эта книга - в первую очередь отличное руководство по написанию лучшего программного обеспечения. Это достигается за счёт сосредоточения внимания на важности управления зависимостями, и поэтому она охватывает различные подходы к этому, в первую очередь DI.

Все мы знаем, что хорошо, когда код слабо связан, что объекты верхнего уровня не должны зависеть от объектов более низких уровней, а должны зависеть от абстракций, вот это всё. Однако 99% нашего опыта по внедрению зависимостей заключается в выделении интерфейса, внедрении его – в лучшем случае через конструктор - и регистрации зависимости в контейнере DI. Так вот, до контейнеров в книге дело доходит только в последней четверти книги.

В первых трёх четвертях на реальных практических примерах разбирается предназначение всех принципов SOLID и множества паттернов проектирования (декоратор, предохранитель, адаптер, компоновщик и т.д.). Их теоретические определения тоже приводятся (после подробного обоснования, зачем оно тут вообще надо), так что не переживайте. Также рассматриваются популярные антипаттерны, такие как «Диктатор», «Локатор сервисов», «Окружающий контекст» и «Ограниченная конструкция». Описываются проблемные подходы («запахи кода»), вроде избыточного внедрения через конструктор, зацикленных зависимостей и внедрения абстрактных фабрик. А, главное, почему они проблемные. Вводится понятие корня композиции (места, где собирается граф объектов, выполняющих всю работу в приложении, и где должны разрешаться все зависимости). Объясняется, в чём различия во времени жизни зависимостей. И многое, многое, многое другое.

И только после этого дело доходит до контейнеров DI, начиная с написания собственного примитивного контейнера, а потом рассказа о трёх популярных контейнерах: Autofac, Simple Injector и встроенном в .NET Core Microsoft.Extensions.DependencyInjection.

В общем, как написал выше, книга обязательна к прочтению всем.

Эта книга – настоящий шедевр. Удивительная и фундаментальная, она нужна каждому разработчику ПО, который хочет написать надёжный и правильный код.
— Эмануэле Ориджи, Funambol

Одно замечание. В книге очень много примеров про еду, поэтому не рекомендую читать её на пустой желудок.

Ну а поскольку в конце описывались DI контейнеры, и авторы горячо хейтили встроенный MS.DI, парочка опросов для вас ниже.

День 1058. #ЗаметкиНаПолях #ExploringNET6
Исследуем .NET 6. Часть 4
В этой серии статей рассмотрим подробно некоторые из новых функций, которые появились в .NET 6.
Часть 1
Часть 2
Часть 3

Рассматриваем код WebApplication
Сегодня мы немного рассмотрим код, лежащий в основе WebApplication, и сосредоточимся на настройке промежуточного ПО и конечных точек.

В предыдущем посте мы остановились на том, на WebApplicationBuilder вызывался метод Build(), который создавал WebApplication, передавая в его конструктор построенный хост:

_builtApplication = new WebApplication(_hostBuilder.Build());
…
return _builtApplication;

Класс WebApplication

public sealed class WebApplication : IHost, IApplicationBuilder, IEndpointRouteBuilder, IAsyncDisposable
{
}

По сравнению с конструктором WebApplicationBuilder, конструктор WebApplication относительно прост. Конструктор и инициализаторы полей выполняют 4 основные задачи:
1. Сохранить предоставленный хост в поле _host. Это тот же тип хоста, что и при прямом использовании универсального хоста, как в ASP.NET Core 3.x/5.
2. Создать новый список EndpointDataSource. Источники конечных точек используются для настройки конечных точек в приложении, включая Razor Pages, контроллеры, конечные точки API и новые «минимальные» API.
3. Создать новый экземпляр ApplicationBuilder. Он используется для создания конвейера промежуточного ПО.
4. Установить свойство __GlobalEndpointRouteBuilder в ApplicationBuilder. Это свойство используется для «сообщения» другому промежуточному ПО, что мы используем новый WebApplication, у которого немного другие значения по умолчанию.

WebApplication в основном делегирует реализацию IHost, IApplicationBuilder и IEndpointRouteBuilder своим приватным свойствам и реализует эти интерфейсы явно.

Конвейер промежуточного ПО в WebApplication
Одно из серьёзных отличий WebApplication от универсального хоста заключается в том, что WebApplication по умолчанию устанавливает различное промежуточное ПО.

Рассмотрим простой пример приложения:

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
WebApplication app = builder.Build();

app.UseHttpsRedirection();
app.UseStaticFiles();

app.MapGet("/", () => "Hello World!");
app.Run();

Здесь создаётся следующее промежуточное ПО (см. рисунок ниже):
1. HostFilteringMiddleware – добавляется благодаря скрытому вызову ConfigureWebHostDefaults(), как и в универсальном хосте в предыдущих версиях.
2. ForwardedHeadersMiddleware – добавляется там же, если для переменной среды ASPNETCORE_FORWARDEDHEADERS_ENABLED задано значение true (не в нашем случае).
3. DeveloperExceptionPageMiddleware – теперь добавляется автоматически, когда вы работаете в среде разработки (Development):
app.UseDeveloperExceptionPage().
4. EndpointRoutingMiddleware (также известное как RoutingMiddleware) – теперь автоматически добавляется в конвейер промежуточного ПО до начала конвейера в Program.cs, а EndpointMiddleware автоматически добавляется в конвейер в конце.
5. Конвейер WebApplication.ApplicationBuilder, содержащий всё промежуточное ПО, определённое в Program.cs:
- HttpsRedirectionMiddleware
- StaticFilesMiddleware
6. EndpointMiddleware – теперь автоматически добавляется в конвейер в конце.

Добавление конечной точки с помощью MapGet() добавляет запись в коллекцию EndpointDataSource объекта WebApplication, что приводит к автоматическому добавлению промежуточного ПО конечных точек:
- EndpointRoutingMiddleware выбирает конечную точку,
- EndpointMiddleware исполняет конечную точку.
EndpointMiddleware обычно добавляется в конвейер в конце путем вызова UseEndpoints(), но здесь оно добавляется автоматически.

Подробнее перевод статьи с примерами кода размещён на Хабре.

Источник: https://andrewlock.net/exploring-dotnet-6-part-4-building-a-middleware-pipeline-with-webapplication/

День 1059. #Карьера
Станьте Сверхпродуктивным Разработчиком за Неделю
Впереди последняя неделя года. Самое время поработать в ударном темпе. Чем вы продуктивнее, тем лучше для всех, кто участвует в вашем проекте. Мы рассмотрим некоторые советы, которые помогут вам добиться успеха.

1. Определите свой самый слабый навык и сосредоточьтесь на его улучшении
Бороться со всеми слабостями сразу - не лучший способ. Вместо этого лучше сосредоточиться на одном навыке, прежде чем переходить к другому. Убедитесь, что это навык, который может существенно повлиять на вашу производительность.
- Выясните задачи, которые отнимают у вас много времени, и что вы обычно гуглите, прежде чем выполнить.
- Выпишите все технологии, которые кажутся вам трудными, и начните выделять небольшие промежутки времени для решения небольших задач.
- Начните с простых задач, чтобы лучше понять концепции, и продолжайте повышать уровень каждый день.
Так вы обретёте уверенность и сможете выполнять повседневные задачи намного быстрее.

2. Составьте список дел на неделю с конкретными задачами и целями
Лучше, если он будет доступен на какой-либо общедоступной платформе, например Trello или Evernote. Затем разбейте каждую задачу на подзадачи, над которыми вы сможете работать. Главное, чтобы список был кратким, чтобы ни одна из задач не казалась слишком сложной или пугающей.
Вычёркивайте задачи из списка, как только они выполнены. Это поможет набрать обороты и уверенность, облегчая выполнение большего количества задач за меньшее время.

3. Научитесь управлять временем
Расставьте задачи в порядке важности и работайте над ними по очереди. Если вы работаете над чем-то, что не является приоритетом, завершите дело быстро, чтобы вернуться к тому, что имеет значение. Постарайтесь установить конкретные цели на день или неделю, чтобы сохранять мотивацию и сосредоточенность.
- Выделяйте время на задачи в зависимости от их влияния на проект, команду и ваш прогресс. Это поможет быстрее завершить работу с высоким приоритетом.
- Периодически изменяйте тактику тайм-менеджмента. Экспериментирование со своим расписанием и стилем работы может улучшить ваши навыки управления временем. Почитайте статьи или пройдите курс по тайм-менеджменту.

4. Ставьте ежедневные цели
Если вы установите ежедневные цели, большая задача будет казаться более реалистичной и достижимой. Например, если задача – реализация новой функциональности в проекте, ежедневные цели вроде «закончить прототип» или «завершить черновик документации для текущего выпуска», помогут работать над большой задачей, не ощущая подавленности от её объёма.
- Планируйте свои ежедневные цели на следующий день. Это избавит от лишних хлопот по утрам, и вы сможете сразу приступить к работе.
- Регулярно делайте перерывы. Это поможет оставаться спокойным и свободным от стресса.
- Проверьте, какие задачи вы можете делегировать, и сконцентрируйтесь на важной работе, которая может принести максимальные результаты.

5. Сделайте работу интересной
- Сохраняйте мотивацию и энтузиазм, визуализируя успех и слушая веселую музыку во время работы.
- Попробуйте объединиться с коллегой, чтобы мотивировать друг друга.
- Поговорите с коллегами на интересные темы. Это снимает стресс и помогает работать с большим удовольствием и концентрацией.
- Отмечайте все маленькие победы вместе со своей командой. Это помогает сохранять оптимизм и сосредоточиться на работе.

6. Не забывайте отдыхать и восстанавливаться
Выделите время перерывов в течение дня, чтобы восстановиться перед тем, как вернуться к работе. Сходите на небольшую прогулку, поговорите с коллегой и выпейте кофе, чтобы быстрее зарядиться энергией. Если вы любите читать, прочтите пару страниц любимой книги. Отдых и восстановление энергии имеют решающее значение для повышения производительности, поэтому делайте регулярные перерывы для творческой или физической работы.

Итого
Разработка ПО может быть интересной и продуктивной; вы должны работать над этим. И помните, что всегда есть возможности для совершенствования, если вы хотите развивать свои навыки и знания.

Источник

День 1061.
Одно из Тех Самых Однострочных Исправлений
В команде Roslyn я научился писать длинные описательные комментарии для сложных мест. Я абсолютно уверен, что подобные комментарии - ценная практика и инклюзивная практика для тех, кто плохо знаком с кодовой базой.

Также полезно иметь комментарии непосредственно в коде, а не во внешнем бегтрекере, PR, документации и т.д. Это дополнительное действие. Внешние ссылки не работают, кодовые базы перемещаются, история переписывается или удаляется.

Конечно, у вас также может быть обоснование и обсуждение в PR, и хорошие сообщения коммитов тоже полезны, но они также разрушаются после переименования файлов, изменения пробелов и т.д. Внешние документы тоже хороши, но читатель может не перейти туда в поиске конкретной вещи.

Если я потратил часы своего драгоценного времени на то, чтобы получить эти знания, мне лучше поместить их в код вместе с сообщением коммита, чтобы их было нелегко потерять.
- Kirill Osenkov

А как вы относитесь к комментариям?

Источник

День 1062. #ЗаметкиНаПолях
Параметризованные Тесты в MSTest v2
Зачастую нам нужно использовать несколько разных тестовых данных, чтобы полностью протестировать метод. Один из способов - скопировать и вставить метод и изменить значение параметров.

[TestClass]
public class MathTests
{
  [TestMethod]
  public void Test_Add1()
  {
    Assert.AreEqual(2, Add(1, 1));
  }

  [TestMethod]
  public void Test_Add2()
  {
    Assert.AreEqual(25, Add(21, 4));
  }
}

В NUnit или xUnit проблема решается добавлением атрибутов TestCase и InlineData соответственно. Однако, я лишь недавно для себя открыл, что это можно сделать и в стандартном MSTest.

DataRow
Атрибут [DataRow] позволяет задать значения параметра теста. Также необходимо заменить [TestMethod] на [DataTestMethod]:

[DataTestMethod]
[DataRow(1, 1, 2)]
[DataRow(12, 30, 42)]
public void Test_Add(int a, int b, int expected)
{
  Assert.AreEqual(expected, Add(a, b));
}

В обозревателе тестов вы увидите 2 выполненных теста. Также доступно ключевое слово params:

[DataTestMethod]
[DataRow(1, new[] { "a", "b" })]
[DataRow(1, "a", "b")]
public void Test_Add(int a, params string[] b) {…}

DynamicData
Если данные не могут быть установлены в параметре атрибута (непостоянные значения или сложные объекты), можно использовать атрибут [DynamicData], позволяющий получать значения параметров из метода (DynamicDataSourceType.Method) или свойства (DynamicDataSourceType.Property), возвращающих IEnumerable<object[]>:

[DataTestMethod]
[DynamicData(nameof(GetData), DynamicDataSourceType.Method)]
public void Test_Add_Method(int a, int b, int expected)
{
  Assert.AreEqual(expected, Add(a, b));
}

public static IEnumerable<object[]> GetData()
{
  yield return new object[] { 1, 1, 2 };
  yield return new object[] { 12, 30, 42 };
}

Свой источник данных
Вы можете создать свой атрибут, реализовав ITestDataSource. Интерфейс имеет 2 метода:
- GetData возвращает массивы данных,
- GetDisplayName возвращает имя теста, которое отображается в обозревателе тестов или в консоли.

public class CustomDataSourceAttribute : 
 Attribute, ITestDataSource
{
  public IEnumerable<object[]> GetData(MethodInfo info)
  {
    yield return new object[] { 1, 1, 2 };
    yield return new object[] { 12, 30, 42 };
  }
  public string GetDisplayName(MethodInfo info, object[] data)
  {
    if (data is null)
      return null;

    return $"Test {info.Name}({string.Join(",", data)})";
  }
}

Затем его можно использовать как атрибут теста:

[DataTestMethod]
[CustomDataSource]
public void Test_Add(int a, int b, int expected)
{
  Assert.AreEqual(expected, Add(a, b));
}

Источник: https://www.meziantou.net/mstest-v2-data-tests.htm

День 1063. #ЗаметкиНаПолях #ExploringNET6
Исследуем .NET 6. Часть 5
В этой серии статей рассмотрим подробно некоторые из новых функций, которые появились в .NET 6.
Часть 1
Часть 2
Часть 3
Часть 4

Поддержка EF Core в WebApplicationBuilder
EF Core включает в себя различные инструменты для создания миграций и запуска их в вашей базе данных, но для этого ему необходимо понимать ваш код. По сути, он должен иметь возможность исполнять код запуска вашего приложения, чтобы использовать все настроенные вами сервисы конфигурации и внедрения зависимостей.

В предыдущих версиях ASP.NET Core EF Core подключался к методу CreateWebHostBuilder или CreateHostBuilder в вашем классе Program. Инструменты EF Core искали этот «волшебный» метод для получения доступа к IWebHostBuilder или IHostBuilder, используемый для создания вашего приложения. Так инструменты EF Core могли загрузить сборку вашего приложения с помощью рефлексии, выполнить этот метод, получить возвращённый IHostBuilder, вызвать на нём Build() для создания IHost, а затем получить IServiceProvider из свойства IHost.Services, и, уже используя этот провайдер, проанализировать практически всё, что связано с вашим приложением.

Поддержка инструментов EF Core в .NET 6
Чтобы обойти изменения, внесённые в .NET 6, в HostBuilder были добавлены новые события DiagnosticSource. Они позволяют подписчикам получить доступ к HostBuilder непосредственно перед его построением, а также доступ к экземпляру IHost сразу после его создания:
1. На время действия метода HostBuilder.Build() создаётся новый DiagnosticListener.
2. Если что-либо прослушивает событие Microsoft.Extensions.Hosting.HostBuilding (хост строится), HostBuilder передает себя (this) слушателю в качестве параметра метода diagnosticListener.Write().
3. После создания хоста и перед возвратом из метода HostBuilder проверяет, прослушивает ли что-нибудь событие Microsoft.Extensions.Hosting.HostBuilt (хост построен). Если это так, вновь созданный хост передаётся слушателю в качестве параметра того же метода diagnosticListener.Write().

Вот как инструменты EF Core используют эти события (см. схему ниже):
1. Загружается сборка вашего приложения.
2. Создаётся экземпляр вспомогательного класса HostFactoryResolver, который ищет и исполняет точку входа в приложение (например, Program.Main).
3. Точка входа запускается в фоновом потоке. Это запускает ваше приложение. И предполагается, что в какой-то момент ваше приложение вызовет HostBuilder.Build().
4. Идёт ожидание одного из трёх событий:
- Код слушателя выдаёт исключение StopTheHostException после завершения всей настройки (об этом ниже).
- В запущенном приложении возникает иное исключение.
- Запуск приложения занимает слишком много времени, поэтому прерывается по таймауту.
5. Результат (в виде построенного хоста или в виде сгенерированного исключения) передаётся инструментам EF Core.

Пара слов о StopTheHostException. Запущенное в фоновом потоке приложение после постройки хоста может продолжать работу, и, например, начать прослушивать порты. Чтобы этого не происходило, слушатель событий, находящийся в том же потоке, после получения события HostBuilt (хост построен), выбрасывает исключение StopTheHostException, которое не обрабатывается, вызывая завершение приложения.

Подробный перевод статьи с примерами кода размещён на Хабре.

Источник: https://andrewlock.net/exploring-dotnet-6-part-5-supporting-ef-core-tools-with-webapplicationbuilder/

День 1064. #Карьера
Чему Можно Научиться из Книг «Программист-прагматик» и «Идеальный программист». Часть 5
Часть 1
Часть 2
Часть 3
Часть 4

7. Важность рефакторинга
Вот определение рефакторинга, которое дал Мартин Фаулер:
Дисциплинированный метод реструктуризации существующей части кода, изменения его внутренней структуры без изменения его внешнего поведения.

Иногда вы найдёте код, который кажется неправильным, и его следует исправить или улучшить. И вы должны помнить, что лучший момент для этого - сейчас, когда вы его нашли. Это неизбежно: код программы должен расти, развиваться и улучшаться. Для этого вам нужно будет переосмыслить некоторые решения и изменить код. Поэтому убедитесь, что он покрыт тестами, чтобы гарантировать, что внешнее поведение не изменится.

В отличие от строительства, написание программ ближе к садоводству, оно ближе к живой природе, чем к бетонным конструкциям. Вы постоянно следите за состоянием сада и при необходимости вносите изменения.
— Программист-прагматик

Вот список подходящих ситуаций для рефакторинга:
- Убрать дублирование кода.
- Сделать некоторые части кода более ортогональными (независимыми друг от друга).
- Обновить устаревший код и/или документацию.
- Повысить производительность.

Вот советы Мартина Фаулера, как провести рефакторинг, не принеся больше вреда, чем пользы:
1. Не пытайтесь провести рефакторинг и добавить функциональность одновременно.
2. Прежде чем приступить к рефакторингу, убедитесь, что у вас есть хорошие тесты. Выполняйте тесты как можно чаще.
3. Делайте короткие, продуманные шаги: переместите поле из одного класса в другой, разделите метод, переименуйте переменную. Частый рефакторинг включает в себя внесение множества локализованных изменений, которые приводят к более масштабным изменениям.

Главное помнить, что рефакторинг - не конкретная задача, а привычка. И, как и в большинстве случаев в жизни, это легче делать, пока проблемы небольшие, как постоянное действие при написании кода. Чем меньше вы проводите рефакторинга сейчас, тем больше времени у вас займёт исправление проблемы в будущем.

Рассматривайте программу, нуждающуюся в рефакторинге, как "опухоль". Чтобы удалить её, требуется хирургическое вмешательство. Вы можете сделать это сразу и удалить её, пока она небольшая. Но если вы будете ждать, пока она вырастет и распространится, то удаление её станет более дорогой и опасной процедурой. Прождёте ещё, и вы можете потерять пациента окончательно.
— Программист-прагматик

8. Основные различия между книгами
Хотя эти книги посвящены схожим предметам, содержание и способ повествования в них не совпадают.
- В книге «Идеальный программист» больше говорится о ежедневной жизни разработчика. Уделяется внимание типичным ситуациям, которые возникают в работе, таким как отношения с отделом продаж или бизнесом, работа в команде или отказы клиентам. Разработчик в книге «Программист-прагматик» рассматривается не как работник. Скорее, даётся обзор области и предлагаются советы для любой ситуации.
- «Идеальный программист» рассматривает разработчика ПО как к профессионального программиста, в то время как «Программист-прагматик» вводит этот совершенно неожиданный термин.
- «Идеальный программист» носит более субъективный характер, поскольку в ней больше личного опыта автора. «Программист-прагматик» кажется более объективной, сосредотачиваясь в основном на советах.
- «Программист-прагматик» содержит больше примеров кода на разных языках программирования, чем «Идеальный программист», что помогает вам понять обсуждаемые концепции.

Источник: https://www.freecodecamp.org/news/lessons-learned-from-the-pragmatic-programmer-and-the-clean-coder/

День 1065. #ЗаметкиНаПолях #AsyncTips
Параллельная обработка данных
Задача: Имеется коллекция данных. Требуется выполнить одну и ту же операцию с каждым элементом. Эта операция является ограниченной по вычислениям и может занять некоторое время.

Решение
Тип Parallel содержит метод ForEach, разработанный специально для этой задачи. Следующий пример получает коллекцию матриц и поворачивает эти матрицы:

void Rotate(IEnumerable<Matrix> matrices, float degrees)
{
  Parallel.ForEach(matrices, m => m.Rotate(degrees));
}

Возможны ситуации, в которых преждевременно требуется прервать цикл (например, при обнаружении недействительного значения). Следующий пример обращает каждую матрицу, но при обнаружении недействительной матрицы цикл прерывается:

void Invert(IEnumerable<Matrix> matrices)
{
  Parallel.ForEach(matrices, (m, state) =>
  {
    if (!m.IsInvertible)
      state.Stop();
    else
      m.Invert();
  });
}

Этот код использует ParallelLoopState.Stop для остановки цикла и предотвращения любых дальнейших вызовов тела цикла. Учтите, что цикл является параллельным, поэтому могут уже выполниться другие вызовы тела цикла, включая вызовы для элементов, следующих после текущего. В приведённом примере кода если третья матрица не является обратимой, то цикл прерывается и новые матрицы обрабатываться не будут, но может оказаться, что уже обрабатываются другие матрицы (например, четвертая и пятая).

Более распространённая ситуация встречается тогда, когда требуется отменить параллельный цикл. Это не то же, что остановка: цикл останавливается изнутри и отменяется за своими пределами. Например, кнопка отмены может отменить CancellationTokenSource, отменяя параллельный цикл, как в следующем примере:

void Rotate (IEnumerable<Matrix> matrices, 
 float degrees, CancellationToken t)
{
  Parallel.ForEach(matrices,
    new ParallelOptions { CancellationToken = t },
    m => m.Rotate(degrees));
}

Следует иметь в виду, что каждая параллельная задача может выполняться в отдельном потоке, поэтому любое совместное состояние должно быть защищено. Следующий пример обращает каждую матрицу и подсчитывает количество матриц, которые обратить не удалось:

// Примечание: это не самая эффективная реализация.
// Это лишь пример использования блокировки
// для защиты совместного состояния.
int Invert(IEnumerable<Matrix> matrices)
{
  object mutex = new object();
  int nonInvertible = 0;
  Parallel.ForEach(matrices, m => {
    if (matrix.IsInvertible)
      m.Invert();
    else
    {
      lock (mutex)
      {
        ++nonInvertible;
      }
    }
  });
  return nonInvertible;
}

Метод Parallel.ForEach предоставляет возможность параллельной обработки последовательности значений. Аналогичное решение Parallel LINQ (PLINQ) предоставляет практически те же возможности в LINQ-подобном синтаксисе. Одно из различий между Parallel и PLINQ заключается в том, что PLINQ предполагает, что может использовать все ядра на компьютере, тогда как Parallel может динамически реагировать на изменения условий процессора.

Parallel.ForEach реализует параллельный цикл foreach. Если вам потребуется выполнить параллельный цикл for, то класс Parallel также поддерживает метод Parallel.For. Метод Parallel.For особенно полезен при работе с несколькими массивами данных, которые получают один индекс.

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 4.

День 1066.
Оглядываясь Назад на C#. Начало

С наступающим!

Говорят, что праздники должны быть временем, когда человек оглядывается на прошедший год и размышляет над решениями и событиями, произошедшими в его жизни. Предполагается, что он обдумывает свои успехи и неудачи в надежде пролить свет на взлёты и падения прошлого, чтобы либо повторить, либо избежать таких событий.

Одна из самых удивительных особенностей C# - это упорный труд, который разработчики вложили в его изменение и адаптацию к текущим трендам и требованиям сообщества. В новом году мы отметим 20-летний юбилей релиза C#, а работать над ним в Microsoft начали задолго до этого. Многие языки возникали и пропадали за время существования C#, а некоторые даже объявлялись новой вехой в программировании, но потерпели неудачу и оставались лишь заметками в анналах истории. C#, даже несмотря на то, что поддерживался одной из крупнейших компаний-разработчиков ПО в мире, никогда не имел гарантии успеха, и временами казалось, что он станет ещё одним мимолётным увлечением.

90-е были действительно другой эпохой программирования, как технологически, так и культурно. Интернет только начинал развиваться. Колёсико мыши было практически неслыханным делом, а трекболы были еще одним предметом, который нужно чистить и обслуживать. Microsoft были в разгаре судебной тяжбы с Sun по поводу торговых марок Java и J++. Delphi, основанный на Turbo Pascal, был лидером в области быстрой разработки приложений (RAD). Необычный язык программирования JavaScript, который добавлял интерактивность в веб-браузеры, был новинкой. Программистам на COBOL и другим людям, работавшим над ошибкой 2000 года, наряду с HTML-разработчиками, платили как рок-звёздам, а Microsoft спасала Apple от финансового краха.

В середине 2000 года Microsoft объявила о скором выпуске нового языка программирования под названием C#, ничем не напоминающего Visual Basic, их флагманский инструмент RAD, который, возможно, был самым любимым (и самым осуждаемым) языком в то время. Синтаксис VB во всех его формах использовался для большинства инструментов программирования Microsoft. Всё, от VBScript в классическом ASP до автоматизации офиса и инструмента RAD Tool. Хотя это официально не было заявлено, выпуском C# Microsoft недвусмысленно намекнули об изменении своего подхода к разработке ПО и что они не против оставить в прошлом синтаксис BEGIN/END и ON ERROR GOTO, к большому огорчению многих разработчиков.

Да, строго говоря, Microsoft официально не отказывались от Visual Basic. Они создали VB.NET с некоторыми изменениями синтаксиса и согласились «развивать» его параллельно с C#. Хотя в то время официально об этом не говорили, но на его рекламу и продвижение было потрачено гораздо меньше времени и усилий. И многие разработчики считали, что Microsoft твердо намерены перевести разработчиков на C#.

Заглянув в историю 90-х, теперь можно посмотреть на мир, в котором дебютировал C# 1.0. Он вошёл в мир, где продолжались споры о том, действительно ли нужны ещё какие-либо коммерческие языки программирования, и, кроме того, он выглядел чрезвычайно похожим на язык программирования конкурирующей компании… Java. Настолько похож, что даже некоторые недостатки Java были сознательно продублированы, например ковариантность массивов.

В Microsoft решили эту проблему с помощью обобщений. Хотя, в первоначальном выпуске было явно запрещено делать что-то вроде следующего:

public void AddEmployee(List<Employee> employees){}
...
public void AddManager () {
  List<Manager> managers = new List<Manager>();

  // Изначально это было запрещено, даже при том, 
  // что Manager – подтип Employee.
  AddEmployee(managers);
}

В некоторых случаях преобразование типов для обобщений, делегатов и т.п. было упрощено в зависимости от того, как использовался тип. Затем Microsoft обновили значительную часть платформы .NET, чтобы без проблем разрешить эти упрощённые правила неявного преобразования.

Продолжение следует…

Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html

Моя первая книга по C# от 2003 года.