День 1058. #ЗаметкиНаПолях #ExploringNET6
Исследуем .NET 6. Часть 4
В этой серии статей рассмотрим подробно некоторые из новых функций, которые появились в .NET 6.
Часть 1
Часть 2
Часть 3
Рассматриваем код WebApplication
Сегодня мы немного рассмотрим код, лежащий в основе
В предыдущем посте мы остановились на том, на
1. Сохранить предоставленный хост в поле
2. Создать новый список
3. Создать новый экземпляр
4. Установить свойство
Конвейер промежуточного ПО в WebApplication
Одно из серьёзных отличий
Рассмотрим простой пример приложения:
1.
2.
3.
4.
5. Конвейер
-
Добавление конечной точки с помощью
-
-
Подробнее перевод статьи с примерами кода размещён на Хабре.
Источник: https://andrewlock.net/exploring-dotnet-6-part-4-building-a-middleware-pipeline-with-webapplication/
Исследуем .NET 6. Часть 4
В этой серии статей рассмотрим подробно некоторые из новых функций, которые появились в .NET 6.
Часть 1
Часть 2
Часть 3
Рассматриваем код WebApplication
Сегодня мы немного рассмотрим код, лежащий в основе
WebApplication
, и сосредоточимся на настройке промежуточного ПО и конечных точек.В предыдущем посте мы остановились на том, на
WebApplicationBuilder
вызывался метод Build()
, который создавал WebApplication
, передавая в его конструктор построенный хост:_builtApplication = new WebApplication(_hostBuilder.Build());Класс WebApplication
…
return _builtApplication;
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. Не забывайте отдыхать и восстанавливаться
Выделите время перерывов в течение дня, чтобы восстановиться перед тем, как вернуться к работе. Сходите на небольшую прогулку, поговорите с коллегой и выпейте кофе, чтобы быстрее зарядиться энергией. Если вы любите читать, прочтите пару страниц любимой книги. Отдых и восстановление энергии имеют решающее значение для повышения производительности, поэтому делайте регулярные перерывы для творческой или физической работы.
Итого
Разработка ПО может быть интересной и продуктивной; вы должны работать над этим. И помните, что всегда есть возможности для совершенствования, если вы хотите развивать свои навыки и знания.
Источник
Станьте Сверхпродуктивным Разработчиком за Неделю
Впереди последняя неделя года. Самое время поработать в ударном темпе. Чем вы продуктивнее, тем лучше для всех, кто участвует в вашем проекте. Мы рассмотрим некоторые советы, которые помогут вам добиться успеха.
1. Определите свой самый слабый навык и сосредоточьтесь на его улучшении
Бороться со всеми слабостями сразу - не лучший способ. Вместо этого лучше сосредоточиться на одном навыке, прежде чем переходить к другому. Убедитесь, что это навык, который может существенно повлиять на вашу производительность.
- Выясните задачи, которые отнимают у вас много времени, и что вы обычно гуглите, прежде чем выполнить.
- Выпишите все технологии, которые кажутся вам трудными, и начните выделять небольшие промежутки времени для решения небольших задач.
- Начните с простых задач, чтобы лучше понять концепции, и продолжайте повышать уровень каждый день.
Так вы обретёте уверенность и сможете выполнять повседневные задачи намного быстрее.
2. Составьте список дел на неделю с конкретными задачами и целями
Лучше, если он будет доступен на какой-либо общедоступной платформе, например Trello или Evernote. Затем разбейте каждую задачу на подзадачи, над которыми вы сможете работать. Главное, чтобы список был кратким, чтобы ни одна из задач не казалась слишком сложной или пугающей.
Вычёркивайте задачи из списка, как только они выполнены. Это поможет набрать обороты и уверенность, облегчая выполнение большего количества задач за меньшее время.
3. Научитесь управлять временем
Расставьте задачи в порядке важности и работайте над ними по очереди. Если вы работаете над чем-то, что не является приоритетом, завершите дело быстро, чтобы вернуться к тому, что имеет значение. Постарайтесь установить конкретные цели на день или неделю, чтобы сохранять мотивацию и сосредоточенность.
- Выделяйте время на задачи в зависимости от их влияния на проект, команду и ваш прогресс. Это поможет быстрее завершить работу с высоким приоритетом.
- Периодически изменяйте тактику тайм-менеджмента. Экспериментирование со своим расписанием и стилем работы может улучшить ваши навыки управления временем. Почитайте статьи или пройдите курс по тайм-менеджменту.
4. Ставьте ежедневные цели
Если вы установите ежедневные цели, большая задача будет казаться более реалистичной и достижимой. Например, если задача – реализация новой функциональности в проекте, ежедневные цели вроде «закончить прототип» или «завершить черновик документации для текущего выпуска», помогут работать над большой задачей, не ощущая подавленности от её объёма.
- Планируйте свои ежедневные цели на следующий день. Это избавит от лишних хлопот по утрам, и вы сможете сразу приступить к работе.
- Регулярно делайте перерывы. Это поможет оставаться спокойным и свободным от стресса.
- Проверьте, какие задачи вы можете делегировать, и сконцентрируйтесь на важной работе, которая может принести максимальные результаты.
5. Сделайте работу интересной
- Сохраняйте мотивацию и энтузиазм, визуализируя успех и слушая веселую музыку во время работы.
- Попробуйте объединиться с коллегой, чтобы мотивировать друг друга.
- Поговорите с коллегами на интересные темы. Это снимает стресс и помогает работать с большим удовольствием и концентрацией.
- Отмечайте все маленькие победы вместе со своей командой. Это помогает сохранять оптимизм и сосредоточиться на работе.
6. Не забывайте отдыхать и восстанавливаться
Выделите время перерывов в течение дня, чтобы восстановиться перед тем, как вернуться к работе. Сходите на небольшую прогулку, поговорите с коллегой и выпейте кофе, чтобы быстрее зарядиться энергией. Если вы любите читать, прочтите пару страниц любимой книги. Отдых и восстановление энергии имеют решающее значение для повышения производительности, поэтому делайте регулярные перерывы для творческой или физической работы.
Итого
Разработка ПО может быть интересной и продуктивной; вы должны работать над этим. И помните, что всегда есть возможности для совершенствования, если вы хотите развивать свои навыки и знания.
Источник
👍3
День 1061.
Одно из Тех Самых Однострочных Исправлений
В команде Roslyn я научился писать длинные описательные комментарии для сложных мест. Я абсолютно уверен, что подобные комментарии - ценная практика и инклюзивная практика для тех, кто плохо знаком с кодовой базой.
Также полезно иметь комментарии непосредственно в коде, а не во внешнем бегтрекере, PR, документации и т.д. Это дополнительное действие. Внешние ссылки не работают, кодовые базы перемещаются, история переписывается или удаляется.
Конечно, у вас также может быть обоснование и обсуждение в PR, и хорошие сообщения коммитов тоже полезны, но они также разрушаются после переименования файлов, изменения пробелов и т.д. Внешние документы тоже хороши, но читатель может не перейти туда в поиске конкретной вещи.
Если я потратил часы своего драгоценного времени на то, чтобы получить эти знания, мне лучше поместить их в код вместе с сообщением коммита, чтобы их было нелегко потерять.
- Kirill Osenkov
А как вы относитесь к комментариям?
Источник
Одно из Тех Самых Однострочных Исправлений
В команде Roslyn я научился писать длинные описательные комментарии для сложных мест. Я абсолютно уверен, что подобные комментарии - ценная практика и инклюзивная практика для тех, кто плохо знаком с кодовой базой.
Также полезно иметь комментарии непосредственно в коде, а не во внешнем бегтрекере, PR, документации и т.д. Это дополнительное действие. Внешние ссылки не работают, кодовые базы перемещаются, история переписывается или удаляется.
Конечно, у вас также может быть обоснование и обсуждение в PR, и хорошие сообщения коммитов тоже полезны, но они также разрушаются после переименования файлов, изменения пробелов и т.д. Внешние документы тоже хороши, но читатель может не перейти туда в поиске конкретной вещи.
Если я потратил часы своего драгоценного времени на то, чтобы получить эти знания, мне лучше поместить их в код вместе с сообщением коммита, чтобы их было нелегко потерять.
- Kirill Osenkov
А как вы относитесь к комментариям?
Источник
День 1062. #ЗаметкиНаПолях
Параметризованные Тесты в MSTest v2
Зачастую нам нужно использовать несколько разных тестовых данных, чтобы полностью протестировать метод. Один из способов - скопировать и вставить метод и изменить значение параметров.
DataRow
Атрибут
Если данные не могут быть установлены в параметре атрибута (непостоянные значения или сложные объекты), можно использовать атрибут
Вы можете создать свой атрибут, реализовав ITestDataSource. Интерфейс имеет 2 метода:
-
-
Параметризованные Тесты в MSTest v2
Зачастую нам нужно использовать несколько разных тестовых данных, чтобы полностью протестировать метод. Один из способов - скопировать и вставить метод и изменить значение параметров.
[TestClass]В NUnit или xUnit проблема решается добавлением атрибутов
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));
}
}
TestCase
и InlineData
соответственно. Однако, я лишь недавно для себя открыл, что это можно сделать и в стандартном MSTest.DataRow
Атрибут
[DataRow]
позволяет задать значения параметра теста. Также необходимо заменить [TestMethod]
на [DataTestMethod]
:[DataTestMethod]В обозревателе тестов вы увидите 2 выполненных теста. Также доступно ключевое слово params:
[DataRow(1, 1, 2)]
[DataRow(12, 30, 42)]
public void Test_Add(int a, int b, int expected)
{
Assert.AreEqual(expected, Add(a, b));
}
[DataTestMethod]DynamicData
[DataRow(1, new[] { "a", "b" })]
[DataRow(1, "a", "b")]
public void Test_Add(int a, params string[] b) {…}
Если данные не могут быть установлены в параметре атрибута (непостоянные значения или сложные объекты), можно использовать атрибут
[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]Источник: https://www.meziantou.net/mstest-v2-data-tests.htm
[CustomDataSource]
public void Test_Add(int a, int b, int expected)
{
Assert.AreEqual(expected, Add(a, b));
}
День 1063. #ЗаметкиНаПолях #ExploringNET6
Исследуем .NET 6. Часть 5
В этой серии статей рассмотрим подробно некоторые из новых функций, которые появились в .NET 6.
Часть 1
Часть 2
Часть 3
Часть 4
Поддержка EF Core в WebApplicationBuilder
EF Core включает в себя различные инструменты для создания миграций и запуска их в вашей базе данных, но для этого ему необходимо понимать ваш код. По сути, он должен иметь возможность исполнять код запуска вашего приложения, чтобы использовать все настроенные вами сервисы конфигурации и внедрения зависимостей.
В предыдущих версиях ASP.NET Core EF Core подключался к методу
Поддержка инструментов EF Core в .NET 6
Чтобы обойти изменения, внесённые в .NET 6, в
1. На время действия метода
2. Если что-либо прослушивает событие Microsoft.Extensions.Hosting.HostBuilding (хост строится),
3. После создания хоста и перед возвратом из метода
Вот как инструменты EF Core используют эти события (см. схему ниже):
1. Загружается сборка вашего приложения.
2. Создаётся экземпляр вспомогательного класса
3. Точка входа запускается в фоновом потоке. Это запускает ваше приложение. И предполагается, что в какой-то момент ваше приложение вызовет
4. Идёт ожидание одного из трёх событий:
- Код слушателя выдаёт исключение
- В запущенном приложении возникает иное исключение.
- Запуск приложения занимает слишком много времени, поэтому прерывается по таймауту.
5. Результат (в виде построенного хоста или в виде сгенерированного исключения) передаётся инструментам EF Core.
Пара слов о
Подробный перевод статьи с примерами кода размещён на Хабре.
Источник: https://andrewlock.net/exploring-dotnet-6-part-5-supporting-ef-core-tools-with-webapplicationbuilder/
Исследуем .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/
Чему Можно Научиться из Книг «Программист-прагматик» и «Идеальный программист». Часть 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/
👍3
День 1065. #ЗаметкиНаПолях #AsyncTips
Параллельная обработка данных
Задача: Имеется коллекция данных. Требуется выполнить одну и ту же операцию с каждым элементом. Эта операция является ограниченной по вычислениям и может занять некоторое время.
Решение
Тип
Более распространённая ситуация встречается тогда, когда требуется отменить параллельный цикл. Это не то же, что остановка: цикл останавливается изнутри и отменяется за своими пределами. Например, кнопка отмены может отменить
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 4.
Параллельная обработка данных
Задача: Имеется коллекция данных. Требуется выполнить одну и ту же операцию с каждым элементом. Эта операция является ограниченной по вычислениям и может занять некоторое время.
Решение
Тип
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.
👍3
День 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 недвусмысленно намекнули об изменении своего подхода к разработке ПО и что они не против оставить в прошлом синтаксис
Да, строго говоря, Microsoft официально не отказывались от Visual Basic. Они создали VB.NET с некоторыми изменениями синтаксиса и согласились «развивать» его параллельно с C#. Хотя в то время официально об этом не говорили, но на его рекламу и продвижение было потрачено гораздо меньше времени и усилий. И многие разработчики считали, что Microsoft твердо намерены перевести разработчиков на C#.
Заглянув в историю 90-х, теперь можно посмотреть на мир, в котором дебютировал C# 1.0. Он вошёл в мир, где продолжались споры о том, действительно ли нужны ещё какие-либо коммерческие языки программирования, и, кроме того, он выглядел чрезвычайно похожим на язык программирования конкурирующей компании… Java. Настолько похож, что даже некоторые недостатки Java были сознательно продублированы, например ковариантность массивов.
В Microsoft решили эту проблему с помощью обобщений. Хотя, в первоначальном выпуске было явно запрещено делать что-то вроде следующего:
Продолжение следует…
Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html
Оглядываясь Назад на 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){}В некоторых случаях преобразование типов для обобщений, делегатов и т.п. было упрощено в зависимости от того, как использовался тип. Затем Microsoft обновили значительную часть платформы .NET, чтобы без проблем разрешить эти упрощённые правила неявного преобразования.
...
public void AddManager () {
List<Manager> managers = new List<Manager>();
// Изначально это было запрещено, даже при том,
// что Manager – подтип Employee.
AddEmployee(managers);
}
Продолжение следует…
Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html
👍11
День 1067.
Оглядываясь Назад на C#. Продолжение
С новым годом! Продолжаем вчерашнюю историю…
Наряду с этим у языка C# были «особенности», которые и в то время считались пугающими, а сегодня вообще бы сделали язык непригодным для использования:
1. В C# были только массивы (никаких других коллекций), и во многих случаях их нельзя было расширять. В то время в .NET Framework были вспомогательные функции для этого, но это было совсем не так просто, как, например, вызов
2. Боксинг, который существует до сих пор, хотя представляет гораздо меньшую проблему, чем в 2001 году.
3. Обнуляемые значимые типы (например, целые числа) не существовали. Это ставило разработчиков перед трудной проблемой определения того, как обрабатывать значения по умолчанию. Вы предполагали, что 0 - значение по умолчанию для целых чисел. Это работало, только если 0 не находился в диапазоне допустимых значений. Тогда приходилось выбирать другое значение, например -1. И это работало, пока кто-то не забывал установить это значение по умолчанию, и вы не тратили часы на поиск того, откуда появляется 0.
4. Хотя технически это не совсем проблема C#, концепция файла
С другой стороны, в Microsoft предприняли несколько смелых шагов, невиданных в языках в то время, чтобы помочь программистам в их повседневной работе. Хотя C#, возможно, и не изобрёл с нуля эти концепции, он пропагандировал их, просто мягко побуждая разработчиков работать более продуктивно и устраняя распространённые ошибки, что и сделало его популярным.
Один из примеров – запрет «проваливаться» в следующий
Точно так же C# убрал необходимость в «синтаксисе Йоды»
Также запрещены выражения вроде
Окончание следует…
Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html
Оглядываясь Назад на C#. Продолжение
С новым годом! Продолжаем вчерашнюю историю…
Наряду с этим у языка C# были «особенности», которые и в то время считались пугающими, а сегодня вообще бы сделали язык непригодным для использования:
1. В C# были только массивы (никаких других коллекций), и во многих случаях их нельзя было расширять. В то время в .NET Framework были вспомогательные функции для этого, но это было совсем не так просто, как, например, вызов
List<T>.Add()
. Встроенные функции копировали данные в новый массив, поэтому, если вы рассчитывали, что ссылки на исходный массив все ещё работают, вам не повезло. Вы также должны были осознавать компромиссы между временем и количеством памяти и выбирать оптимальный подход. В .NET был список ArrayList
, который изначально поддерживал расширение, но только в том случае, если вы соглашались с тем, что все его элементы были типа Object
.2. Боксинг, который существует до сих пор, хотя представляет гораздо меньшую проблему, чем в 2001 году.
3. Обнуляемые значимые типы (например, целые числа) не существовали. Это ставило разработчиков перед трудной проблемой определения того, как обрабатывать значения по умолчанию. Вы предполагали, что 0 - значение по умолчанию для целых чисел. Это работало, только если 0 не находился в диапазоне допустимых значений. Тогда приходилось выбирать другое значение, например -1. И это работало, пока кто-то не забывал установить это значение по умолчанию, и вы не тратили часы на поиск того, откуда появляется 0.
4. Хотя технически это не совсем проблема C#, концепция файла
.ini
была заменена конфигурацией в виде XML, который разработчики до этого никогда не видели и не понимали, как использовать. Хотя сейчас это звучит довольно глупо, простая конфигурация в виде «ключ=значение» была заменена гораздо более многословным синтаксисом.С другой стороны, в Microsoft предприняли несколько смелых шагов, невиданных в языках в то время, чтобы помочь программистам в их повседневной работе. Хотя C#, возможно, и не изобрёл с нуля эти концепции, он пропагандировал их, просто мягко побуждая разработчиков работать более продуктивно и устраняя распространённые ошибки, что и сделало его популярным.
Один из примеров – запрет «проваливаться» в следующий
case
:switch numberХотя некоторым это ограничение кажется смешным, оно экономит бесчисленные часы отладки, когда
{
case 0:
DoSomething();
// Нельзя опускать оператор break
case 1:
DoSomethingElse();
break;
...
}
break
был случайно пропущен.Точно так же C# убрал необходимость в «синтаксисе Йоды»
if (42 == answer)
, когда константа ставится в левую часть оператора сравнения, просто чтобы не путать сравнение с присваиванием if (answer = 42)
. Также запрещены выражения вроде
if(42)
, а требуется явное if(42 > 0)
, потому что первое сбивает с толку людей, не понимающих, почему, например, в JavaScript if(-1)
оценивается как true.Окончание следует…
Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html
👍4👎2
День 1068.
Оглядываясь Назад на C#. Окончание
Начало
Продолжение
Примерно в 2005 году в Microsoft сделали амбициозный шаг и представили концепцию обобщений. Их реализация в C# существенно изменила ландшафт языка и среды выполнения, предоставив более сильный функционал по сравнению с реализацией в Java, появившейся годом ранее. C++, Python, Rust, Swift и Go теперь тоже поддерживают обобщения, и без них будущее C# определённо было бы под вопросом. Сейчас нельзя и представить C# без обобщений и их преемников, и они также рассматривались как важный шаг в преодолении разрыва между чисто академическими языками и языками, используемыми в коммерческих целях.
В том же году легендарный C++ программист Херб Саттер написал свою культовую статью «Бесплатный обед закончился», в которой он предсказал крах систем, строго полагавшихся на то, что скорость процессоров будет постоянно увеличиваться, позволяя программам работать быстрее без дополнительных оптимизаций. В Microsoft осознали, что любой вид асинхронного программирования, существовавший в то время, был трудным почти для всех разработчиков. C# получил модель async/await в 2011 году в предварительной версии и официально в 2012 году. (Хотя Microsoft ещё в 2010 году добавили Task Parallel Library для решения схожих задач). Трудно сказать, откуда другие языки черпали вдохновение, но несколько языков последовали за C# и также добавили этот шаблон:
- Python в 2015,
- Typescript в 2015,
- JavaScript в 2017,
- Rust в 2019,
- C++ в 2020,
- Swift в 2021.
Помимо всего этого, на протяжении многих лет в Microsoft работали над сокращением многословности языка, чтобы повысить удобочитаемость и общую продуктивность с точки зрения чистого печатания. В C# всегда можно было передавать функции в качестве аргументов, но синтаксис в первых версиях был громоздким и препятствовал широкому распространению этого приёма. Введение в 2007 году лямбда-функций (в C# 3.0) решило эту проблему, открыв путь для широкого распространения LINQ. Сократили геттеры и сеттеры свойств, которые требовали от разработчика вручную создавать поле и писать инструкции для обновления и получения значения. Переписали компилятор, чтобы разрешить перехватывать процесс сборки для анализа и добавления нового кода. Вот лишь некоторые из улучшений.
Оглядываясь назад, более чем 20 лет спустя, C# действительно сохранил свой костяк с момента возникновения, но некоторые аспекты также полностью изменились по мере того, как менялись мнения о теории программирования. Ещё в 90-х функциональное программирование считалось в основном академическим занятием, но сегодня стало очень популярным. Изначально C# позиционировал себя как объектно-ориентированный язык, но с годами изменился, чтобы быть в первую очередь объектно-ориентированным языком, но с дополнениями, поддерживающими функциональный характер разработки. Некоторые задаются вопросом, движется ли он по тому же пути, что и PERL, который кажется хаотичным набором огромного количества способов выполнить одну и ту же задачу, но в то же время без адаптации к реалиям язык обречён на то, чтобы быть забытым, как и многие его предшественники.
Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html
Оглядываясь Назад на C#. Окончание
Начало
Продолжение
Примерно в 2005 году в Microsoft сделали амбициозный шаг и представили концепцию обобщений. Их реализация в C# существенно изменила ландшафт языка и среды выполнения, предоставив более сильный функционал по сравнению с реализацией в Java, появившейся годом ранее. C++, Python, Rust, Swift и Go теперь тоже поддерживают обобщения, и без них будущее C# определённо было бы под вопросом. Сейчас нельзя и представить C# без обобщений и их преемников, и они также рассматривались как важный шаг в преодолении разрыва между чисто академическими языками и языками, используемыми в коммерческих целях.
В том же году легендарный C++ программист Херб Саттер написал свою культовую статью «Бесплатный обед закончился», в которой он предсказал крах систем, строго полагавшихся на то, что скорость процессоров будет постоянно увеличиваться, позволяя программам работать быстрее без дополнительных оптимизаций. В Microsoft осознали, что любой вид асинхронного программирования, существовавший в то время, был трудным почти для всех разработчиков. C# получил модель async/await в 2011 году в предварительной версии и официально в 2012 году. (Хотя Microsoft ещё в 2010 году добавили Task Parallel Library для решения схожих задач). Трудно сказать, откуда другие языки черпали вдохновение, но несколько языков последовали за C# и также добавили этот шаблон:
- Python в 2015,
- Typescript в 2015,
- JavaScript в 2017,
- Rust в 2019,
- C++ в 2020,
- Swift в 2021.
Помимо всего этого, на протяжении многих лет в Microsoft работали над сокращением многословности языка, чтобы повысить удобочитаемость и общую продуктивность с точки зрения чистого печатания. В C# всегда можно было передавать функции в качестве аргументов, но синтаксис в первых версиях был громоздким и препятствовал широкому распространению этого приёма. Введение в 2007 году лямбда-функций (в C# 3.0) решило эту проблему, открыв путь для широкого распространения LINQ. Сократили геттеры и сеттеры свойств, которые требовали от разработчика вручную создавать поле и писать инструкции для обновления и получения значения. Переписали компилятор, чтобы разрешить перехватывать процесс сборки для анализа и добавления нового кода. Вот лишь некоторые из улучшений.
Оглядываясь назад, более чем 20 лет спустя, C# действительно сохранил свой костяк с момента возникновения, но некоторые аспекты также полностью изменились по мере того, как менялись мнения о теории программирования. Ещё в 90-х функциональное программирование считалось в основном академическим занятием, но сегодня стало очень популярным. Изначально C# позиционировал себя как объектно-ориентированный язык, но с годами изменился, чтобы быть в первую очередь объектно-ориентированным языком, но с дополнениями, поддерживающими функциональный характер разработки. Некоторые задаются вопросом, движется ли он по тому же пути, что и PERL, который кажется хаотичным набором огромного количества способов выполнить одну и ту же задачу, но в то же время без адаптации к реалиям язык обречён на то, чтобы быть забытым, как и многие его предшественники.
Источник: https://kemiller2002.github.io/c-sharp/2021/12/24/reflection.html
👍7
День 1069. #Книги
Вдохновившись этой серией постов, решил-таки полностью прочитать книгу дядюшки Боба «Идеальный программист». И должен вам сказать, прошла она у меня на ура. Прекрасное ненапряжное чтение для метро, автобуса по дороге на работу (или где вы там ещё книжки читаете).
Книга про карьеру разработчика. Приводятся советы относительно различных жизненных ситуаций, с которыми вы можете столкнуться на работе. Всё это приправлено байками из жизни самого Роберта Мартина.
Конечно, не обошлось без присущего дядюшке Бобу идеализма, и кое-где он перегибает палку в плане категоричности суждений. Но в целом книга понравилась, советую.
PS: Накидайте в комментарии похожего околопрограммистского «лёгкого чтива». Я ещё читал «Мифический человеко-месяц» Фредерика Брукса (но она уже порядком устарела) и «Кодеры за работой» Питера Сейбела. Последняя представляет собой серию интервью с известными программистами от создателя ЖЖ Брэда Фицпатрика до самого Дональда Кнута. Хотя написана довольно сухо.
Вдохновившись этой серией постов, решил-таки полностью прочитать книгу дядюшки Боба «Идеальный программист». И должен вам сказать, прошла она у меня на ура. Прекрасное ненапряжное чтение для метро, автобуса по дороге на работу (или где вы там ещё книжки читаете).
Книга про карьеру разработчика. Приводятся советы относительно различных жизненных ситуаций, с которыми вы можете столкнуться на работе. Всё это приправлено байками из жизни самого Роберта Мартина.
Конечно, не обошлось без присущего дядюшке Бобу идеализма, и кое-где он перегибает палку в плане категоричности суждений. Но в целом книга понравилась, советую.
PS: Накидайте в комментарии похожего околопрограммистского «лёгкого чтива». Я ещё читал «Мифический человеко-месяц» Фредерика Брукса (но она уже порядком устарела) и «Кодеры за работой» Питера Сейбела. Последняя представляет собой серию интервью с известными программистами от создателя ЖЖ Брэда Фицпатрика до самого Дональда Кнута. Хотя написана довольно сухо.
👍1
День 1071. #NET6
Не Делайте Этого В .NET 6, Делайте Вот Так. Начало
В C# 10 появилось много хороших вещей: улучшения производительности, горячая перезагрузка, минимальные API и многое другое. Большинство разговоров идёт про важные функции. А что насчёт более мелких улучшений, который всё же помогают сделать ваш ежедневный опыт разработки более продуктивным? Многие из них могут помочь убрать шаблонный код и ускорить достижение цели.
1. Не разбивайте большие коллекции вручную, используйте новый API LINQ
При работе с большими коллекциями иногда нужно разбивать их на более мелкие порции (страницы). Чаще всего это приводит к серии вызовов методов
Если вам нужно работать с датой и временем в .NET, вы обычно используете
3. Не пишите кучу кода для логирования HTTP-запросов, используйте новое промежуточное ПО
До .NET 6 регистрировать HTTP-запросы было не сложно, но немного многословно. Один из способов - создать своё промежуточное ПО, где логировать запрос и передавать его дальше по конвейеру.
Не делайте так. Вместо этого используйте новое промежуточное ПО .NET 6 HTTP Logging:
Окончание следует...
Источник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/
Не Делайте Этого В .NET 6, Делайте Вот Так. Начало
В C# 10 появилось много хороших вещей: улучшения производительности, горячая перезагрузка, минимальные API и многое другое. Большинство разговоров идёт про важные функции. А что насчёт более мелких улучшений, который всё же помогают сделать ваш ежедневный опыт разработки более продуктивным? Многие из них могут помочь убрать шаблонный код и ускорить достижение цели.
1. Не разбивайте большие коллекции вручную, используйте новый API LINQ
При работе с большими коллекциями иногда нужно разбивать их на более мелкие порции (страницы). Чаще всего это приводит к серии вызовов методов
Take
и Skip
, либо к созданию метода расширения, вроде этого популярного ответа со Stack Overflow:static class LinqExtensionsНе делайте так. Вместо этого используйте новый метод
{
public static IEnumerable<IEnumerable<T>> Split<T>(
this IEnumerable<T> list, int parts)
{
int i = 0;
var splits =
from item in list
group item by i++ % parts into part
select part.AsEnumerable();
return splits;
}
}
Chunk
:int pageSize = 10;2. Если вам нужна только дата, не используйте DateTime, используйте DateOnly
IEnumerable<Employee[]> employeeChunk = employees.Chunk(pageSize);
Если вам нужно работать с датой и временем в .NET, вы обычно используете
DateTime
, TimeSpan
или DateTimeOffset
. Что, если вам нужно работать только с датами и нужен только год, месяц или день? В .NET 6 вы можете использовать новую структуру DateOnly
(также можно использовать TimeOnly
). Вот стандартный код, который вы могли использовать раньше:var someDateTime = new DateTime(2021, 11, 09);Не делайте так. Вместо этого используйте структуру
// 09.11.2021 12:00:00 AM
var justTheDate = someDateTime.ToShortDateString();
// "09.11.2021"
DateOnly
:var someDateTime = new DateOnly(2021, 11, 09);Вы можете делать множество манипуляций с новыми структурами, вроде расчёта дней между датами, и даже комбинировать их с
// 09.11.2021
DateTime
. Также структура предлагает лучшую безопасность типов для дат и более простую сериализацию.3. Не пишите кучу кода для логирования HTTP-запросов, используйте новое промежуточное ПО
До .NET 6 регистрировать HTTP-запросы было не сложно, но немного многословно. Один из способов - создать своё промежуточное ПО, где логировать запрос и передавать его дальше по конвейеру.
Не делайте так. Вместо этого используйте новое промежуточное ПО .NET 6 HTTP Logging:
public void Configure(Логирование можно настроить по вашему усмотрению:
IApplicationBuilder app,
IWebHostEnvironment env)
{
app.UseHttpLogging();
// ...
}
public void ConfigureServices(Надо следить за тем, что вы пишете в лог, и как часто, но всё же это серьёзное упрощение процедуры.
IServiceCollection services)
{
services.AddHttpLogging(log =>
{
log.LoggingFields = HttpLoggingFields.All;
log.RequestHeaders.Add("X-Request-Header");
log.ResponseHeaders.Add("X-Response-Header");
log.RequestBodyLogLimit = 4096;
log.ResponseBodyLogLimit = 4096;
});
}
Окончание следует...
Источник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/
👍29
День 1072. #NET6
Не Делайте Этого В .NET 6, Делайте Вот Так. Окончание
Начало
4. Не используйте костыли для обработки исключений в Blazor Server, используйте компонент ErrorBoundary
Что происходит при возникновении необработанного исключения в Blazor Server? Оно считается фатальным, поскольку «цепь остается в неопределённом состоянии, что может привести к проблемам со стабильностью или безопасностью в Blazor Server». В результате вам может потребоваться разбрасывать повсюду блоки try/catch в качестве превентивной меры или инкапсулировать логику в JavaScript, поскольку код C# после необработанного исключения не будет выполнен.
Не делайте так. Вместо этого используйте новый компонент
Если я хочу включить подробный логгинг для Kestrel, раньше нужно было использовать
В C# 10 представлены пространства имён уровня файлов. Вот обычное объявление класса в C# до версии 10:
Не Делайте Этого В .NET 6, Делайте Вот Так. Окончание
Начало
4. Не используйте костыли для обработки исключений в Blazor Server, используйте компонент ErrorBoundary
Что происходит при возникновении необработанного исключения в Blazor Server? Оно считается фатальным, поскольку «цепь остается в неопределённом состоянии, что может привести к проблемам со стабильностью или безопасностью в Blazor Server». В результате вам может потребоваться разбрасывать повсюду блоки try/catch в качестве превентивной меры или инкапсулировать логику в JavaScript, поскольку код C# после необработанного исключения не будет выполнен.
Не делайте так. Вместо этого используйте новый компонент
ErrorBoundary
. Это не глобальный обработчик исключений, но он поможет справиться с непредсказуемым поведением, особенно с компонентами, которые вы не контролируете.<div class="main">Конечно, можно не перехватывать все исключения:
<div class="content px-4">
<ErrorBoundary>
@Body
</ErrorBoundary>
</div>
</div>
<tbody>5. Не используйте подробный логгинг в Server.Kestrel, используйте новые подкатегории
@foreach (var emp in Employees)
{
<ErrorBoundary @key="@emp">
<ChildContent>
<tr>
<td>@emp.Id</td>
<td>@emp.FirstName</td>
<td>@emp.LastName</td>
</tr>
</ChildContent>
<ErrorContent>
Не удалось отобразить #@emp.Id.
</ErrorContent>
</ErrorBoundary>
}
</tbody>
Если я хочу включить подробный логгинг для Kestrel, раньше нужно было использовать
Microsoft.AspNetCore.Server.Kestrel
. Это всё ещё существует, но есть и новые подкатегории, которые упрощают жизнь. В дополнение к Server.Kestrel
теперь есть Kestrel.BadRequests
, Kestrel.Connections
, Kestrel.Http2
и Kestrel.Http3
. Допустим, вы хотите регистрировать только неверные запросы:{Не делайте так. Делайте вот так:
"Logging": {
"LogLevel": {
"Microsoft.AspNetCore.Server.Kestrel": "Debug"
}
}
}
{6. Не теряйтесь в скобках, используйте пространства имён уровня файлов
"Logging": {
"LogLevel": {
"Microsoft.AspNetCore.Server.Kestrel.BadRequests": "Debug"
}
}
}
В C# 10 представлены пространства имён уровня файлов. Вот обычное объявление класса в C# до версии 10:
namespace SuperheroApp.ModelsТеперь можно убрать скобки в пространстве имён, а также получить все преимущества неизменяемости, использовав записи:
{
public class Superhero
{
public string? FirstName { get; set; }
public string? LastName { get; set; }
}
}
namespace SuperheroApp.Models;Кстати, о скобках. В C# 10 также введены новые шаблоны свойств. В выражении
public record Superhero(string? FirstName, string? LastName);
switch
вместо var tax = sales switchможно использовать более ясный формат:
{
{ Address: { State: "AZ" } } => 1.03M,
{ Address: { State: "FL" } } => 1.07M,
{ Address: { State: "CA" } } => 1.12M
_ => 0
};
var tax = sales switchИсточник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/
{
{ Address.State: "AZ" } => 1.03M,
{ Address.State: "FL" } => 1.07M,
{ Address.State: "CA" } => 1.12M
_ => 0
};
👍10
День 1073. #Testing
Исправлять ли Ошибки в Приватных Методах, Если Они Компенсируют Друг Друга?
Недавно наткнулся на интересное обсуждение. Нужно ли исправлять ошибки, которые компенсируют друг друга и в итоге приводят к правильному поведению?
Допустим, у нас есть такой код:
Как следует тестировать этот метод? Общее мнение, что вам следует тестировать только публичные методы. Приватные методы следует тестировать косвенно, через публичные методы, которые их используют.
Другими словами,
Но разве этот совет не заставляет вас игнорировать ошибки в
В нашем примере метод
Клиентов
Так что да, этот совет потенциально может привести к незамеченным ошибкам в приватных методах. Но нет, это не проблема, потому что эти ошибки никогда не проявятся. Если только приватные методы не используются где-либо ещё, и там ошибка проявляется в публичных методах. Но тогда она должна быть обнаружена тестами тех публичных методов.
Я бы даже сказал, что это вовсе не ошибки, потому что клиенты вашего приложения не могут с ними столкнуться. Как говорится, если в лесу упало дерево и никто этого не услышал, можно ли считать, что оно упало беззвучно?
Однако, если бы эти методы не были приватными, всё было бы по-другому. Теперь, когда эти методы являются частью общедоступного API, они также становятся частью наблюдаемого поведения и, следовательно, должны быть протестированы и исправлены. Но до тех пор ошибки в приватных методах - не проблема.
Конечно, если вы заметили ошибки в приватных методах
Но это «исправление» будет рефакторингом, а не исправлением ошибки: здесь вы меняете детали реализации; наблюдаемое поведение остаётся неизменным.
Источник: https://enterprisecraftsmanship.com/
Автор Оригинала: Владимир Хориков
Исправлять ли Ошибки в Приватных Методах, Если Они Компенсируют Друг Друга?
Недавно наткнулся на интересное обсуждение. Нужно ли исправлять ошибки, которые компенсируют друг друга и в итоге приводят к правильному поведению?
Допустим, у нас есть такой код:
public void PerformAction()Допустим, что и
{
Step1();
Step2();
}
private void Step1()
{ ... }
private void Step2()
{ ... }
Step1
, и Step2
содержат ошибки в своей реализации, но общее поведение метода PerformAction
является правильным, потому что по чистой случайности ошибки в двух приватных методах взаимно компенсируются.Как следует тестировать этот метод? Общее мнение, что вам следует тестировать только публичные методы. Приватные методы следует тестировать косвенно, через публичные методы, которые их используют.
Другими словами,
PerformAction
- единственный метод, который здесь следует тестировать. Step1
и Step2
вообще не должны рассматриваться.Но разве этот совет не заставляет вас игнорировать ошибки в
Step1
и Step2
, поскольку поведение PerformAction
остаётся правильным? Это отличный вопрос, и чтобы ответить на него, нам нужно ещё раз обсудить разницу между «наблюдаемым поведением» и «деталями реализации».В нашем примере метод
PerformAction
- это наблюдаемое поведение, а Step1
и Step2
- детали реализации. Поэтому единственное, что имеет значение, - это поведение PerformAction
.Клиентов
PerformAction
не волнует, как именно этот метод выполняет свою функцию. Единственное, что их волнует, - это конечный результат - его наблюдаемое поведение. Модульные тесты всегда должны имитировать клиентов тестируемого кода и, следовательно, не должны заботиться о двух приватных методах.Так что да, этот совет потенциально может привести к незамеченным ошибкам в приватных методах. Но нет, это не проблема, потому что эти ошибки никогда не проявятся. Если только приватные методы не используются где-либо ещё, и там ошибка проявляется в публичных методах. Но тогда она должна быть обнаружена тестами тех публичных методов.
Я бы даже сказал, что это вовсе не ошибки, потому что клиенты вашего приложения не могут с ними столкнуться. Как говорится, если в лесу упало дерево и никто этого не услышал, можно ли считать, что оно упало беззвучно?
Однако, если бы эти методы не были приватными, всё было бы по-другому. Теперь, когда эти методы являются частью общедоступного API, они также становятся частью наблюдаемого поведения и, следовательно, должны быть протестированы и исправлены. Но до тех пор ошибки в приватных методах - не проблема.
Конечно, если вы заметили ошибки в приватных методах
Step1
и Step2
, лучше всего исправить их независимо от того, заметны ли они, чтобы избежать путаницы для будущих читателей этих методов.Но это «исправление» будет рефакторингом, а не исправлением ошибки: здесь вы меняете детали реализации; наблюдаемое поведение остаётся неизменным.
Источник: https://enterprisecraftsmanship.com/
Автор Оригинала: Владимир Хориков
👍8