День 1992. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 15. Расстановка приоритетов по децибелам - не лучшая стратегия
Слышали поговорку: «Смазывают то колесо, которое скрипит»? По аналогии тот, кто громче всех отстаивает свои требования, получает наивысший приоритет.
Часто требований так много, что все их сложно добавить в проект. Лица, принимающие решения, должны выбрать, что добавить прямо сейчас, что отложить, от чего вовсе отказаться. Расстановка приоритетов — обязательный элемент планирования проекта. Она помогает распределить требования между итерациями, сборками или выпусками.
Каждому заинтересованному лицу кажется, что его потребности самые важные. Влиятельные, волевые или громкоголосые клиенты могут оказывать сильное давление, но они не всегда отстаивают самые важные с точки зрения бизнеса функции. Цель расстановки приоритетов — быстрое и недорогое предоставление максимальной ценности для клиента. Не нужно тратить силы на реализацию функций, не способствующих успеху продукта.
Методы определения приоритетов
- трехуровневая классификация: высокий, средний и низкий приоритет;
- классификация MoSCoW (Must, Should, Could, Won’t — обязательно, желательно, возможно, не нужно);
- попарное сравнение требований для сортировки по приоритетам;
- упорядочивание приоритетов похожих требований;
- распределение 100 баллов между требованиями в зависимости от приоритета;
- игра в планирование ;
- аналитические методы ранжирования требований на основе их ценности для продукта и стоимости реализации.
Критерии выбора приоритетов
1. Бизнес-цели
Наиболее весомый критерий — степень, в которой каждое требование поможет организации достичь её бизнес-целей. Такие суждения основываются на бизнес-требованиях проекта, которые спонсор должен определить на ранней стадии проекта. Они описывают создаваемую или используемую бизнес-возможность и количественно определяют бизнес-цели проекта.
2. Группы пользователей
Удовлетворение требований привилегированных групп пользователей больше способствует успеху бизнеса, чем удовлетворение потребностей других групп.
3. Частота использования
Один из способов оценить частоту использования — изучение особенностей применения приложения. Например, какой процент пользовательских сеансов на сайте авиакомпании связан с бронированием, отменой бронирования, проверкой статуса рейса и т.п.? Обычно (но не всегда) наиболее часто используемые операции будут иметь наивысший приоритет.
4. Соответствие нормативам
Такие требования должны иметь высокий приоритет. Вы не сможете продать продукт, если он не будет сертифицирован. Некоторые из таких функций могут иметь высокий приоритет, даже если ни один конечный пользователь не запрашивает их.
5. Основная функциональность
Некоторые возможности следует реализовать на раннем этапе, даже если они не приносят немедленную выгоду, т.к. они - основа для последующих функций. Определяя последовательность реализации, нужно учитывать зависимости между требованиями. От некоторых функций может зависеть архитектурная надёжность сложного продукта.
6. Рискованная функциональность
Требования, подразумевающие высокий риск с точки зрения реализации, следует реализовывать на ранней стадии, чтобы оценить их выполнимость и снизить общий технический риск проекта.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.
Уроки 50 Лет Разработки ПО
Урок 15. Расстановка приоритетов по децибелам - не лучшая стратегия
Слышали поговорку: «Смазывают то колесо, которое скрипит»? По аналогии тот, кто громче всех отстаивает свои требования, получает наивысший приоритет.
Часто требований так много, что все их сложно добавить в проект. Лица, принимающие решения, должны выбрать, что добавить прямо сейчас, что отложить, от чего вовсе отказаться. Расстановка приоритетов — обязательный элемент планирования проекта. Она помогает распределить требования между итерациями, сборками или выпусками.
Каждому заинтересованному лицу кажется, что его потребности самые важные. Влиятельные, волевые или громкоголосые клиенты могут оказывать сильное давление, но они не всегда отстаивают самые важные с точки зрения бизнеса функции. Цель расстановки приоритетов — быстрое и недорогое предоставление максимальной ценности для клиента. Не нужно тратить силы на реализацию функций, не способствующих успеху продукта.
Методы определения приоритетов
- трехуровневая классификация: высокий, средний и низкий приоритет;
- классификация MoSCoW (Must, Should, Could, Won’t — обязательно, желательно, возможно, не нужно);
- попарное сравнение требований для сортировки по приоритетам;
- упорядочивание приоритетов похожих требований;
- распределение 100 баллов между требованиями в зависимости от приоритета;
- игра в планирование ;
- аналитические методы ранжирования требований на основе их ценности для продукта и стоимости реализации.
Критерии выбора приоритетов
1. Бизнес-цели
Наиболее весомый критерий — степень, в которой каждое требование поможет организации достичь её бизнес-целей. Такие суждения основываются на бизнес-требованиях проекта, которые спонсор должен определить на ранней стадии проекта. Они описывают создаваемую или используемую бизнес-возможность и количественно определяют бизнес-цели проекта.
2. Группы пользователей
Удовлетворение требований привилегированных групп пользователей больше способствует успеху бизнеса, чем удовлетворение потребностей других групп.
3. Частота использования
Один из способов оценить частоту использования — изучение особенностей применения приложения. Например, какой процент пользовательских сеансов на сайте авиакомпании связан с бронированием, отменой бронирования, проверкой статуса рейса и т.п.? Обычно (но не всегда) наиболее часто используемые операции будут иметь наивысший приоритет.
4. Соответствие нормативам
Такие требования должны иметь высокий приоритет. Вы не сможете продать продукт, если он не будет сертифицирован. Некоторые из таких функций могут иметь высокий приоритет, даже если ни один конечный пользователь не запрашивает их.
5. Основная функциональность
Некоторые возможности следует реализовать на раннем этапе, даже если они не приносят немедленную выгоду, т.к. они - основа для последующих функций. Определяя последовательность реализации, нужно учитывать зависимости между требованиями. От некоторых функций может зависеть архитектурная надёжность сложного продукта.
6. Рискованная функциональность
Требования, подразумевающие высокий риск с точки зрения реализации, следует реализовывать на ранней стадии, чтобы оценить их выполнимость и снизить общий технический риск проекта.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.
👍5
День 1993. #ЗаметкиНаПолях #Cancellation
Отмена. Часть 2: Запрос Отмены.
В прошлый раз мы рассмотрели базовый контракт отмены. Теперь рассмотрим, как создавать токены отмены для запроса отмены.
CancellationTokenSource
Некоторые токены отмены предоставляются используемой вами платформой или библиотекой. Например, ASP.NET предоставит вам CancellationToken, который представляет собой неожиданное отключение клиента. Polly может предоставить вашему делегату токен, который представляет собой более общую отмену (например, срабатывание политики тайм-аута).
В других сценариях вам потребуется предоставить собственный токен. В общем случае, когда вы хотите создать CancellationToken, который можно будет отменить позже, нужно использовать CancellationTokenSource.
Каждый CancellationTokenSource управляет своим набором токенов. Каждый токен, созданный из CancellationTokenSource, представляет собой небольшую структуру, которая ссылается на свой CancellationTokenSource. Токен отмены может только отвечать на запросы отмены; CancellationTokenSource необходим для запроса отмены. Поэтому запрашивающий код создает CancellationTokenSource и сохраняет ссылку на него (используя эту ссылку позже для запроса отмены), а отвечающий код просто получает CancellationToken и использует его для ответа на запросы отмены.
Таймауты
Одной из распространённых потребностей отмены является реализация тайм-аута. Решение состоит в том, чтобы иметь таймер, который запрашивает отмену по истечении срока его действия. В CancellationTokenSource такое поведение встроено. Вы можете использовать конструктор CancellationTokenSource, который принимает таймаут, или вызвать CancelAfter для существующего CancellationTokenSource:
Очистка
Чтобы избежать утечек ресурсов, важно уничтожать (dispose) экземпляры CancellationTokenSource. Очищается несколько видов ресурсов: во-первых, таймер тайм-аута (если он есть); во-вторых, все «слушатели», прикрепленные к токенам отмены. Эта очистка выполняется при отмене или уничтожении CancellationTokenSource. Вы должны убедиться, что либо одно, либо другое выполнено, чтобы избежать утечек ресурсов.
Если токен отмены сохраняется и используется позже, вы бы не хотели уничтожать CancellationTokenSource. В этом случае следует сохранять CancellationTokenSource активным до тех пор, пока вы не будете уверены, что весь код, использующий его токены, выполнен. Это более сложный случай, и иногда удобнее отменить CancellationTokenSource, а не уничтожать его.
Предупреждение: уничтожение связанных источников CancellationTokenSource.
Вызов Cancel или Dispose очистит все регистрации для конкретного CancellationTokenSource. Однако если этот CancellationTokenSource связан с «родительским» CancellationTokenSource, вызов Cancel для «дочернего» CancellationTokenSource приведёт к отмене регистрации в «родительском» CancellationTokenSource. Вы можете вызвать Dispose (или использовать оператор using) для «дочернего элемента», чтобы очистить регистрацию у родителя этого дочернего элемента, разрывая ссылку.
Эта и другие темы, касающиеся связанных CancellationTokenSource, будут рассмотрены далее в этой серии.
Источник: https://blog.stephencleary.com/2022/03/cancellation-2-requesting-cancellation.html
Отмена. Часть 2: Запрос Отмены.
В прошлый раз мы рассмотрели базовый контракт отмены. Теперь рассмотрим, как создавать токены отмены для запроса отмены.
CancellationTokenSource
Некоторые токены отмены предоставляются используемой вами платформой или библиотекой. Например, ASP.NET предоставит вам CancellationToken, который представляет собой неожиданное отключение клиента. Polly может предоставить вашему делегату токен, который представляет собой более общую отмену (например, срабатывание политики тайм-аута).
В других сценариях вам потребуется предоставить собственный токен. В общем случае, когда вы хотите создать CancellationToken, который можно будет отменить позже, нужно использовать CancellationTokenSource.
Каждый CancellationTokenSource управляет своим набором токенов. Каждый токен, созданный из CancellationTokenSource, представляет собой небольшую структуру, которая ссылается на свой CancellationTokenSource. Токен отмены может только отвечать на запросы отмены; CancellationTokenSource необходим для запроса отмены. Поэтому запрашивающий код создает CancellationTokenSource и сохраняет ссылку на него (используя эту ссылку позже для запроса отмены), а отвечающий код просто получает CancellationToken и использует его для ответа на запросы отмены.
Таймауты
Одной из распространённых потребностей отмены является реализация тайм-аута. Решение состоит в том, чтобы иметь таймер, который запрашивает отмену по истечении срока его действия. В CancellationTokenSource такое поведение встроено. Вы можете использовать конструктор CancellationTokenSource, который принимает таймаут, или вызвать CancelAfter для существующего CancellationTokenSource:
async Task DoSomethingWithTimeoutAsync()
{
// Создаём CTS, который отменится через 5 минут
using CancellationTokenSource cts
= new(TimeSpan.FromMinutes(5));
// Передаём токен
await DoSomethingAsync(cts.Token);
// В конце метода CTS уничтожается
// Его токены не могут больше использоваться
}
Очистка
Чтобы избежать утечек ресурсов, важно уничтожать (dispose) экземпляры CancellationTokenSource. Очищается несколько видов ресурсов: во-первых, таймер тайм-аута (если он есть); во-вторых, все «слушатели», прикрепленные к токенам отмены. Эта очистка выполняется при отмене или уничтожении CancellationTokenSource. Вы должны убедиться, что либо одно, либо другое выполнено, чтобы избежать утечек ресурсов.
Если токен отмены сохраняется и используется позже, вы бы не хотели уничтожать CancellationTokenSource. В этом случае следует сохранять CancellationTokenSource активным до тех пор, пока вы не будете уверены, что весь код, использующий его токены, выполнен. Это более сложный случай, и иногда удобнее отменить CancellationTokenSource, а не уничтожать его.
Предупреждение: уничтожение связанных источников CancellationTokenSource.
Вызов Cancel или Dispose очистит все регистрации для конкретного CancellationTokenSource. Однако если этот CancellationTokenSource связан с «родительским» CancellationTokenSource, вызов Cancel для «дочернего» CancellationTokenSource приведёт к отмене регистрации в «родительском» CancellationTokenSource. Вы можете вызвать Dispose (или использовать оператор using) для «дочернего элемента», чтобы очистить регистрацию у родителя этого дочернего элемента, разрывая ссылку.
Эта и другие темы, касающиеся связанных CancellationTokenSource, будут рассмотрены далее в этой серии.
Источник: https://blog.stephencleary.com/2022/03/cancellation-2-requesting-cancellation.html
👍16
День 1994. #ЗаметкиНаПолях
Activator.CreateInstance(Type) Может Возвращать Null
Большинство людей ожидают, что этот метод вернет не-null объект, поскольку вы явно запрашиваете создание нового экземпляра, но это не всегда так. Для типов Nullable<T>
Заметьте, что такое же поведение наблюдается при использовании ключевого слова
Вы можете использовать null-снисходительный оператор (!), чтобы подавить предупреждение о том, что значение может быть
Источник: https://www.meziantou.net/activator-createinstance-type-may-return-null.htm
Activator.CreateInstance(Type) Может Возвращать Null
Activator.CreateInstance(Type) позволяет создать экземпляр типа, не зная тип во время компиляции. Например, вы можете захотеть создать экземпляр типа на основе файла конфигурации или ввода пользователя. Всегда, когда вы не можете использовать ключевое слово new, вы можете использовать Activator.CreateInstance(Type).Большинство людей ожидают, что этот метод вернет не-null объект, поскольку вы явно запрашиваете создание нового экземпляра, но это не всегда так. Для типов Nullable<T>
Activator.CreateInstance(Type) возвращает значение null.object? value = Activator.CreateInstance(typeof(int?));
Console.WriteLine(value is null); // true
Заметьте, что такое же поведение наблюдается при использовании ключевого слова
new:object? value = new int?();
Console.WriteLine(value is null); // true
Вы можете использовать null-снисходительный оператор (!), чтобы подавить предупреждение о том, что значение может быть
null, если вы уверены, что тип не может быть Nullable<T>:object? value = Activator.CreateInstance(typeof(object))!;
Console.WriteLine(value.GetHashCode());
Console.WriteLine(value is null); // всегда false
Источник: https://www.meziantou.net/activator-createinstance-type-may-return-null.htm
👍16
День 1995. #ЧтоНовенького
UUID Версии 7 в .NET 9
Спецификация UUID (универсальные уникальные идентификаторы), также известные как GUID (глобальные уникальные идентификаторы), определяет несколько различных версий UUID.
.NET использует UUID версии 4 в методе
Новый API по-прежнему находится внутри System.Guid:
Что аналогично:
Основным преимуществом является перегрузка с меткой времени, включенная в UUID. Вот как устроен UUID версии 7:
| 48-bit timestamp | 12-bit random | 62-bit random |
Длина осталась прежней, но первые 48 бит занимает метка времени. Основное преимущество заключается в том, что вы можете сортировать UUID по времени их создания, что делает их более подходящими для идентификаторов в базах данных, чем UUID версии 4.
Управление меткой времени
Поскольку метод принимает DateTimeOffset, вызывающая функция может использовать TimeProvider для управления UtcNow:
timeProvider можно внедрить через DI и эмулировать в сценариях тестирования.
Интересно, что внутренний код вызывает
Оригинальное предложение и дискуссия: https://github.com/dotnet/runtime/issues/103658
Источник: https://steven-giesel.com/blogPost/ea42a518-4d8b-4e08-8f73-e542bdd3b983/uuid-v7-in-net-9
UUID Версии 7 в .NET 9
Спецификация UUID (универсальные уникальные идентификаторы), также известные как GUID (глобальные уникальные идентификаторы), определяет несколько различных версий UUID.
.NET использует UUID версии 4 в методе
Guid.NewGuid(). Это, почти полностью случайное (или псевдослучайное) число. Но в превью 7 .NET 9 мы получим UUID версии 7.Новый API по-прежнему находится внутри System.Guid:
var guid = Guid.CreateVersion7();
Что аналогично:
var guid =
Guid.CreateVersion7(Guid.CreateVersion7(DateTimeOffset.UtcNow));
Основным преимуществом является перегрузка с меткой времени, включенная в UUID. Вот как устроен UUID версии 7:
| 48-bit timestamp | 12-bit random | 62-bit random |
Длина осталась прежней, но первые 48 бит занимает метка времени. Основное преимущество заключается в том, что вы можете сортировать UUID по времени их создания, что делает их более подходящими для идентификаторов в базах данных, чем UUID версии 4.
Управление меткой времени
Поскольку метод принимает DateTimeOffset, вызывающая функция может использовать TimeProvider для управления UtcNow:
var uuid = Guid.CreateVersion7(timeProvider.GetUtcNow());
timeProvider можно внедрить через DI и эмулировать в сценариях тестирования.
Интересно, что внутренний код вызывает
NewGuid(), а затем заменяет его первые байты на метку времени с помощью Unsafe.AsRef. Это делает CreateVersion7() примерно в 2 раза медленнее, чем NewGuid(), но это в любом случае десятки наносекунд.CreateVersion7 - довольно странное название метода, как по мне. Во-первых, оно какбэ намекает, что должны быть CreateVersion1, …, CreateVersion6, а их нет. А во-вторых, не соответствует методу NewGuid. То есть предполагается, что вы должны разбираться в версиях UUID, чтобы знать, какой версии UUID в NewGuid. Впрочем, возможно (и надеюсь), что к релизу .NET 9 метод переименуют.Оригинальное предложение и дискуссия: https://github.com/dotnet/runtime/issues/103658
Источник: https://steven-giesel.com/blogPost/ea42a518-4d8b-4e08-8f73-e542bdd3b983/uuid-v7-in-net-9
👍33
День 1996. #ЗаметкиНаПолях
Кастомизируем Swagger UI
Swagger — это набор инструментов для разработки, документирования и использования RESTful API. Он помогает разработчикам более эффективно проектировать, создавать, документировать и использовать API.
Swashbuckle — проект с открытым кодом, который интегрирует Swagger с приложениями .NET. По умолчанию при создании проекта API в Program.cs создаётся код, который добавляет поддержку Swagger вместе со Swagger UI.
Этот UI можно обогатить множеством вещей.
IDocumentFilter
С помощью этого интерфейса можно манипулировать и настраивать весь документ Swagger/OpenAPI перед его визуализацией или доставкой клиентам. Он обеспечивает возможность изменять, добавлять или удалять любую часть документа, например пути, операции, схемы и т. д.
Метод Apply предоставляет доступ к объекту OpenApiDocument, который представляет собой документ Swagger, и объекту DocumentFilterContext, который предоставляет дополнительный контекст и информацию.
Например, вам нужно удалить устаревшую конечную точку из Swagger UI, не удаляя её из кода. Если мы пометим какую-то конечную точку как устаревшую (Deprecated), это не скроет её из Swagger UI. Она будет просто перечёркнута и выделена серым цветом.
Добавим фильтр в Program.cs:
Теперь эта конечная точка не появится в Swagger UI.
Также можно добавить дополнительные метаданные ко всем (или избранным) конечным точкам. Например, добавление стандартного заголовка полезно для ограничения скорости, отслеживания запросов или любых других сквозных задач:
Источник: https://thecodeman.net/blog
Кастомизируем Swagger UI
Swagger — это набор инструментов для разработки, документирования и использования RESTful API. Он помогает разработчикам более эффективно проектировать, создавать, документировать и использовать API.
Swashbuckle — проект с открытым кодом, который интегрирует Swagger с приложениями .NET. По умолчанию при создании проекта API в Program.cs создаётся код, который добавляет поддержку Swagger вместе со Swagger UI.
builder.Services.AddSwaggerGen();
var app = builder.Build();
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
Этот UI можно обогатить множеством вещей.
IDocumentFilter
С помощью этого интерфейса можно манипулировать и настраивать весь документ Swagger/OpenAPI перед его визуализацией или доставкой клиентам. Он обеспечивает возможность изменять, добавлять или удалять любую часть документа, например пути, операции, схемы и т. д.
Метод Apply предоставляет доступ к объекту OpenApiDocument, который представляет собой документ Swagger, и объекту DocumentFilterContext, который предоставляет дополнительный контекст и информацию.
Например, вам нужно удалить устаревшую конечную точку из Swagger UI, не удаляя её из кода. Если мы пометим какую-то конечную точку как устаревшую (Deprecated), это не скроет её из Swagger UI. Она будет просто перечёркнута и выделена серым цветом.
public class RemoveObsoleteFilter : IDocumentFilter
{
public void Apply(
OpenApiDocument doc,
DocumentFilterContext ctx) {
var obsPaths = doc.Paths
.Where(p => p.Value.Operations
.Any(op => op.Value.Deprecated))
.Select(p => p.Key)
.ToList();
foreach (var path in obsPaths)
doc.Paths.Remove(path);
}
}
Добавим фильтр в Program.cs:
builder.Services.AddSwaggerGen(c =>
{
c.DocumentFilter<RemoveObsoleteFilter>();
});
Теперь эта конечная точка не появится в Swagger UI.
Также можно добавить дополнительные метаданные ко всем (или избранным) конечным точкам. Например, добавление стандартного заголовка полезно для ограничения скорости, отслеживания запросов или любых других сквозных задач:
public class CustomHeaderFilter : IDocumentFilter
{
public void Apply(
OpenApiDocument doc,
DocumentFilterContext ctx)
{
foreach (var path in doc.Paths.Values)
{
foreach (var op in path.Operations.Values)
{
foreach (var resp in op.Responses.Values)
{
resp.Headers ??=
new Dictionary<string, OpenApiHeader>();
resp.Headers
.Add("X-Custom-Header",
new OpenApiHeader
{
Description = "Custom header",
Schema = new OpenApiSchema
{
Type = "string"
}
});
}
}
}
}
}
Источник: https://thecodeman.net/blog
👍22
День 1997. #ЗаметкиНаПолях
Добавляем Аудит NuGet в Проекты .NET.
Аудит безопасности для менеджеров пакетов, таких как NuGet, является критически важным процессом для обеспечения безопасности программных проектов. В NuGet есть функция, которая вам поможет. Она может запустить аудит безопасности с помощью команды dotnet restore, которая сверяет ваши зависимости со списком известных уязвимостей из GitHub Advisory Database.
Если обнаружены уязвимости, вы можете обновить затронутые пакеты до более новой версии, содержащей исправления безопасности, или, если обновления недоступны, проверить, как обезопасить код или использовать альтернативный пакет.
Для аудита NuGet требуется .NET SDK 8.0.100 или более поздней версии. Чтобы включить аудит NuGet для ваших проектов .NET, добавьте в файл проекта следующие свойства:
Вы также можете проверить наличие уязвимостей в своих проектах с помощью команды
Если вы пока не можете устранить уязвимость, можно отключить предупреждение для каждого пакета, используя NoWarn в элементе PackageReference. Если ссылка транзитивная, можно добавить прямую ссылку на пакет с уязвимостью:
Если у вас глобально включены WarningsAsErrors в проекте, но вы не хотите такого поведения для уязвимостей, используйте WarningsNotAsErrors:
Источник: https://www.meziantou.net/enable-nuget-auditing-for-your-dotnet-projects.htm
Добавляем Аудит NuGet в Проекты .NET.
Аудит безопасности для менеджеров пакетов, таких как NuGet, является критически важным процессом для обеспечения безопасности программных проектов. В NuGet есть функция, которая вам поможет. Она может запустить аудит безопасности с помощью команды dotnet restore, которая сверяет ваши зависимости со списком известных уязвимостей из GitHub Advisory Database.
Если обнаружены уязвимости, вы можете обновить затронутые пакеты до более новой версии, содержащей исправления безопасности, или, если обновления недоступны, проверить, как обезопасить код или использовать альтернативный пакет.
Для аудита NuGet требуется .NET SDK 8.0.100 или более поздней версии. Чтобы включить аудит NuGet для ваших проектов .NET, добавьте в файл проекта следующие свойства:
<Project>
<PropertyGroup>
<NuGetAudit>true</NuGetAudit>
<!-- Прямые и транзитивные пакеты -->
<NuGetAuditMode>all</NuGetAuditMode>
<!-- Уровень уязвимостей для отчёта -->
<NuGetAuditLevel>low</NuGetAuditLevel>
<!-- Отменяем сборку в CI при обнаружении уязвимостей -->
<WarningsAsErrors Condition="$(ContinuousIntegrationBuild) == 'true' OR '$(Configuration)' == 'Release'">
(WarningsAsErrors);NU1900;NU1901;NU1902;NU1903;NU1904
</WarningsAsErrors>
</PropertyGroup>
</Project>
Вы также можете проверить наличие уязвимостей в своих проектах с помощью команды
dotnet list package --vulnerable.
Если вы пока не можете устранить уязвимость, можно отключить предупреждение для каждого пакета, используя NoWarn в элементе PackageReference. Если ссылка транзитивная, можно добавить прямую ссылку на пакет с уязвимостью:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="System.Formats.Asn1" Version="8.0.0" NoWarn="NU1903" />
<PackageReference Include="System.Text.Json" Version="8.0.1" />
</ItemGroup>
</Project>
Если у вас глобально включены WarningsAsErrors в проекте, но вы не хотите такого поведения для уязвимостей, используйте WarningsNotAsErrors:
<Project>
<PropertyGroup>
<WarningsNotAsErrors>NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors>
</PropertyGroup>
<Project>
Источник: https://www.meziantou.net/enable-nuget-auditing-for-your-dotnet-projects.htm
👍17
День 1998. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 16. Не задокументировав и не согласовав содержимое проекта, нельзя узнать, увеличивается ли его объём. Начало
Наверняка всем приходилось работать над проектом, который постепенно разбухал. Но был ли изначально чётко определён его объем?
Призрак разбухания проекта
Разбухание часто называют главной причиной того, почему реализация проекта не укладывается в запланированный график. Но вы не узнаете, имеет ли место разбухание проекта, если нет согласованной точки отсчёта: «Вот что мы намерены сделать в этот период времени».
Объём проекта можно определить как набор возможностей, с реализацией которого в конкретной итерации, сборке или выпуске продукта соглашаются заинтересованные стороны. Всякий запланированный этап работы начинается с базовой функциональности, которую команда должна реализовать на данном этапе. Это является отправной точкой, позволяющей определять изменение объёма.
Люди традиционно считают разбухание проекта чем-то плохим. Оно свидетельствует о том, что выявленные требования были неполными или неточными и это повлекло поток дополнительных требований. В любом крупном проекте невозможно заранее определить все требования, поэтому должны предполагаться изменение и рост количества требований по мере того, как пользователи пробуют ранние версии, получают новые идеи и лучше понимают задачу. Сдерживание изменений из-за боязни разбухания проекта может привести к созданию продуктов, которые не удовлетворяют все потребности клиентов. Но и непрерывное разбухание может навредить.
В Agile-проектах участники намеренно не пытаются выявить объём всего проекта и определяют объём каждой итерации. В список требований постоянно добавляются новые пункты. Владелец продукта расставляет приоритеты для новых требований с учетом ещё не реализованных, чтобы определить, какие из них должны быть реализованы в ближайших итерациях. Это помогает точно выявить потребности пользователей, но может привести к неопределённости времени доставки конечного продукта.
Как документировать объём
Простейший способ — перечислить функции, запланированные для реализации в следующем спринте. Другие способы:
- контекстная диаграмма, которая ничего не говорит о внутреннем устройстве системы, но идентифицирует пользователей, другие программы и устройства, которые подключаются к ней;
- диаграмма вариантов использования, изображающая действующих лиц за границами системы и варианты их взаимодействия с системой;
- диаграмма экосистемы, показывающая взаимосвязь нескольких систем, что позволяет оценить волновой эффект изменений в системах, которые не взаимодействуют напрямую с вашей;
- журнал реализации требований в итерации, содержащий набор требований, которые команда планирует завершить в течение одной итерации;
- карта пользовательских историй, показывающая детали пользовательских историй, определяющие объём всего продукта, итерации, конкретной функции и т.п.;
- дорожная карта функций, помогающая определить несколько уровней наращивания возможностей для каждой функции, а затем описать область применения конкретного выпуска и перечислить уровни расширения отдельных функций, добавленных в этот выпуск;
- дерево функций, визуально разбивающее основные функции на подфункции, которые планировщик может сгруппировать в целях определения объёма каждого цикла разработки;
- список событий, определяющий внешние события, которые будут обрабатываться при каждом выпуске.
В каждом случае цель определения объема состоит в том, чтобы выяснить, какие возможности должна предоставлять конкретная часть проекта. Выявление этих возможностей помогает установить границу области применения и задать точку отсчёта для рассмотрения изменений в этой области в процессе разработки.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.
Уроки 50 Лет Разработки ПО
Урок 16. Не задокументировав и не согласовав содержимое проекта, нельзя узнать, увеличивается ли его объём. Начало
Наверняка всем приходилось работать над проектом, который постепенно разбухал. Но был ли изначально чётко определён его объем?
Призрак разбухания проекта
Разбухание часто называют главной причиной того, почему реализация проекта не укладывается в запланированный график. Но вы не узнаете, имеет ли место разбухание проекта, если нет согласованной точки отсчёта: «Вот что мы намерены сделать в этот период времени».
Объём проекта можно определить как набор возможностей, с реализацией которого в конкретной итерации, сборке или выпуске продукта соглашаются заинтересованные стороны. Всякий запланированный этап работы начинается с базовой функциональности, которую команда должна реализовать на данном этапе. Это является отправной точкой, позволяющей определять изменение объёма.
Люди традиционно считают разбухание проекта чем-то плохим. Оно свидетельствует о том, что выявленные требования были неполными или неточными и это повлекло поток дополнительных требований. В любом крупном проекте невозможно заранее определить все требования, поэтому должны предполагаться изменение и рост количества требований по мере того, как пользователи пробуют ранние версии, получают новые идеи и лучше понимают задачу. Сдерживание изменений из-за боязни разбухания проекта может привести к созданию продуктов, которые не удовлетворяют все потребности клиентов. Но и непрерывное разбухание может навредить.
В Agile-проектах участники намеренно не пытаются выявить объём всего проекта и определяют объём каждой итерации. В список требований постоянно добавляются новые пункты. Владелец продукта расставляет приоритеты для новых требований с учетом ещё не реализованных, чтобы определить, какие из них должны быть реализованы в ближайших итерациях. Это помогает точно выявить потребности пользователей, но может привести к неопределённости времени доставки конечного продукта.
Как документировать объём
Простейший способ — перечислить функции, запланированные для реализации в следующем спринте. Другие способы:
- контекстная диаграмма, которая ничего не говорит о внутреннем устройстве системы, но идентифицирует пользователей, другие программы и устройства, которые подключаются к ней;
- диаграмма вариантов использования, изображающая действующих лиц за границами системы и варианты их взаимодействия с системой;
- диаграмма экосистемы, показывающая взаимосвязь нескольких систем, что позволяет оценить волновой эффект изменений в системах, которые не взаимодействуют напрямую с вашей;
- журнал реализации требований в итерации, содержащий набор требований, которые команда планирует завершить в течение одной итерации;
- карта пользовательских историй, показывающая детали пользовательских историй, определяющие объём всего продукта, итерации, конкретной функции и т.п.;
- дорожная карта функций, помогающая определить несколько уровней наращивания возможностей для каждой функции, а затем описать область применения конкретного выпуска и перечислить уровни расширения отдельных функций, добавленных в этот выпуск;
- дерево функций, визуально разбивающее основные функции на подфункции, которые планировщик может сгруппировать в целях определения объёма каждого цикла разработки;
- список событий, определяющий внешние события, которые будут обрабатываться при каждом выпуске.
В каждом случае цель определения объема состоит в том, чтобы выяснить, какие возможности должна предоставлять конкретная часть проекта. Выявление этих возможностей помогает установить границу области применения и задать точку отсчёта для рассмотрения изменений в этой области в процессе разработки.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.
👍10
День 1999. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 16. Не задокументировав и не согласовав содержимое проекта, нельзя узнать, увеличивается ли его объём. Окончание
Начало
Это входит в рамки проекта?
Поскольку объём так или иначе будет меняться, в каждом проекте должен быть определён практический процесс управления изменениями. Простое добавление требований в список без их анализа может только навредить. Формальный процесс внесения изменений не должен начинаться, пока команда не установит базовые границы определённого объёма работы. До этого момента требования и объём проекта динамично меняются. Во время выполнения каждого этапа работы контроль над изменениями должен становиться всё более строгим, чтобы повысить вероятность достижения базовых целей в соответствии с графиком.
Когда кто-то предлагает новое требование, следует задать вопрос: «Вписывается ли оно в объём?» Есть три возможных ответа.
1. Да, требование явно вписывается в рамки проекта. Предлагаемый функционал необходим для достижения целей в текущем цикле разработки. Поэтому мы должны добавить это требование в список.
2. Нет, требование явно выходит за рамки проекта. Оно не способствует достижению бизнес-целей в текущем цикле, поэтому его не нужно принимать в реализацию прямо сейчас, но можно рассмотреть в дальнейшем или отклонить.
3. Требование не вписывается в текущие рамки проекта, но относится к категории желательных. Спонсор проекта должен принять бизнес-решение: следует ли увеличивать объём проекта ради реализации новых возможностей. Если запрошенное изменение представляет определённую ценность для бизнеса, то правильным будет увеличить объём проекта. Но если объём увеличивается, придётся изменить и что-то ещё: сократить другие функции, изменить расписание, увеличить стоимость и т.п.
Расплывчатые требования = расплывчатый объём проекта
Расплывчатое описание требований чревато нечётким пониманием объёма проекта. Из-за двусмысленности одна сторона может думать, что определённая функция явно входит в рамки проекта, а другая – что нет. Расплывчатые термины, такие как «поддержка», «улучшение», «и т. д.», по сути являются неопределёнными.
Например: «Система должна поддерживать документы Microsoft Word». У читателей могут быть очень разные представления о том, какие именно функции подразумеваются под поддержкой. Владелец продукта строит планы на основе своей интерпретации слова «поддерживать», а позже обнаруживает, что клиент, запросивший эту функцию, имел гораздо более широкие ожидания. Это ведёт к разбуханию проекта? Или просто является уточнением первоначального ожидания? Тщательное описание требований перед принятием обязательств помогает избежать таких проблем.
Мудрые подрядчики предусматривают дополнительное время на разрешение непредвиденных обстоятельств, стараясь учесть возможность некоторого разбухания проекта и расплывчатости требований. Однако увеличение цены проекта, вызываемое такой предусмотрительностью, может оттолкнуть потенциального клиента. В контрактах должно быть чётко указано, как следует оценивать увеличение объёма работ и кто будет за это платить. Чем чётче вы определите, что включено, а что нет, тем легче будет впоследствии разрешить споры о реализованных и нереализованных функциях.
Итого
Изменения случаются, но чрезмерные изменения предполагают, что изначально никто не проработал задачу должным образом. Чёткое определение запланированного объёма работ позволяет команде сосредоточиться на создании ценного результата в рамках графика и бюджетных ограничений и принимать важные бизнес-решения, когда поступают запросы на изменение.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.
Уроки 50 Лет Разработки ПО
Урок 16. Не задокументировав и не согласовав содержимое проекта, нельзя узнать, увеличивается ли его объём. Окончание
Начало
Это входит в рамки проекта?
Поскольку объём так или иначе будет меняться, в каждом проекте должен быть определён практический процесс управления изменениями. Простое добавление требований в список без их анализа может только навредить. Формальный процесс внесения изменений не должен начинаться, пока команда не установит базовые границы определённого объёма работы. До этого момента требования и объём проекта динамично меняются. Во время выполнения каждого этапа работы контроль над изменениями должен становиться всё более строгим, чтобы повысить вероятность достижения базовых целей в соответствии с графиком.
Когда кто-то предлагает новое требование, следует задать вопрос: «Вписывается ли оно в объём?» Есть три возможных ответа.
1. Да, требование явно вписывается в рамки проекта. Предлагаемый функционал необходим для достижения целей в текущем цикле разработки. Поэтому мы должны добавить это требование в список.
2. Нет, требование явно выходит за рамки проекта. Оно не способствует достижению бизнес-целей в текущем цикле, поэтому его не нужно принимать в реализацию прямо сейчас, но можно рассмотреть в дальнейшем или отклонить.
3. Требование не вписывается в текущие рамки проекта, но относится к категории желательных. Спонсор проекта должен принять бизнес-решение: следует ли увеличивать объём проекта ради реализации новых возможностей. Если запрошенное изменение представляет определённую ценность для бизнеса, то правильным будет увеличить объём проекта. Но если объём увеличивается, придётся изменить и что-то ещё: сократить другие функции, изменить расписание, увеличить стоимость и т.п.
Расплывчатые требования = расплывчатый объём проекта
Расплывчатое описание требований чревато нечётким пониманием объёма проекта. Из-за двусмысленности одна сторона может думать, что определённая функция явно входит в рамки проекта, а другая – что нет. Расплывчатые термины, такие как «поддержка», «улучшение», «и т. д.», по сути являются неопределёнными.
Например: «Система должна поддерживать документы Microsoft Word». У читателей могут быть очень разные представления о том, какие именно функции подразумеваются под поддержкой. Владелец продукта строит планы на основе своей интерпретации слова «поддерживать», а позже обнаруживает, что клиент, запросивший эту функцию, имел гораздо более широкие ожидания. Это ведёт к разбуханию проекта? Или просто является уточнением первоначального ожидания? Тщательное описание требований перед принятием обязательств помогает избежать таких проблем.
Мудрые подрядчики предусматривают дополнительное время на разрешение непредвиденных обстоятельств, стараясь учесть возможность некоторого разбухания проекта и расплывчатости требований. Однако увеличение цены проекта, вызываемое такой предусмотрительностью, может оттолкнуть потенциального клиента. В контрактах должно быть чётко указано, как следует оценивать увеличение объёма работ и кто будет за это платить. Чем чётче вы определите, что включено, а что нет, тем легче будет впоследствии разрешить споры о реализованных и нереализованных функциях.
Итого
Изменения случаются, но чрезмерные изменения предполагают, что изначально никто не проработал задачу должным образом. Чёткое определение запланированного объёма работ позволяет команде сосредоточиться на создании ценного результата в рамках графика и бюджетных ограничений и принимать важные бизнес-решения, когда поступают запросы на изменение.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.
👍3
День 2000.
Вот добрался до очередного юбилея. А вас почти 5,2К. Это немного, ноэто честная работа ценю каждого и стараюсь для каждого.
Напоминаю, что вот здесь подборка тегов, по которым можно искать интересующие темы. Кроме того, можно и простым поиском найти интересующую информацию. За 2000 дней много всего скопилось. А если не нашли, не стесняйтесь спросить в нашем чате.
Спасибо, что читаете, ещё больше спасибо, что лайкаете, комментируете и шерите. А если вдруг кто захочет поддержать, можно это сделать на Boosty, Patreon или просто закинуть напивко кофе.
Вот добрался до очередного юбилея. А вас почти 5,2К. Это немного, но
Напоминаю, что вот здесь подборка тегов, по которым можно искать интересующие темы. Кроме того, можно и простым поиском найти интересующую информацию. За 2000 дней много всего скопилось. А если не нашли, не стесняйтесь спросить в нашем чате.
Спасибо, что читаете, ещё больше спасибо, что лайкаете, комментируете и шерите. А если вдруг кто захочет поддержать, можно это сделать на Boosty, Patreon или просто закинуть на
👍83
День 2001. #ЗаметкиНаПолях #Cancellation
Отмена. Часть 3: Обнаружение Отмены. Начало
Нередко возникает желание определить, действительно ли запрос на отмену что-то отменил. Отмена – это скоординированная операция, и иногда коду, запрашивающему отмену, необходимо знать, действительно ли отмена имела место или операция просто завершилась нормально.
В контракте отмены есть способ сообщить об этом: методы, принимающие CancellationToken, по соглашению должны выдавать исключение OperationCanceledException при их отмене. Это верно для всех методов BCL и должно быть так и в вашем коде.
Ответ на отмену
Самый распространённый сценарий обнаружения отмены — не обрабатывать исключение при отмене. Обычно исключение OperationCanceledException просто игнорируется:
Код выше обработает непредвиденные ошибки, но проигнорирует исключения отмены.
Если код должен сделать что-то другое при отмене, можно обработать это в блоке catch:
Однако подумайте, действительно ли вам нужно это делать, потому что это редкий случай, вызывает вопросы по логике кода, а также такой код сложно тестировать.
Окончание следует…
Источник: https://blog.stephencleary.com/2022/03/cancellation-3-detecting-cancellation.html
Отмена. Часть 3: Обнаружение Отмены. Начало
Нередко возникает желание определить, действительно ли запрос на отмену что-то отменил. Отмена – это скоординированная операция, и иногда коду, запрашивающему отмену, необходимо знать, действительно ли отмена имела место или операция просто завершилась нормально.
В контракте отмены есть способ сообщить об этом: методы, принимающие CancellationToken, по соглашению должны выдавать исключение OperationCanceledException при их отмене. Это верно для всех методов BCL и должно быть так и в вашем коде.
Ответ на отмену
Самый распространённый сценарий обнаружения отмены — не обрабатывать исключение при отмене. Обычно исключение OperationCanceledException просто игнорируется:
async Task TryDoSomethingAsync()
{
using CancellationTokenSource cts = new();
// Создаём что-то, что может отменять cts
try
{
await DoAsync(cts.Token);
}
catch (Exception ex) when
(ex is not OperationCanceledException)
{
// Обработка исключения
}
}
Код выше обработает непредвиденные ошибки, но проигнорирует исключения отмены.
Если код должен сделать что-то другое при отмене, можно обработать это в блоке catch:
async Task DoSomethingAsync()
{
using CancellationTokenSource cts = new();
// Создаём что-то, что может отменять cts
try
{
await DoAsync(cts.Token);
}
catch (OperationCanceledException)
{
// Обработка отмены
}
catch (Exception ex)
{
// Обработка исключения
}
}
Однако подумайте, действительно ли вам нужно это делать, потому что это редкий случай, вызывает вопросы по логике кода, а также такой код сложно тестировать.
Окончание следует…
Источник: https://blog.stephencleary.com/2022/03/cancellation-3-detecting-cancellation.html
👍8
День 2002. #ЗаметкиНаПолях #Cancellation
Отмена. Часть 3: Обнаружение Отмены. Окончание
Начало
TaskCanceledException
Существует ещё один тип исключения для отмены: TaskCanceledException. Он выбрасывается некоторыми API вместо OperationCanceledException.
Как правило, рекомендуется не использовать TaskCanceledException. Некоторые API просто вызывают OperationCanceledException, даже если они имеют дело с отменёнными задачами. А поскольку TaskCanceledException является производным от OperationCanceledException, код обработчика исключений отмены может просто перехватывать OperationCanceledException, игнорировать TaskCanceledException, и это будет работать везде.
Внимание: не перехватывайте TaskCanceledException. Вместо этого перехватывайте OperationCanceledException.
OperationCanceledException.CancellationToken
OperationCanceledException имеет свойство CancellationToken. Это токен, вызвавший отмену. Это в том случае, если он установлен. Не все API устанавливают это значение для выбрасываемых ими исключений.
Если вашему коду необходимо определить, отменяет ли операцию он сам или это делает какой-то другой код, у вас может возникнуть соблазн использовать это свойство. Но лучше игнорировать его. Когда используются связанные токены отмены (об этом далее в этой серии), вполне возможно, что токен в этом свойстве на самом деле не является основной причиной отмены:
В коде выше есть проблема: в зависимости от реализации DoAsync возможно, что отмена cts приведёт к тому, что DoAsync выдаст исключение OperationCanceledException, но токен, на который ссылается это исключение, будет отличаться от токена cts.
Если вам действительно необходимо выполнить специальную обработку случая, когда происходит отмена через конкретный токен, попробуйте что-то вроде этого:
Технически, здесь мы проверяем не «привёл ли мой токен к отмене операции», а скорее «произошла ли отмена и запрашивал ли мой токен отмену». Но в подавляющем большинстве случаев такой проверки достаточно.
Внимание: не используйте OperationCanceledException.CancellationToken. Он может работать не так, как вы ожидаете.
Источник: https://blog.stephencleary.com/2022/03/cancellation-3-detecting-cancellation.html
Отмена. Часть 3: Обнаружение Отмены. Окончание
Начало
TaskCanceledException
Существует ещё один тип исключения для отмены: TaskCanceledException. Он выбрасывается некоторыми API вместо OperationCanceledException.
Как правило, рекомендуется не использовать TaskCanceledException. Некоторые API просто вызывают OperationCanceledException, даже если они имеют дело с отменёнными задачами. А поскольку TaskCanceledException является производным от OperationCanceledException, код обработчика исключений отмены может просто перехватывать OperationCanceledException, игнорировать TaskCanceledException, и это будет работать везде.
Внимание: не перехватывайте TaskCanceledException. Вместо этого перехватывайте OperationCanceledException.
OperationCanceledException.CancellationToken
OperationCanceledException имеет свойство CancellationToken. Это токен, вызвавший отмену. Это в том случае, если он установлен. Не все API устанавливают это значение для выбрасываемых ими исключений.
Если вашему коду необходимо определить, отменяет ли операцию он сам или это делает какой-то другой код, у вас может возникнуть соблазн использовать это свойство. Но лучше игнорировать его. Когда используются связанные токены отмены (об этом далее в этой серии), вполне возможно, что токен в этом свойстве на самом деле не является основной причиной отмены:
async Task DoSomethingAsync()
{
// Плохой код, не делайте так
using CancellationTokenSource cts = new();
// Создаём что-то, что может отменять cts
try
{
await DoAsync(cts.Token);
}
catch (OperationCanceledException ex)
when (ex.CancellationToken == cts.Token)
{
// Обработка отмены «нашим» токеном
}
}
В коде выше есть проблема: в зависимости от реализации DoAsync возможно, что отмена cts приведёт к тому, что DoAsync выдаст исключение OperationCanceledException, но токен, на который ссылается это исключение, будет отличаться от токена cts.
Если вам действительно необходимо выполнить специальную обработку случая, когда происходит отмена через конкретный токен, попробуйте что-то вроде этого:
async Task DoSomethingAsync()
{
using CancellationTokenSource cts = new();
// Создаём что-то, что может отменять cts
try
{
await DoAsync(cts.Token);
}
catch (OperationCanceledException ex)
when (cts.IsCancellationRequested)
{
// Обработка отмены «нашим» токеном
}
}
Технически, здесь мы проверяем не «привёл ли мой токен к отмене операции», а скорее «произошла ли отмена и запрашивал ли мой токен отмену». Но в подавляющем большинстве случаев такой проверки достаточно.
Внимание: не используйте OperationCanceledException.CancellationToken. Он может работать не так, как вы ожидаете.
Источник: https://blog.stephencleary.com/2022/03/cancellation-3-detecting-cancellation.html
👍12
День 2003. #ЧтоНовенького #CSharp13
Regex.EnumerateSplits
В 6м превью .NET 9 представлен новый метод класса Regex, который позволяет разбивать входные данные по шаблону без выделения памяти.
Класс Regex предоставляет метод Split, по концепции аналогичный методу String.Split. С помощью String.Split вы предоставляете один или несколько разделителей (символов или строк), и реализация разбивает входной текст по этим разделителям. Вот пример использования String.Split:
который выводит:
Regex предоставляет аналогичный метод Split, но вместо указания разделителя в виде символа или строки он указывается как шаблон регулярного выражения:
Вывод:
Однако Regex.Split принимает в качестве входных данных только строки и не поддерживает входные данные в виде ReadOnlySpan<char>, а также выводит полный набор результатов в виде массива строк, что требует выделения как массива строк для хранения результатов, так и выделения строк для каждого результата. В .NET 9 новый метод EnumerateSplits позволяет выполнять ту же операцию, но с входными данными в виде ReadOnlySpan<char> и без какого-либо выделения памяти. Он принимает ReadOnlySpan<char> и возвращает перечислитель (ValueSplitEnumerator) результатов в виде диапазона (Range). В следующем примере показано использование Regex.EnumerateSplits:
Вывод будет такой же, как в предыдущем примере, но без выделения памяти. Здесь r – диапазон, например, {0..1} для первого результата, и на консоль выводится срез входных данных, соответствующий диапазону (это результат типа ReadOnlySpan<char>, поэтому он помещён в интерполированную строку для использования в Console.WriteLine.
Источник: https://github.com/dotnet/core/blob/main/release-notes/9.0/preview/preview6/libraries.md
Regex.EnumerateSplits
В 6м превью .NET 9 представлен новый метод класса Regex, который позволяет разбивать входные данные по шаблону без выделения памяти.
Класс Regex предоставляет метод Split, по концепции аналогичный методу String.Split. С помощью String.Split вы предоставляете один или несколько разделителей (символов или строк), и реализация разбивает входной текст по этим разделителям. Вот пример использования String.Split:
foreach (var s in "Hello, world! How are you?".Split('w'))
{
Console.WriteLine(s);
}который выводит:
Hello,
orld! Ho
are you?
Regex предоставляет аналогичный метод Split, но вместо указания разделителя в виде символа или строки он указывается как шаблон регулярного выражения:
foreach (var s in Regex.Split(
"Hello, world! How are you?", "[aeiou]"))
{
Console.WriteLine(s);
}
Вывод:
H
ll
, w
rld! H
w
r
y
?
Однако Regex.Split принимает в качестве входных данных только строки и не поддерживает входные данные в виде ReadOnlySpan<char>, а также выводит полный набор результатов в виде массива строк, что требует выделения как массива строк для хранения результатов, так и выделения строк для каждого результата. В .NET 9 новый метод EnumerateSplits позволяет выполнять ту же операцию, но с входными данными в виде ReadOnlySpan<char> и без какого-либо выделения памяти. Он принимает ReadOnlySpan<char> и возвращает перечислитель (ValueSplitEnumerator) результатов в виде диапазона (Range). В следующем примере показано использование Regex.EnumerateSplits:
ReadOnlySpan<char> input =
"Hello, world! How are you?";
foreach (Range r in
Regex.EnumerateSplits(input, "[aeiou]"))
{
Console.WriteLine($"{input[r]}");
}
Вывод будет такой же, как в предыдущем примере, но без выделения памяти. Здесь r – диапазон, например, {0..1} для первого результата, и на консоль выводится срез входных данных, соответствующий диапазону (это результат типа ReadOnlySpan<char>, поэтому он помещён в интерполированную строку для использования в Console.WriteLine.
Источник: https://github.com/dotnet/core/blob/main/release-notes/9.0/preview/preview6/libraries.md
👍21
День 2004. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Проектирование. Начало
Если цель выявления требований состоит в определении характеристик, которыми должны обладать решения, то суть проектирования — в разработке этих решений. Однако между требованиями и проектным решением не чёткая граница, а размытая серая зона. Во время исследования требований полезно предпринять некоторые предварительные действия в области проектирования, например создать прототипы. Пользователи, взаимодействующие с прототипом, часто замечают, что это проясняет их мышление и способствует появлению новых идей, поскольку прототип более осязаем, чем абстрактный список требований.
Суть проектирования ПО в том, чтобы связать требования с фрагментами кода, но переход даже от чётко описанных требований к конкретным элементам проектного решения не является ни простым, ни очевидным. Одни виды деятельности, например проектирование БД, носят систематический и аналитический характер. Другие более органичны: проектное решение выкристаллизовывается постепенно, по мере того как разработчики исследуют переход от задачи к решению. А проектирование UX/UI включает художественно-творческие подходы, основанные на глубоком понимании человеческого фактора.
Виды проектирования ПО
- архитектурное,
- техническое (низкоуровневое),
- проектирование БД,
- проектирование UX/UI.
В каждом есть многочисленные ограничения: требования совместимости с другими продуктами, применимые стандарты, технологические ограничения, бизнес-политики и правила, ограничения по стоимости и ресурсам и т.п. Ограничения усложняют проектирование, сообщая разработчикам, чего они не могут делать, точно так же как требования диктуют, что должна делать реализация.
1. Архитектурное проектирование
Определяет структуру системы и её компоненты, или архитектурные элементы. Элементы состоят из модулей кода, которые могут быть объединены в несколько взаимосвязанных подсистем в крупном продукте. Архитектурное проектирование предусматривает разделение системы на компоненты, определение обязанностей каждого компонента и назначение конкретных требований соответствующим компонентам, а также определение интерфейсов между компонентами.
2. Техническое проектирование
Проработка логической структуры отдельных компонентов (модулей, классов и их методов, сценариев и т. д.) и деталей интерфейсов между модулями, разработка алгоритмов.
3. Проектирование БД
На этом этапе определяются сущности и отношения между ними, а также элементы данных каждой сущности, их типы, свойства и логические связи, определяются CRUD (create, read, update, delete) процедуры.
4. Проектирование UX/UI
Проектирование пользовательского опыта само по себе является обширной дисциплиной. Архитектура пользовательского интерфейса определяет диалоговые элементы (точки взаимодействия пользователя с системой) и пути навигации между ними, повторяющие сценарии решения пользовательских задач. При техническом проектировании UI учитывается специфика взаимодействий пользователя с продуктом, в том числе продумываются эскизы экрана, внешний вид, элементы управления и свойства отдельных текстовых блоков, графики, поля ввода и экраны вывода результатов. Оба этапа проектирования UI — архитектурное и техническое — определяют воспринимаемую пользователем простоту обучения и использования или в совокупности — удобство использования (UX).
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 3.
Уроки 50 Лет Разработки ПО
Проектирование. Начало
Если цель выявления требований состоит в определении характеристик, которыми должны обладать решения, то суть проектирования — в разработке этих решений. Однако между требованиями и проектным решением не чёткая граница, а размытая серая зона. Во время исследования требований полезно предпринять некоторые предварительные действия в области проектирования, например создать прототипы. Пользователи, взаимодействующие с прототипом, часто замечают, что это проясняет их мышление и способствует появлению новых идей, поскольку прототип более осязаем, чем абстрактный список требований.
Суть проектирования ПО в том, чтобы связать требования с фрагментами кода, но переход даже от чётко описанных требований к конкретным элементам проектного решения не является ни простым, ни очевидным. Одни виды деятельности, например проектирование БД, носят систематический и аналитический характер. Другие более органичны: проектное решение выкристаллизовывается постепенно, по мере того как разработчики исследуют переход от задачи к решению. А проектирование UX/UI включает художественно-творческие подходы, основанные на глубоком понимании человеческого фактора.
Виды проектирования ПО
- архитектурное,
- техническое (низкоуровневое),
- проектирование БД,
- проектирование UX/UI.
В каждом есть многочисленные ограничения: требования совместимости с другими продуктами, применимые стандарты, технологические ограничения, бизнес-политики и правила, ограничения по стоимости и ресурсам и т.п. Ограничения усложняют проектирование, сообщая разработчикам, чего они не могут делать, точно так же как требования диктуют, что должна делать реализация.
1. Архитектурное проектирование
Определяет структуру системы и её компоненты, или архитектурные элементы. Элементы состоят из модулей кода, которые могут быть объединены в несколько взаимосвязанных подсистем в крупном продукте. Архитектурное проектирование предусматривает разделение системы на компоненты, определение обязанностей каждого компонента и назначение конкретных требований соответствующим компонентам, а также определение интерфейсов между компонентами.
2. Техническое проектирование
Проработка логической структуры отдельных компонентов (модулей, классов и их методов, сценариев и т. д.) и деталей интерфейсов между модулями, разработка алгоритмов.
3. Проектирование БД
На этом этапе определяются сущности и отношения между ними, а также элементы данных каждой сущности, их типы, свойства и логические связи, определяются CRUD (create, read, update, delete) процедуры.
4. Проектирование UX/UI
Проектирование пользовательского опыта само по себе является обширной дисциплиной. Архитектура пользовательского интерфейса определяет диалоговые элементы (точки взаимодействия пользователя с системой) и пути навигации между ними, повторяющие сценарии решения пользовательских задач. При техническом проектировании UI учитывается специфика взаимодействий пользователя с продуктом, в том числе продумываются эскизы экрана, внешний вид, элементы управления и свойства отдельных текстовых блоков, графики, поля ввода и экраны вывода результатов. Оба этапа проектирования UI — архитектурное и техническое — определяют воспринимаемую пользователем простоту обучения и использования или в совокупности — удобство использования (UX).
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 3.
👍2
День 2004. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Проектирование. Окончание
Начало
У вас хороший проект?
Проектирование предполагает разработку оптимального решения, которое будет соответствовать множеству требований в течение всего срока службы продукта. Проектное решение должно позволять реализовать правильную функциональность и достичь ожидаемых характеристик всех атрибутов качества. Кроме того, проектное решение должно эффективно обеспечивать расширение и изменение как в процессе разработки, так и после выпуска.
Соблюдение принципов, изложенных ниже, способствует уменьшению сложности проектного решения, повышению его надёжности и упрощению понимания, изменения, расширения и повторного использования.
1. Разделение обязанностей
Проект должен быть разделён на модули, независимые друг от друга и имеющие чётко определённые и не пересекающиеся обязанности.
2. Сокрытие информации
Каждый модуль должен скрывать внутренние детали своих данных и алгоритмов от остальной системы. Другие модули должны получать доступ к данным и сервисам модуля только через чётко определённый интерфейс. В этом случае реализацию каждого модуля можно изменить при необходимости, не затрагивая другие модули, которые его вызывают.
3. Слабая связанность
Хорошо продуманный модульный проект демонстрирует слабую связанность между компонентами, поэтому изменение одного модуля требует минимальных изменений других.
4. Сильная связность
Модуль, для которого характерна сильная связность, идеально выполняет одну чётко определённую задачу.
5. Абстракция
Позволяет разработчикам писать код, не зависящий от конкретных деталей реализации, таких как тип ОС или UI. Абстракция упрощает переносимость и повторное использование.
6. Чётко определённые и удобные интерфейсы
Позволяют разработчикам других модулей легко обращаться к сервисам данного модуля, а также упрощают замену модуля, когда это необходимо, поскольку интерфейс, который он предоставляет остальной части системы, остаётся неизменным. Тот же принцип применяется к внешним интерфейсам, которые система предоставляет вовне.
Не спешите переходить от требований сразу к коду. Найдите время, оцените альтернативные варианты проектного решения и выберите наиболее подходящее.
Первые шаги
1. Перечислите приёмы проектирования, в которых особенно преуспела ваша организация. Задокументирована ли информация об этих приёмах? Доступна ли она другим членам команды, чтобы они могли ознакомиться с ними и применять на практике?
2. Определите любые проблемы, отмечавшиеся в команде и связанные с архитектурным, техническим проектированием, проектированием БД и UX.
3. Опишите, как каждая проблема влияет на вашу способность успешно завершать проекты. Как они мешают достижению успеха разработчикам и клиентам? Огрехи в проектном решении могут привести к снижению надёжности системы, что нелегко исправить, низкой производительности, дублированию кода, несоответствиям внутри продукта или между связанными продуктами и к проблемам с удобством использования.
4. Для каждой проблемы, определите основные причины, провоцирующие или усугубляющие её. Вы можете найти несколько основных причин, способствующих появлению одной и той же проблемы, или несколько проблем, обусловленных одной общей причиной.
5. Изучая лучшие практики проектирования, отмечайте, как они могут быть полезны вашей команде.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 3.
Уроки 50 Лет Разработки ПО
Проектирование. Окончание
Начало
У вас хороший проект?
Проектирование предполагает разработку оптимального решения, которое будет соответствовать множеству требований в течение всего срока службы продукта. Проектное решение должно позволять реализовать правильную функциональность и достичь ожидаемых характеристик всех атрибутов качества. Кроме того, проектное решение должно эффективно обеспечивать расширение и изменение как в процессе разработки, так и после выпуска.
Соблюдение принципов, изложенных ниже, способствует уменьшению сложности проектного решения, повышению его надёжности и упрощению понимания, изменения, расширения и повторного использования.
1. Разделение обязанностей
Проект должен быть разделён на модули, независимые друг от друга и имеющие чётко определённые и не пересекающиеся обязанности.
2. Сокрытие информации
Каждый модуль должен скрывать внутренние детали своих данных и алгоритмов от остальной системы. Другие модули должны получать доступ к данным и сервисам модуля только через чётко определённый интерфейс. В этом случае реализацию каждого модуля можно изменить при необходимости, не затрагивая другие модули, которые его вызывают.
3. Слабая связанность
Хорошо продуманный модульный проект демонстрирует слабую связанность между компонентами, поэтому изменение одного модуля требует минимальных изменений других.
4. Сильная связность
Модуль, для которого характерна сильная связность, идеально выполняет одну чётко определённую задачу.
5. Абстракция
Позволяет разработчикам писать код, не зависящий от конкретных деталей реализации, таких как тип ОС или UI. Абстракция упрощает переносимость и повторное использование.
6. Чётко определённые и удобные интерфейсы
Позволяют разработчикам других модулей легко обращаться к сервисам данного модуля, а также упрощают замену модуля, когда это необходимо, поскольку интерфейс, который он предоставляет остальной части системы, остаётся неизменным. Тот же принцип применяется к внешним интерфейсам, которые система предоставляет вовне.
Не спешите переходить от требований сразу к коду. Найдите время, оцените альтернативные варианты проектного решения и выберите наиболее подходящее.
Первые шаги
1. Перечислите приёмы проектирования, в которых особенно преуспела ваша организация. Задокументирована ли информация об этих приёмах? Доступна ли она другим членам команды, чтобы они могли ознакомиться с ними и применять на практике?
2. Определите любые проблемы, отмечавшиеся в команде и связанные с архитектурным, техническим проектированием, проектированием БД и UX.
3. Опишите, как каждая проблема влияет на вашу способность успешно завершать проекты. Как они мешают достижению успеха разработчикам и клиентам? Огрехи в проектном решении могут привести к снижению надёжности системы, что нелегко исправить, низкой производительности, дублированию кода, несоответствиям внутри продукта или между связанными продуктами и к проблемам с удобством использования.
4. Для каждой проблемы, определите основные причины, провоцирующие или усугубляющие её. Вы можете найти несколько основных причин, способствующих появлению одной и той же проблемы, или несколько проблем, обусловленных одной общей причиной.
5. Изучая лучшие практики проектирования, отмечайте, как они могут быть полезны вашей команде.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 3.
👍8
Техника работодателя и работа на ней... #холивар
(С)тянуто из соседнего чатика, надеюсь, там поймут и простят.
(С)тянуто из соседнего чатика, надеюсь, там поймут и простят.
Anonymous Poll
32%
Работодатель обязан предоставить хорошую технику в любом случае
23%
Работодатель обязан предоставить технику хотя бы в офисе (на удалёнке, так и быть, буду на своей)
12%
Если работодатель даст, могу работать на ней, если нет, буду на своей
27%
Если работодатель требует уснавку ВПН, и прочих трекеров, пусть даёт технику
5%
То, что предлагают работодатели, меня не устраивает, работаю только на своей технике
1%
Свой вариант (напишу в комментариях)
День 2006. #HotKeys
Горячие Клавиши Visual Studio
Давным-давно на канале уже были подобные посты, но не грех и повторить. Тем более, что в IDE появились новые функции.
Управляем буфером обмена
В Visual Studio есть буфер обмена, куда можно копировать несколько значений, и вставлять их через Ctrl+Shift+V, однако в Windows есть свой буфер, куда можно копировать как обычно через
Вырезать целую строку, не выделяя весь текст в ней, можно просто поставив курсор на строку и нажав
Редактирование
Навигация
Для ASP.NET:
Рефакторинг
Скрипты
"prop",
"ctor",
Также
Отладка
Какие горячие клавиши вы чаще всего используете? Добавляйте в комментарии.
Горячие Клавиши Visual Studio
Давным-давно на канале уже были подобные посты, но не грех и повторить. Тем более, что в IDE появились новые функции.
Управляем буфером обмена
В Visual Studio есть буфер обмена, куда можно копировать несколько значений, и вставлять их через Ctrl+Shift+V, однако в Windows есть свой буфер, куда можно копировать как обычно через
Ctrl+C, и вставлять несколько значений в любое приложение с помощью Win+V. Что удобнее – решать вам.Вырезать целую строку, не выделяя весь текст в ней, можно просто поставив курсор на строку и нажав
Ctrl+L (хотя у меня работает и Ctrl+X). В обоих случаях строка будет вырезана в буфер обмена. Просто удалить строку, не добавляя её в буфер обмена можно с помощью Ctrl+Shift+L.Редактирование
Ctrl+K,C – закомментировать строку,Ctrl+K,U – раскомментировать строку,Ctrl+D – продублировать строку,Ctrl+K,F – отформатировать выделенный блок,Ctrl+K,D – отформатировать весь файл,Ctrl+K,E – очистка кода в файле (по заданным вами правилам, например, удаление ненужных using),Ctrl+K,S – вставка скрипта (блок if, try, for и т.п.), либо заключить выделенный код в блок.Alt+<стрелки вверх/вниз> - переместить строку вверх/вниз,Alt+Shift+<стрелки> (Alt+<выделение мышью>) - редактирование по колонкам,Ctrl+Alt+<поместить курсор мышью> - многокурсорный ввод (редактирование в нескольких местах одновременно).Навигация
Ctrl+G – перейти к линии,Ctrl+K,K – оставить закладку,Ctrl+K,N – перейти к следующей закладке,Ctrl+, (Ctrl+T) - поиск по коду в проекте,Ctrl+Q – поиск по инструментам IDE,F12 (Ctrl+щелчок мыши) – перейти к определению,Ctrl+F12 – перейти к реализации,Alt+F12 – подсказка реализации во всплывающем окне,Shift+F12 – найти использования,Ctrl+Shift+пробел – подсказка по аргументам метода,Ctrl+[,X (Ctrl+Alt+L) – отметить текущий файл в обозревателе решения,Ctrl+; - поиск в обозревателе решения,Ctrl+M,O - свернуть все методы,Ctrl+M,P - развернуть все методы,Ctrl+M,M – свернуть/развернуть текущий метод.Для ASP.NET:
Ctrl+M,G – перейти из метода контроллера в представление или наоборот.Рефакторинг
Ctrl+. (Alt+Enter) – подсказки рефакторинга,Ctrl+R,R – переименовать,Ctrl+R,M – извлечь выделенный код в метод,Ctrl+R,I - извлечь интерфейс из класса,Ctrl+R,V (Ctrl+R,O) - реорганизовать параметры метода.Скрипты
"prop",
Tab,Tab – создать свойство,"ctor",
Tab,Tab – создать конструктор,Также
Tab,Tab работает для других популярных ключевых слов (if, for, switch и т.п.)Отладка
F9 – создать точку останова,Ctrl+Alt+B – окно со всеми точками останова,Ctrl+Shift+F9 – удалить все точки останова.Какие горячие клавиши вы чаще всего используете? Добавляйте в комментарии.
👍29👎1
День 2007. #ЗаметкиНаПолях
Остановка PowerShell Скрипта при Ошибке
По умолчанию PowerShell не останавливает скрипт при возникновении ошибки. Вместо этого он записывает ошибку в поток ошибок и продолжает выполнение скрипта. Вы можете изменить это поведение, установив переменную
PowerShell имеет два разных вида команд: командлеты (cmdlet) и нативные команды. Например,
Если задать
Можно переопределить поведение
Чтобы обойти поведение
Источник: https://www.meziantou.net/stop-the-script-when-an-error-occurs-in-powershell.htm
Остановка PowerShell Скрипта при Ошибке
По умолчанию PowerShell не останавливает скрипт при возникновении ошибки. Вместо этого он записывает ошибку в поток ошибок и продолжает выполнение скрипта. Вы можете изменить это поведение, установив переменную
$ErrorActionPreference в значение Stop. Тогда PowerShell остановит скрипт при возникновении ошибки.PowerShell имеет два разных вида команд: командлеты (cmdlet) и нативные команды. Например,
Get-ChildItem — это командлет, а git — нативная команда. Начиная с первой версии PowerShell, переменная $ErrorActionPreference управляла поведением только командлетов. В PowerShell 7.3 была введена переменная $PSNativeCommandUseErrorActionPreference для управления поведением нативных команд.Если задать
$ErrorActionPreference значение Stop, PowerShell остановит скрипт, когда командлет выдаст ошибку. Если задать $PSNativeCommandUseErrorActionPreference в значение true, PowerShell также остановит скрипт, когда нативная команда выдаст ошибку. Хорошей практикой будет установить обе переменные в начале скрипта:# Остановить скрипт при ошибке
$ErrorActionPreference = 'Stop'
$PSNativeCommandUseErrorActionPreference = $true
Можно переопределить поведение
$ErrorActionPreference для каждого командлета, используя параметр -ErrorAction. Например, следующая команда не останавливает скрипт, если Get-ChildItem завершится с ошибкой:Get-ChildItem dummy -ErrorAction SilentlyContinue
Чтобы обойти поведение
$PSNativeCommandUseErrorActionPreference для определённой нативной команды, вы можете использовать синтаксис & { } для запуска команды внутри блока скрипта. Внутри блока скрипта вы можете изменить значение $PSNativeCommandUseErrorActionPreference на false. Когда блок скрипта завершается, переменная возвращается к своему предыдущему значению.& {
# Изменяем $PSNativeCommandUseErrorActionPreference в этом блоке
$PSNativeCommandUseErrorActionPreference = $false
robocopy.exe dummy1 dummy2
if ($LASTEXITCODE -gt 8) {
throw "robocopy failed with exit code $LASTEXITCODE"
}
}Источник: https://www.meziantou.net/stop-the-script-when-an-error-occurs-in-powershell.htm
👍17
День 2008. #ЗаметкиНаПолях #Cancellation
Отмена. Часть 4: Проверка отмены
В большинстве случаев получаемый токен отмены просто передаётся на более низкий уровень. Но если нужен отменяемый код на самом низком уровне, есть несколько вариантов.
Обычный шаблон — периодически вызывать ThrowIfCancellationRequested:
В коде выше проверяется токен отмены до начала работы, что является хорошей практикой. Возможно, токен уже отменён к моменту начала выполнения вашей операции.
ThrowIfCancellationRequested проверит, запрошена ли отмена, и если да, то выдаст OperationCanceledException. Ваш код должен просто позволить этому исключению распространиться из метода.
Главный вопрос — как часто проверять. На него нет хорошего ответа; в идеале - несколько раз в секунду, но в общем случае - просто поместите его в лучшее место(а) и запустите несколько тестов, чтобы увидеть, достаточно ли отзывчива отмена.
Как не делать проверку
Существует антишаблон пулинга на предмет отмены в бесконечном цикле:
Код будет периодически проверять токен отмены; и при отмене происходит выход из метода. Этот метод не удовлетворяет контракту отмены, требующему выбрасывать исключение при отмене. Т.е. вызывающий код не может знать, был ли метод выполнен до конца или был отменён. Правильное решение — использовать ThrowIfCancellationRequested, даже для бесконечных циклов (как в предыдущем примере).
Когда проверять
Проверка - подходящий вариант для наблюдения за отменой, если код синхронный, например, код вычислительной операции. Но отмена в .NET применима как к синхронному коду, так и к асинхронному. Фактически, параллельные циклы и PLINQ имеют встроенную поддержку отмены: ParallelOptions.CancellationToken для Parallel и WithCancellation для PLINQ.
Уместно вводить ThrowIfCancellationRequested в асинхронный код, если вы не уверены, будут ли другие методы учитывать токен отмены. Помните, что метод, принимающий CancellationToken может учитывать отмену, но может и проигнорировать его. Поэтому в вашем коде можно добавить проверки отмены между «шагами»:
Хотя вы можете разбросать вызовы ThrowIfCancellationRequested по всему коду, как в примере выше, лучше это делать, только когда тестирование показывает, что код не учитывает отмену. Т.е. предполагайте, что DoStep1Async и DoStep2Async будут учитывать отмену, пока тестирование не докажет обратное.
Также уместно использовать ThrowIfCancellationRequested в определённых точках, где ваш код собирается сделать что-то затратное. Простое добавление туда проверки отмены означает, что вашему коду не придётся выполнять затратную работу, если он всё равно будет отменён.
Источник: https://blog.stephencleary.com/2022/03/cancellation-3-detecting-cancellation.html
Отмена. Часть 4: Проверка отмены
В большинстве случаев получаемый токен отмены просто передаётся на более низкий уровень. Но если нужен отменяемый код на самом низком уровне, есть несколько вариантов.
Обычный шаблон — периодически вызывать ThrowIfCancellationRequested:
void DoSomething(CancellationToken ct)
{
while (!done)
{
ct.ThrowIfCancellationRequested();
Thread.Sleep(200); // некоторая работа
}
}
В коде выше проверяется токен отмены до начала работы, что является хорошей практикой. Возможно, токен уже отменён к моменту начала выполнения вашей операции.
ThrowIfCancellationRequested проверит, запрошена ли отмена, и если да, то выдаст OperationCanceledException. Ваш код должен просто позволить этому исключению распространиться из метода.
Главный вопрос — как часто проверять. На него нет хорошего ответа; в идеале - несколько раз в секунду, но в общем случае - просто поместите его в лучшее место(а) и запустите несколько тестов, чтобы увидеть, достаточно ли отзывчива отмена.
Как не делать проверку
Существует антишаблон пулинга на предмет отмены в бесконечном цикле:
void DoSomethingForever(CancellationToken ct)
{
// плохой код, не делайте так
while (!ct.IsCancellationRequested)
Thread.Sleep(200); // некоторая работа
}
Код будет периодически проверять токен отмены; и при отмене происходит выход из метода. Этот метод не удовлетворяет контракту отмены, требующему выбрасывать исключение при отмене. Т.е. вызывающий код не может знать, был ли метод выполнен до конца или был отменён. Правильное решение — использовать ThrowIfCancellationRequested, даже для бесконечных циклов (как в предыдущем примере).
Когда проверять
Проверка - подходящий вариант для наблюдения за отменой, если код синхронный, например, код вычислительной операции. Но отмена в .NET применима как к синхронному коду, так и к асинхронному. Фактически, параллельные циклы и PLINQ имеют встроенную поддержку отмены: ParallelOptions.CancellationToken для Parallel и WithCancellation для PLINQ.
Уместно вводить ThrowIfCancellationRequested в асинхронный код, если вы не уверены, будут ли другие методы учитывать токен отмены. Помните, что метод, принимающий CancellationToken может учитывать отмену, но может и проигнорировать его. Поэтому в вашем коде можно добавить проверки отмены между «шагами»:
async Task DoComplexWorkAsync(CancellationToken ct)
{
ct.ThrowIfCancellationRequested();
await DoStep1Async(ct);
ct.ThrowIfCancellationRequested();
await DoStep2Async(ct);
}
Хотя вы можете разбросать вызовы ThrowIfCancellationRequested по всему коду, как в примере выше, лучше это делать, только когда тестирование показывает, что код не учитывает отмену. Т.е. предполагайте, что DoStep1Async и DoStep2Async будут учитывать отмену, пока тестирование не докажет обратное.
Также уместно использовать ThrowIfCancellationRequested в определённых точках, где ваш код собирается сделать что-то затратное. Простое добавление туда проверки отмены означает, что вашему коду не придётся выполнять затратную работу, если он всё равно будет отменён.
Источник: https://blog.stephencleary.com/2022/03/cancellation-3-detecting-cancellation.html
👍29
День 2009. #ЧтоНовенького
Предложение Типов-Объединений в C#
Бывает, что вы хотите сохранить в переменной значение не всегда одного и того же типа. Может потребоваться сохранить один из нескольких связанных типов в зависимости от того, что данные должны представлять в конкретный момент.
Например, приложение может определить клиента и поставщика, которые имеют несколько общих свойств, и может потребоваться выполнить общую операцию над обоими типами, но с учётом их различий.
Обычно здесь выделяют общие члены в абстрактный класс или интерфейс, и делают разных наследников. Но это хорошо, только когда эти типы существуют в первую очередь для цели операции или имеет смысл, чтобы операция отображалась как часть типа. Если типы имеют более широкое назначение, загрязнение их такими методами может быть нежелательным. Кроме того, вы можете не владеть определениями типов, либо у вас слишком много похожих ситуаций и вы можете решить только одну из них через наследование, либо вы решили не пропускать требования конкретной операции в определение данных, тогда единственный простой выбор, который у вас есть, — объявить переменную как object и позволить ей быть чем угодно.
Альтернативой является создание одной и той же логики для обработки обоих типов, и объявление параметра или переменной, которая может содержать любой из типов. Было бы хорошо, если бы язык предоставлял способ объявить тип, который хранит значение одного из ограниченного набора других типов, и при этом сохранял бы безопасность типов. Многие другие языки уже делают это. Обычно такие специальные типы называют discriminated union (дискриминированными/размеченными объединениями) или просто объединениями типов.
Недавно было предложено (точнее уже давно, сейчас предложение просто обновили) добавить в C# 4 типа объединений:
1. Стандартные
Именованное объединение типов, которое объявляет все типы своих членов в одном объявлении (похоже на расширенный enum):
2. Структуры
Аналогично классу, но объединение и типы членов являются структурами.
3. «По требованию» (Ad hoc)
Анонимные объединения типов, объявляемые в любом месте.
4. Пользовательские
Если необходимо объявить тип объединения, который не может быть указан как один из типов выше, можно объявить пользовательский тип объединения.
Но не спешите радоваться, это пока только обновлённое предложение. Так что завезут его в лучшем случае через пару релизов (лет), и то, скорей всего, сначала в виде превью.
Источник: https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md
Предложение Типов-Объединений в C#
Бывает, что вы хотите сохранить в переменной значение не всегда одного и того же типа. Может потребоваться сохранить один из нескольких связанных типов в зависимости от того, что данные должны представлять в конкретный момент.
Например, приложение может определить клиента и поставщика, которые имеют несколько общих свойств, и может потребоваться выполнить общую операцию над обоими типами, но с учётом их различий.
Обычно здесь выделяют общие члены в абстрактный класс или интерфейс, и делают разных наследников. Но это хорошо, только когда эти типы существуют в первую очередь для цели операции или имеет смысл, чтобы операция отображалась как часть типа. Если типы имеют более широкое назначение, загрязнение их такими методами может быть нежелательным. Кроме того, вы можете не владеть определениями типов, либо у вас слишком много похожих ситуаций и вы можете решить только одну из них через наследование, либо вы решили не пропускать требования конкретной операции в определение данных, тогда единственный простой выбор, который у вас есть, — объявить переменную как object и позволить ей быть чем угодно.
Альтернативой является создание одной и той же логики для обработки обоих типов, и объявление параметра или переменной, которая может содержать любой из типов. Было бы хорошо, если бы язык предоставлял способ объявить тип, который хранит значение одного из ограниченного набора других типов, и при этом сохранял бы безопасность типов. Многие другие языки уже делают это. Обычно такие специальные типы называют discriminated union (дискриминированными/размеченными объединениями) или просто объединениями типов.
Недавно было предложено (точнее уже давно, сейчас предложение просто обновили) добавить в C# 4 типа объединений:
1. Стандартные
Именованное объединение типов, которое объявляет все типы своих членов в одном объявлении (похоже на расширенный enum):
union U
{
A(int x, string y);
B(int z);
C;
}
U u = new A(10, "ten");
2. Структуры
Аналогично классу, но объединение и типы членов являются структурами.
union struct U
{
A(int x, string y);
B(int z);
C;
}
U u = new A(10, "ten");
3. «По требованию» (Ad hoc)
Анонимные объединения типов, объявляемые в любом месте.
(A or B or C) u = new A(10, "ten");
4. Пользовательские
Если необходимо объявить тип объединения, который не может быть указан как один из типов выше, можно объявить пользовательский тип объединения.
[Closed]
public class U { … }
public class A(int x, string y) : U { … }
public class B(int z) : U { … }
Но не спешите радоваться, это пока только обновлённое предложение. Так что завезут его в лучшем случае через пару релизов (лет), и то, скорей всего, сначала в виде превью.
Источник: https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md
👍18👎2
День 2010. #ЗаметкиНаПолях #AsyncTips
Конечный Автомат в C# для async/await. Начало
Часто говорят, что ключевые слова async/await приводят к созданию конечного автомата. Но что это значит? Рассмотрим на простом примере:
Здесь несколько вызовов await: для получения ответа, и для чтения содержимого.
Деление метода по границе await
Каждый раз при вызове await, мы знаем, что нам не нужно ничего делать, кроме как ждать результата. Логично при этом просто выйти из метода и вернуться, как только будет получен результат. Компилятор разделит метод по границе await и создаст конечный автомат. Вот упрощённый код:
Это очень упрощенная версия того, что делает компилятор, и она не учитывает важные части, например, как содержимое извлекается из HttpClient. Важно то, что мы синхронно вызываем часть метода до await, а затем используем механизм обратных вызовов (именно поэтому используется ref this) для продолжений метода. Таким образом, как только HTTP-вызов завершается, мы возвращаемся в метод и продолжаем с того места, где остановились (state = 1), когда завершается чтение – продолжаем со state=2.
Окончание следует…
Источник: https://steven-giesel.com/blogPost/720a48fd-0abe-4c32-83ac-26926d501895/the-state-machine-in-c-with-asyncawait
Конечный Автомат в C# для async/await. Начало
Часто говорят, что ключевые слова async/await приводят к созданию конечного автомата. Но что это значит? Рассмотрим на простом примере:
async Task<Dto> GetAsync()
{
using var hc = new HttpClient();
hc.BaseAddress = new Uri("…");
var resp = await hc.GetAsync("");
resp.EnsureSuccessStatusCode();
var content =
await resp.Content.ReadAsStringAsync();
return JsonSerializer.Deserialize<Dto>(content);
}
public class Dto;
Здесь несколько вызовов await: для получения ответа, и для чтения содержимого.
Деление метода по границе await
Каждый раз при вызове await, мы знаем, что нам не нужно ничего делать, кроме как ждать результата. Логично при этом просто выйти из метода и вернуться, как только будет получен результат. Компилятор разделит метод по границе await и создаст конечный автомат. Вот упрощённый код:
public class GetAllAsync_StateMachine
{
public ContinuationMachine _builder =
ContinuationMachineBuilder.Create();
private int _state = 0;
private HttpClient _hc;
private HttpResponseMessage _resp;
private string _content;
private void MoveNext()
{
switch (_state)
{
case 0:
_hc = new HttpClient();
_hc.BaseAddress = new Uri("…");
_hc.GetAsync("");
_state = 1;
_builder.Continue(ref this);
break;
case 1:
_resp.EnsureSuccessStatusCode();
_resp.Content.ReadAsStringAsync();
_state = 2;
_builder.Continue(ref this);
break;
case 2:
return JsonSerializer.Deserialize<Dto>(_content);
}
}
}
Это очень упрощенная версия того, что делает компилятор, и она не учитывает важные части, например, как содержимое извлекается из HttpClient. Важно то, что мы синхронно вызываем часть метода до await, а затем используем механизм обратных вызовов (именно поэтому используется ref this) для продолжений метода. Таким образом, как только HTTP-вызов завершается, мы возвращаемся в метод и продолжаем с того места, где остановились (state = 1), когда завершается чтение – продолжаем со state=2.
Окончание следует…
Источник: https://steven-giesel.com/blogPost/720a48fd-0abe-4c32-83ac-26926d501895/the-state-machine-in-c-with-asyncawait
👍21