День 2289. #ЗаметкиНаПолях
5 Основных Ошибок при Создании API. Окончание
Начало
Продолжение
5. Отсутствие централизованной обработки ошибок
Ошибка: Хаотичное использование блоков try-catch по всему коду или, что ещё хуже оставление исключений необработанными.
Реальность: Нужно одно место для аккуратной обработки непредвиденных ошибок.
Плохо:
Проблемы:
- Дублирование кода.
- Несогласованные ответы с ошибками.
- Трудности с правильным логированием.
Лучше (использование промежуточного ПО обработки ошибок):
Ещё лучше – использование ProblemDetails (application/problem+json) в .NET 9 автоматически через ответ Problem().
Почему важно:
- Более чистый код.
- Стандартные сообщения об ошибках для всех клиентов.
- Простота подключения логирования (Serilog, OpenTelemetry, и т.п.).
Кроме того:
Не рекомендуется использовать исключения в качестве основного способа обработки ошибок. Вместо этого, если вы создаёте новые API сегодня, рассмотрите шаблон Result (например, Result, OneOf и т.д.). Так вы явно возвращаете результаты успеха/неудачи, вообще не полагаясь на исключения. Исключения должны использоваться для действительно неожиданных случаев, а не для обычных ошибок проверки. Тем не менее, если ваш проект (или ваша команда) уже использует исключения, лучшим решением будет централизовать их обработку.
Вот простая обработка ошибок в стиле Result:
Итого
API — это не просто «передача данных туда и обратно».
API — это контракты.
API — это обещания.
Когда вы создаёте API с хорошей проверкой входных данных, управлением версиями, обработкой ошибок и продуманными ответами — вы даёте обещание своим клиентам (и себе в будущем), что ваша система будет надёжной и предсказуемой. Даже небольшие улучшения в API сейчас могут сэкономить десятки часов позже.
Источник: https://thecodeman.net/posts/building-apis-top-5-mistakes
5 Основных Ошибок при Создании API. Окончание
Начало
Продолжение
5. Отсутствие централизованной обработки ошибок
Ошибка: Хаотичное использование блоков try-catch по всему коду или, что ещё хуже оставление исключений необработанными.
Реальность: Нужно одно место для аккуратной обработки непредвиденных ошибок.
Плохо:
try
{
var user = await db.Users.FindAsync(id);
return Results.Ok(user);
}
catch (Exception ex)
{
return Results.Problem(ex.Message);
}
Проблемы:
- Дублирование кода.
- Несогласованные ответы с ошибками.
- Трудности с правильным логированием.
Лучше (использование промежуточного ПО обработки ошибок):
app.UseExceptionHandler(app =>
{
app.Run(async ctx =>
{
ctx.Response.StatusCode = 500;
ctx.Response.ContentType = "application/json";
await ctx.Response.WriteAsJsonAsync(new
{
Error = "Что-то пошло не так."
});
});
});
Ещё лучше – использование ProblemDetails (application/problem+json) в .NET 9 автоматически через ответ Problem().
Почему важно:
- Более чистый код.
- Стандартные сообщения об ошибках для всех клиентов.
- Простота подключения логирования (Serilog, OpenTelemetry, и т.п.).
Кроме того:
Не рекомендуется использовать исключения в качестве основного способа обработки ошибок. Вместо этого, если вы создаёте новые API сегодня, рассмотрите шаблон Result (например, Result, OneOf и т.д.). Так вы явно возвращаете результаты успеха/неудачи, вообще не полагаясь на исключения. Исключения должны использоваться для действительно неожиданных случаев, а не для обычных ошибок проверки. Тем не менее, если ваш проект (или ваша команда) уже использует исключения, лучшим решением будет централизовать их обработку.
Вот простая обработка ошибок в стиле Result:
public record Result<T>(
bool IsSuccess,
T? Value,
string? ErrorMessage
);
app.MapGet("/users/{id}",
async (Guid id, DbContext db) =>
{
var user = await db.Users.FindAsync(id);
if (user is null)
return Results.NotFound(
new Result<User>(
false,
null,
"Пользователь не найден"));
return Results.Ok(
new Result<User>(true, user, null));
});
Итого
API — это не просто «передача данных туда и обратно».
API — это контракты.
API — это обещания.
Когда вы создаёте API с хорошей проверкой входных данных, управлением версиями, обработкой ошибок и продуманными ответами — вы даёте обещание своим клиентам (и себе в будущем), что ваша система будет надёжной и предсказуемой. Даже небольшие улучшения в API сейчас могут сэкономить десятки часов позже.
Источник: https://thecodeman.net/posts/building-apis-top-5-mistakes
День 2290. #ЧтоНовенького
Поддержка Валидации в Минимальных API
В превью 3 .NET 10 доступна поддержка валидации в минимальных API. Эта функция позволяет вам требовать валидацию данных, отправляемых на конечные точки API. Когда валидация включена, среда выполнения ASP.NET Core выполнит любые проверки, определённые для параметров запроса, заголовка и маршрута, а также для тела запроса. Валидации можно определить с помощью атрибутов из пространства имён System.ComponentModel.DataAnnotations.
Разработчики также могут добавлять кастомную валидацию с помощью:
- создания пользовательских реализаций ValidationAttribute (для валидации отдельных свойств);
- реализации интерфейса IValidatableObject для сложной логики проверки (задействующей несколько свойств модели).
Если валидация не проходит, среда выполнения возвращает ответ 400 Bad Request с подробностями ошибок валидации.
Чтобы включить встроенную поддержку валидации для минимальных API, вызовите метод расширения AddValidation, чтобы зарегистрировать требуемые сервисы в контейнере зависимостей приложения:
Вам также нужно установить свойство InterceptorsNamespaces в файле проекта следующим образом:
Реализация автоматически обнаруживает типы, которые определены в обработчиках минимальных API или базовые типы типов, определённых в обработчиках минимальных API. Валидация выполняется для этих типов с помощью фильтра, добавляемого к каждой конечной точке.
Таким образом, используется генерация исходного кода для добавления перехватчиков, что очень эффективно. Но всё-таки, надеюсь, что к релизу добавление этого магического кода будет не обязательно.
Валидация может быть отключена для определённых конечных точек с помощью метода расширения DisableValidation:
Атрибуты валидации могут добавляться как к отдельным параметрам конечной точки, так и к свойствам модели (если класс модели является параметром конечной точки).
Источник: https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/aspnetcore.md#validation-support-in-minimal-apis
Поддержка Валидации в Минимальных API
В превью 3 .NET 10 доступна поддержка валидации в минимальных API. Эта функция позволяет вам требовать валидацию данных, отправляемых на конечные точки API. Когда валидация включена, среда выполнения ASP.NET Core выполнит любые проверки, определённые для параметров запроса, заголовка и маршрута, а также для тела запроса. Валидации можно определить с помощью атрибутов из пространства имён System.ComponentModel.DataAnnotations.
Разработчики также могут добавлять кастомную валидацию с помощью:
- создания пользовательских реализаций ValidationAttribute (для валидации отдельных свойств);
- реализации интерфейса IValidatableObject для сложной логики проверки (задействующей несколько свойств модели).
Если валидация не проходит, среда выполнения возвращает ответ 400 Bad Request с подробностями ошибок валидации.
Чтобы включить встроенную поддержку валидации для минимальных API, вызовите метод расширения AddValidation, чтобы зарегистрировать требуемые сервисы в контейнере зависимостей приложения:
builder.Services.AddValidation();
Вам также нужно установить свойство InterceptorsNamespaces в файле проекта следующим образом:
<PropertyGroup>
<!-- Включаем генерацию перехватчиков для атрибутов валидации -->
<InterceptorsNamespaces>$(InterceptorsNamespaces);Microsoft.AspNetCore.Http.Validation.Generated</InterceptorsNamespaces>
</PropertyGroup>
Реализация автоматически обнаруживает типы, которые определены в обработчиках минимальных API или базовые типы типов, определённых в обработчиках минимальных API. Валидация выполняется для этих типов с помощью фильтра, добавляемого к каждой конечной точке.
Таким образом, используется генерация исходного кода для добавления перехватчиков, что очень эффективно. Но всё-таки, надеюсь, что к релизу добавление этого магического кода будет не обязательно.
Валидация может быть отключена для определённых конечных точек с помощью метода расширения DisableValidation:
app.MapPost("/products",
([EvenNumber(ErrorMessage = "ID должен быть чётным")]
int productId,
[Required] string name)
=> TypedResults.Ok(productId))
.DisableValidation();Атрибуты валидации могут добавляться как к отдельным параметрам конечной точки, так и к свойствам модели (если класс модели является параметром конечной точки).
Источник: https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/aspnetcore.md#validation-support-in-minimal-apis
День 2291. #TipsAndTricks
Скрипт PowerShell для Переименования Проектов .NET
Переименовать проект .NET — утомительное занятие. Вам придётся переименовать файлы и папки, а также заменить содержимое в файлах, например пространство имён или путь в файлах .sln.
Следующий скрипт PowerShell, переименует файлы и папки и заменит содержимое в файлах:
Источник: https://www.meziantou.net/powershell-script-to-rename-dotnet-projects.htm
Скрипт PowerShell для Переименования Проектов .NET
Переименовать проект .NET — утомительное занятие. Вам придётся переименовать файлы и папки, а также заменить содержимое в файлах, например пространство имён или путь в файлах .sln.
Следующий скрипт PowerShell, переименует файлы и папки и заменит содержимое в файлах:
$ErrorActionPreference = "Stop"
$rootFolder = Resolve-Path -Path "."
$oldName = "SampleRazorPages"
$newName = "SampleWebApp"
# Переименовываем файлы и папки
foreach ($item in Get-ChildItem -LiteralPath $rootFolder -Recurse | Sort-Object -Property FullName -Descending) {
$itemNewName = $item.Name.Replace($oldName, $newName)
if ($item.Name -ne $itemNewName) {
Rename-Item -LiteralPath $item.FullName -NewName $itemNewName
}
}
# Заменяем содержимое в файлах
foreach ($item in Get-ChildItem $rootFolder -Recurse -Include "*.cmd", "*.cs", "*.csproj", "*.json", "*.md", "*.proj", "*.props", "*.ps1", "*.sln", "*.slnx", "*.targets", "*.txt", "*.vb", "*.vbproj", "*.xaml", "*.xml", "*.xproj", "*.yml", "*.yaml") {
$content = Get-Content -LiteralPath $item.FullName
if ($content) {
$newContent = $content.Replace($oldName, $newName)
Set-Content -LiteralPath $item.FullName -Value $newContent
}
}
Источник: https://www.meziantou.net/powershell-script-to-rename-dotnet-projects.htm
Что означает .NET?
#Quiz
#Quiz
Anonymous Quiz
47%
New Environmental Technology
16%
Network Enabled Technology
22%
Происходит от домена .net
16%
Сокращение от слова "network"
День 2292. #SystemDesign101
Объяснение Модели OSI
Как данные передаются по сети? Зачем нам нужно так много уровней в модели OSI (Open Systems Interconnection)?
На схеме выше показано, как данные инкапсулируются и деинкапсулируются при передаче по сети.
Шаг 1: Когда устройство A отправляет данные устройству B по сети через протокол HTTP, сначала добавляется заголовок HTTP на прикладном уровне.
Шаг 2: Затем к данным добавляется заголовок TCP или UDP. Они инкапсулируются в сегменты TCP на транспортном уровне. Заголовок содержит порт источника, порт назначения и порядковый номер.
Шаг 3: Сегменты инкапсулируются с заголовком IP на сетевом уровне. Заголовок IP содержит IP-адреса источника/получателя.
Шаг 4: Добавляется заголовок MAC на канальном уровне с MAC-адресами источника/получателя.
Шаг 5: Инкапсулированные фреймы отправляются на физический уровень и передаются по сети в двоичном формате.
Шаги 6–10: Когда устройство B получает двоичные данные из сети, оно выполняет процесс деинкапсуляции, который является обратным процессу инкапсуляции. Заголовки удаляются слой за слоем, и в итоге устройство B может прочитать данные.
Нам нужны слои в сетевой модели, потому что каждый слой фокусируется на своих собственных обязанностях. Каждый слой может полагаться на заголовки для инструкций по обработке и не должен понимать значение данных из последнего слоя.
Источник: https://github.com/ByteByteGoHq/system-design-101
Объяснение Модели OSI
Как данные передаются по сети? Зачем нам нужно так много уровней в модели OSI (Open Systems Interconnection)?
На схеме выше показано, как данные инкапсулируются и деинкапсулируются при передаче по сети.
Шаг 1: Когда устройство A отправляет данные устройству B по сети через протокол HTTP, сначала добавляется заголовок HTTP на прикладном уровне.
Шаг 2: Затем к данным добавляется заголовок TCP или UDP. Они инкапсулируются в сегменты TCP на транспортном уровне. Заголовок содержит порт источника, порт назначения и порядковый номер.
Шаг 3: Сегменты инкапсулируются с заголовком IP на сетевом уровне. Заголовок IP содержит IP-адреса источника/получателя.
Шаг 4: Добавляется заголовок MAC на канальном уровне с MAC-адресами источника/получателя.
Шаг 5: Инкапсулированные фреймы отправляются на физический уровень и передаются по сети в двоичном формате.
Шаги 6–10: Когда устройство B получает двоичные данные из сети, оно выполняет процесс деинкапсуляции, который является обратным процессу инкапсуляции. Заголовки удаляются слой за слоем, и в итоге устройство B может прочитать данные.
Нам нужны слои в сетевой модели, потому что каждый слой фокусируется на своих собственных обязанностях. Каждый слой может полагаться на заголовки для инструкций по обработке и не должен понимать значение данных из последнего слоя.
Источник: https://github.com/ByteByteGoHq/system-design-101
День 2293. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Совершенствование процессов
Цель совершенствования процесса разработки (Software Process Improvement, SPI) — снизить стоимость разработки и сопровождения ПО. Это средство достижения превосходных бизнес-результатов, что бы ни подразумевалось под ними: ускорение доставки продуктов, уменьшение количества переделок, лучшее удовлетворение потребностей клиентов, снижение затрат на поддержку и т.п. Что-то должно измениться в работе команды, чтобы данная цель стала достижимой. Это изменение и есть SPI. Каждый ретроспективный обзор, чтобы извлечь уроки и улучшить работу в следующий раз, закладывает основу для совершенствования процессов. Каждая новая техника, делающая проект более эффективным и действенным, совершенствует процесс.
Не бойтесь процессов
Для некоторых слово «процесс» имеет негативный оттенок. Иногда люди не осознают, что у них уже есть процесс разработки ПО, даже если он плохо определён или не задокументирован. Некоторые опасаются, что необходимость следовать процедурам будет ограничивать их, подавлять творческий потенциал или замедлит проект. Конечно, можно упорно применять неподходящие процессы, не добавляя ценности и не допуская изменений в проектах и людях. Но это не обязательно! Когда всё работает правильно, организации добиваются успеха благодаря процессам, а не вопреки им. Разумные и подходящие процессы помогают добиваться успеха постоянно. Процесс и творчество совместимы.
Несмотря на концептуальную простоту, SPI — сложная задача. Нелегко заставить людей признать наличие недостатков в их нынешних методах работы. Любая проектная работа сложна, и как же уговорить команды тратить время на выявление и устранение недостатков? Изменить культуру организации непросто, однако SPI предполагает изменение культуры наряду с изменениями в технических и управленческих методах.
Как возвести SPI в привычку
Многие программы SPI не дают эффективных и устойчивых результатов. Новые модные инициативы по изменениям вводятся с помпой, но потом тихо исчезают без объявления и анализа причин. Организация отказывается от приложенных усилий и позже пробует что-то другое. Обычно вы можете совершить только две неудачные попытки стратегического совершенствования, прежде чем люди решат, что организация несерьёзно относится к изменениям. После двух неудач мало кто всерьёз отнесётся к следующей инициативе по изменению.
Чтобы достичь успеха в совершенствовании процессов, нужно время. Организации должны достаточно долго прикладывать усилия, чтобы получить первые плоды. Если вы остановитесь на полпути после вложения средств в оценку и обучение, но до того, как изменения окупятся, то потеряете свои вложения. Крупномасштабные изменения процессов происходят небыстро, поэтому учитесь получать удовольствие от маленьких побед. Постарайтесь определить улучшения, которые можно быстро внедрить, чтобы решить известные проблемы, а также долгосрочные системные изменения.
Если в организации нет настоятельной необходимости соблюдать определённый стандарт, например в целях сертификации, то приемлема любая система разработки, будь то устоявшаяся модель, вроде Agile или какая-то своя. Но если рассматривать SPI просто как очередную причуду руководства, то большинство работников постараются просто пережить её, пытаясь выполнять свою настоящую работу, несмотря на отвлекающие факторы. Это не способствует успеху изменений.
Первые шаги
1. Каких бизнес-результатов вы ещё не достигли, для чего могло бы потребоваться SPI?
2. Увенчались ли успехом прошлые инициативы SPI? Какие действия окупились: устоявшаяся модель совершенствования или доморощенные подходы?
3. Определите любые недостатки или проблемы в работе организации, устранив которые можно улучшить процессы.
4. Как каждая проблема влияет на способность успешно выявлять, разрабатывать и внедрять SPI?
5. Попробуйте определить основные причины, провоцирующие или усугубляющие каждую проблему.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Совершенствование процессов
Цель совершенствования процесса разработки (Software Process Improvement, SPI) — снизить стоимость разработки и сопровождения ПО. Это средство достижения превосходных бизнес-результатов, что бы ни подразумевалось под ними: ускорение доставки продуктов, уменьшение количества переделок, лучшее удовлетворение потребностей клиентов, снижение затрат на поддержку и т.п. Что-то должно измениться в работе команды, чтобы данная цель стала достижимой. Это изменение и есть SPI. Каждый ретроспективный обзор, чтобы извлечь уроки и улучшить работу в следующий раз, закладывает основу для совершенствования процессов. Каждая новая техника, делающая проект более эффективным и действенным, совершенствует процесс.
Не бойтесь процессов
Для некоторых слово «процесс» имеет негативный оттенок. Иногда люди не осознают, что у них уже есть процесс разработки ПО, даже если он плохо определён или не задокументирован. Некоторые опасаются, что необходимость следовать процедурам будет ограничивать их, подавлять творческий потенциал или замедлит проект. Конечно, можно упорно применять неподходящие процессы, не добавляя ценности и не допуская изменений в проектах и людях. Но это не обязательно! Когда всё работает правильно, организации добиваются успеха благодаря процессам, а не вопреки им. Разумные и подходящие процессы помогают добиваться успеха постоянно. Процесс и творчество совместимы.
Несмотря на концептуальную простоту, SPI — сложная задача. Нелегко заставить людей признать наличие недостатков в их нынешних методах работы. Любая проектная работа сложна, и как же уговорить команды тратить время на выявление и устранение недостатков? Изменить культуру организации непросто, однако SPI предполагает изменение культуры наряду с изменениями в технических и управленческих методах.
Как возвести SPI в привычку
Многие программы SPI не дают эффективных и устойчивых результатов. Новые модные инициативы по изменениям вводятся с помпой, но потом тихо исчезают без объявления и анализа причин. Организация отказывается от приложенных усилий и позже пробует что-то другое. Обычно вы можете совершить только две неудачные попытки стратегического совершенствования, прежде чем люди решат, что организация несерьёзно относится к изменениям. После двух неудач мало кто всерьёз отнесётся к следующей инициативе по изменению.
Чтобы достичь успеха в совершенствовании процессов, нужно время. Организации должны достаточно долго прикладывать усилия, чтобы получить первые плоды. Если вы остановитесь на полпути после вложения средств в оценку и обучение, но до того, как изменения окупятся, то потеряете свои вложения. Крупномасштабные изменения процессов происходят небыстро, поэтому учитесь получать удовольствие от маленьких побед. Постарайтесь определить улучшения, которые можно быстро внедрить, чтобы решить известные проблемы, а также долгосрочные системные изменения.
Если в организации нет настоятельной необходимости соблюдать определённый стандарт, например в целях сертификации, то приемлема любая система разработки, будь то устоявшаяся модель, вроде Agile или какая-то своя. Но если рассматривать SPI просто как очередную причуду руководства, то большинство работников постараются просто пережить её, пытаясь выполнять свою настоящую работу, несмотря на отвлекающие факторы. Это не способствует успеху изменений.
Первые шаги
1. Каких бизнес-результатов вы ещё не достигли, для чего могло бы потребоваться SPI?
2. Увенчались ли успехом прошлые инициативы SPI? Какие действия окупились: устоявшаяся модель совершенствования или доморощенные подходы?
3. Определите любые недостатки или проблемы в работе организации, устранив которые можно улучшить процессы.
4. Как каждая проблема влияет на способность успешно выявлять, разрабатывать и внедрять SPI?
5. Попробуйте определить основные причины, провоцирующие или усугубляющие каждую проблему.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
День 2294. #ЧтоНовенького
Поддержка Server-Sent Events (SSE)
ASP.NET Core теперь поддерживает возврат результата ServerSentEvents с помощью API TypedResults.ServerSentEvents. Эта функция поддерживается как в минимальных API, так и в приложениях на основе контроллеров.
События Server-Sent (SSE) — это технология push-уведомлений со стороны сервера, которая позволяет серверу отправлять поток сообщений о событиях клиенту в рамках одного HTTP-соединения. В .NET сообщения о событиях представлены как объекты SseItem<T>, которые могут содержать тип события, идентификатор и полезные данные типа T.
Класс TypedResults включает новый статический метод ServerSentEvents для возврата результата ServerSentEvents. Первым параметром этого метода является IAsyncEnumerable<SseItem<T>>, который представляет собой поток сообщений о событиях, отправляемых клиенту.
В следующем примере показано, как использовать API TypedResults.ServerSentEvents для возврата клиенту потока событий сердечного ритма в виде объектов JSON:
Подробнее Server-Sent Events разобрал Ник Чапсас в своём видео.
Источник: https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/aspnetcore.md#support-for-server-sent-events-sse
Поддержка Server-Sent Events (SSE)
ASP.NET Core теперь поддерживает возврат результата ServerSentEvents с помощью API TypedResults.ServerSentEvents. Эта функция поддерживается как в минимальных API, так и в приложениях на основе контроллеров.
События Server-Sent (SSE) — это технология push-уведомлений со стороны сервера, которая позволяет серверу отправлять поток сообщений о событиях клиенту в рамках одного HTTP-соединения. В .NET сообщения о событиях представлены как объекты SseItem<T>, которые могут содержать тип события, идентификатор и полезные данные типа T.
Класс TypedResults включает новый статический метод ServerSentEvents для возврата результата ServerSentEvents. Первым параметром этого метода является IAsyncEnumerable<SseItem<T>>, который представляет собой поток сообщений о событиях, отправляемых клиенту.
В следующем примере показано, как использовать API TypedResults.ServerSentEvents для возврата клиенту потока событий сердечного ритма в виде объектов JSON:
app.MapGet("/json-item",
(CancellationToken ct) =>
{
async IAsyncEnumerable<HeartRateEvent>
GetHeartRate(
[EnumeratorCancellation]
CancellationToken token)
{
while (!token.IsCancellationRequested)
{
var hr = Random.Shared.Next(60, 100);
yield return HeartRateEvent.Create(hr);
await Task.Delay(2000, token);
}
}
return TypedResults.ServerSentEvents(
GetHeartRate(ct),
eventType: "heartRate");
});Подробнее Server-Sent Events разобрал Ник Чапсас в своём видео.
Источник: https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/aspnetcore.md#support-for-server-sent-events-sse
День 2295. #Карьера
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Начало
У всех нас были дни, когда список задач состоял из одних «срочных» запросов. Менеджеру по продукту нужна эта функция вчера. В производстве только что появились три критических ошибки. Технический долг, который вы откладывали, наконец стал причиной проблем. И от вас ожидают, что вы будете справляться со всем этим одновременно. С правильной структурой и инструментами расстановки приоритетов вы можете прорваться через хаос и сосредоточиться на том, что действительно важно.
Почему это важно?
Эффективная расстановка приоритетов — это не только работа быстрее, но и работа умнее. Для разработчиков правильная расстановка приоритетов задач:
- Уменьшает переключение контекста, которое, как показывают исследования, может снизить производительность до 40%.
- Гарантирует устранение критических ошибок и проблем безопасности до того, как они повлияют на пользователей.
- Согласует работу по разработке с целями и сроками бизнеса.
- Снижает стресс и предотвращает выгорание.
- Создаёт возможность работы «в потоке», когда получается лучший код.
Без чёткой системы расстановки приоритетов вы обнаружите, что постоянно тушите пожары, никогда не достигая существенного прогресса в важных проектах и наблюдая, как страдает ваша производительность.
Эффективные методики определения приоритетов задач разработки
Следующие проверенные методики могут помочь вам определить, что заслуживает вашего внимания в первую очередь.
1. Матрица Эйзенхауэра: срочное и важное
Матрица Эйзенхауэра делит задачи на четыре квадранта в зависимости от их срочности и важности.
- Срочно и важно: критические ошибки, уязвимости безопасности, сбои в производстве. Делайте это немедленно.
- Важно, но не срочно: рефакторинг кода, документирование, изучение новых навыков. Запланируйте время для этого.
- Срочно, но не важно: всяческие встречи, письма, обновления статуса. Делегируйте, если возможно.
- Не срочно и не важно: прочие отвлекающие факторы. Полностью исключите это.
Для разработчиков эта методика особенно ценна, поскольку помогает различать действительно чрезвычайные ситуации (например, нарушения безопасности) и задачи, которые просто кажутся срочными, но могут подождать (например, запрос на функцию, который «абсолютно необходимо сделать на этой неделе»).
2. Метод ABCDE
Разработан Брайаном Трейси и предлагает простой подход к расстановке приоритетов:
- A: Высокоприоритетные, срочные задачи со значительными последствиями, если не будут выполнены.
- B: Важные задачи, но менее срочные, чем A, со средними последствиями.
- C: Низкоприоритетные с небольшими или нулевыми последствиями.
- D: Задачи, которые можно делегировать другим.
- E: Задачи, которые можно полностью исключить.
Всегда сначала беритесь за задачи «A», так как они требуют немедленных действий и существенно влияют на ваши долгосрочные цели и сроки.
3. Метод MoSCoW
Особенно полезный для agile команд. Классифицирует задачи следующим образом:
- Обязательно (Must have): критические требования, которые должны быть выполнены для успеха проекта.
- Хорошо бы (Should have): важные функции, которые добавляют значительную ценность, но не являются абсолютно необходимыми.
- Можно бы (Could have): функции, которые улучшат продукт, но могут быть отложены.
- Необязательно (Won’t have): функции, которые не будут реализованы в текущей итерации.
Эта структура особенно хорошо работает при расстановке приоритетов в пользовательских историях и требованиях на основе их важности для общего пользовательского опыта.
Продолжение следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Начало
У всех нас были дни, когда список задач состоял из одних «срочных» запросов. Менеджеру по продукту нужна эта функция вчера. В производстве только что появились три критических ошибки. Технический долг, который вы откладывали, наконец стал причиной проблем. И от вас ожидают, что вы будете справляться со всем этим одновременно. С правильной структурой и инструментами расстановки приоритетов вы можете прорваться через хаос и сосредоточиться на том, что действительно важно.
Почему это важно?
Эффективная расстановка приоритетов — это не только работа быстрее, но и работа умнее. Для разработчиков правильная расстановка приоритетов задач:
- Уменьшает переключение контекста, которое, как показывают исследования, может снизить производительность до 40%.
- Гарантирует устранение критических ошибок и проблем безопасности до того, как они повлияют на пользователей.
- Согласует работу по разработке с целями и сроками бизнеса.
- Снижает стресс и предотвращает выгорание.
- Создаёт возможность работы «в потоке», когда получается лучший код.
Без чёткой системы расстановки приоритетов вы обнаружите, что постоянно тушите пожары, никогда не достигая существенного прогресса в важных проектах и наблюдая, как страдает ваша производительность.
Эффективные методики определения приоритетов задач разработки
Следующие проверенные методики могут помочь вам определить, что заслуживает вашего внимания в первую очередь.
1. Матрица Эйзенхауэра: срочное и важное
Матрица Эйзенхауэра делит задачи на четыре квадранта в зависимости от их срочности и важности.
- Срочно и важно: критические ошибки, уязвимости безопасности, сбои в производстве. Делайте это немедленно.
- Важно, но не срочно: рефакторинг кода, документирование, изучение новых навыков. Запланируйте время для этого.
- Срочно, но не важно: всяческие встречи, письма, обновления статуса. Делегируйте, если возможно.
- Не срочно и не важно: прочие отвлекающие факторы. Полностью исключите это.
Для разработчиков эта методика особенно ценна, поскольку помогает различать действительно чрезвычайные ситуации (например, нарушения безопасности) и задачи, которые просто кажутся срочными, но могут подождать (например, запрос на функцию, который «абсолютно необходимо сделать на этой неделе»).
2. Метод ABCDE
Разработан Брайаном Трейси и предлагает простой подход к расстановке приоритетов:
- A: Высокоприоритетные, срочные задачи со значительными последствиями, если не будут выполнены.
- B: Важные задачи, но менее срочные, чем A, со средними последствиями.
- C: Низкоприоритетные с небольшими или нулевыми последствиями.
- D: Задачи, которые можно делегировать другим.
- E: Задачи, которые можно полностью исключить.
Всегда сначала беритесь за задачи «A», так как они требуют немедленных действий и существенно влияют на ваши долгосрочные цели и сроки.
3. Метод MoSCoW
Особенно полезный для agile команд. Классифицирует задачи следующим образом:
- Обязательно (Must have): критические требования, которые должны быть выполнены для успеха проекта.
- Хорошо бы (Should have): важные функции, которые добавляют значительную ценность, но не являются абсолютно необходимыми.
- Можно бы (Could have): функции, которые улучшат продукт, но могут быть отложены.
- Необязательно (Won’t have): функции, которые не будут реализованы в текущей итерации.
Эта структура особенно хорошо работает при расстановке приоритетов в пользовательских историях и требованиях на основе их важности для общего пользовательского опыта.
Продолжение следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
День 2296. #Карьера
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Продолжение
Начало
Практические шаги
1. Соберите и перечислите все задачи
Прежде чем вы сможете эффективно расставить приоритеты, необходимо иметь представление обо всём, что нужно сделать. Составьте полный список задач, включая:
- Назначенные тикеты и отчёты об ошибках;
- Запросы функций;
- Обзоры кода;
- Элементы технического долга;
- Необходимость документации;
- Встречи и административная работа.
Используйте инструмент управления проектами, чтобы централизовать эту информацию, а не держать её разбросанной по электронным письмам, сообщениям в мессенджерах и листочкам на рабочем столе.
2. Оцените истинную срочность и кажущуюся срочность
Не всё, что помечено как «срочное», на самом деле срочно. Задайте эти вопросы, чтобы определить фактическую срочность задачи:
- Что произойдет, если это не будет сделано сегодня? На этой неделе?
- Кто пострадает, если эта задача будет отложена?
- Блокирует ли это других членов команды или элементы критического пути?
- Существуют ли жёсткие сроки, обусловленные внешними факторами (например, запуск продукта)?
Часто вы обнаружите, что многие «срочные» запросы могут подождать без существенных последствий.
3. Примените методику приоритетов
Выберите одну из методик, обсуждавшихся ранее, и классифицируйте каждую задачу соответствующим образом. Будьте честны и реалистичны в отношении того, к какому классу относятся задачи — не позволяйте всему скатываться в категорию «срочно и важно».
4. Сосредоточьтесь на одной задаче за раз
Многозадачность — миф, особенно для разработчиков. Переключение контекста между задачами написания кода особенно затратно с когнитивной точки зрения. Как только вы определили самую приоритетную задачу:
- Закройте ненужные вкладки и приложения;
- Блокируйте отвлекающие факторы (email, телефон, мессенджеры и т.д.);
- Установите таймер для сосредоточенной работы («помидорный график» хорошо подходит многим разработчикам);
- Работайте над этой единственной задачей до её завершения или до тех пор, пока не достигнете логической точки остановки.
5. Сообщите приоритеты и установите ожидания
Когда вы не можете сделать всё сразу (а вы не можете), становится важным чёткое общение:
- Сообщите заинтересованным сторонам о ваших текущих приоритетах и о том, почему вы расположили задачи в определённом порядке;
- Укажите реалистичные сроки для менее приоритетных задач;
- При необходимости обсудите сроки;
- Будьте прозрачны в отношении ограничений ваших физических способностей.
Большинство разумных членов команды поймут решения по расстановке приоритетов, если вы чётко объясните свои доводы.
Инструменты
Правильные инструменты могут значительно упростить процесс.
1. Платформы управления проектами
Предоставляют централизованное рабочее пространство для визуализации, организации и расстановки приоритетов задач. Некоторые платформы, такие как Teamcamp помогают отслеживать и анализировать время. Такие инструменты помогут вам:
- Определить, какие задачи постоянно занимают больше времени, чем ожидалось;
- Распознать закономерности в вашей производительности;
- Делать более точные оценки для будущей работы;
- Обосновывать решения по расстановке приоритетов с помощью данных.
2. Инструменты автоматизации
Автоматизируя повторяющиеся задачи, вы освобождаете умственное пространство и время для важной работы:
- Настройте конвейеры CI/CD для автоматизации тестирования и развёртывания;
- Создайте скрипты для распространённых шаблонов кода;
- Используйте чат-ботов для рутинных коммуникаций;
- Внедрите автоматизированные проверки кода.
Каждая задача, которую вы автоматизируете, — это на одну задачу меньше, в конкуренции за ваше внимание.
Окончание следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Продолжение
Начало
Практические шаги
1. Соберите и перечислите все задачи
Прежде чем вы сможете эффективно расставить приоритеты, необходимо иметь представление обо всём, что нужно сделать. Составьте полный список задач, включая:
- Назначенные тикеты и отчёты об ошибках;
- Запросы функций;
- Обзоры кода;
- Элементы технического долга;
- Необходимость документации;
- Встречи и административная работа.
Используйте инструмент управления проектами, чтобы централизовать эту информацию, а не держать её разбросанной по электронным письмам, сообщениям в мессенджерах и листочкам на рабочем столе.
2. Оцените истинную срочность и кажущуюся срочность
Не всё, что помечено как «срочное», на самом деле срочно. Задайте эти вопросы, чтобы определить фактическую срочность задачи:
- Что произойдет, если это не будет сделано сегодня? На этой неделе?
- Кто пострадает, если эта задача будет отложена?
- Блокирует ли это других членов команды или элементы критического пути?
- Существуют ли жёсткие сроки, обусловленные внешними факторами (например, запуск продукта)?
Часто вы обнаружите, что многие «срочные» запросы могут подождать без существенных последствий.
3. Примените методику приоритетов
Выберите одну из методик, обсуждавшихся ранее, и классифицируйте каждую задачу соответствующим образом. Будьте честны и реалистичны в отношении того, к какому классу относятся задачи — не позволяйте всему скатываться в категорию «срочно и важно».
4. Сосредоточьтесь на одной задаче за раз
Многозадачность — миф, особенно для разработчиков. Переключение контекста между задачами написания кода особенно затратно с когнитивной точки зрения. Как только вы определили самую приоритетную задачу:
- Закройте ненужные вкладки и приложения;
- Блокируйте отвлекающие факторы (email, телефон, мессенджеры и т.д.);
- Установите таймер для сосредоточенной работы («помидорный график» хорошо подходит многим разработчикам);
- Работайте над этой единственной задачей до её завершения или до тех пор, пока не достигнете логической точки остановки.
5. Сообщите приоритеты и установите ожидания
Когда вы не можете сделать всё сразу (а вы не можете), становится важным чёткое общение:
- Сообщите заинтересованным сторонам о ваших текущих приоритетах и о том, почему вы расположили задачи в определённом порядке;
- Укажите реалистичные сроки для менее приоритетных задач;
- При необходимости обсудите сроки;
- Будьте прозрачны в отношении ограничений ваших физических способностей.
Большинство разумных членов команды поймут решения по расстановке приоритетов, если вы чётко объясните свои доводы.
Инструменты
Правильные инструменты могут значительно упростить процесс.
1. Платформы управления проектами
Предоставляют централизованное рабочее пространство для визуализации, организации и расстановки приоритетов задач. Некоторые платформы, такие как Teamcamp помогают отслеживать и анализировать время. Такие инструменты помогут вам:
- Определить, какие задачи постоянно занимают больше времени, чем ожидалось;
- Распознать закономерности в вашей производительности;
- Делать более точные оценки для будущей работы;
- Обосновывать решения по расстановке приоритетов с помощью данных.
2. Инструменты автоматизации
Автоматизируя повторяющиеся задачи, вы освобождаете умственное пространство и время для важной работы:
- Настройте конвейеры CI/CD для автоматизации тестирования и развёртывания;
- Создайте скрипты для распространённых шаблонов кода;
- Используйте чат-ботов для рутинных коммуникаций;
- Внедрите автоматизированные проверки кода.
Каждая задача, которую вы автоматизируете, — это на одну задачу меньше, в конкуренции за ваше внимание.
Окончание следует…
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
День 2297. #Карьера
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Окончание
Начало
Продолжение
Стратегии приоритизации для разработчиков
1. Метод Айви Ли
- В конце каждого рабочего дня записывайте 6 самых важных задач на завтра.
- Расположите эти задачи в порядке важности.
- Когда вы начнёте работу на следующий день, сосредоточьтесь исключительно на первой задаче, пока она не будет завершена.
- Переходите к следующей задаче только после завершения предыдущей.
- Перемещайте все незавершённые задачи в список на завтра.
- Повторяйте ежедневно.
2. Блокировка времени для работы «в потоке»
Разработчикам нужно непрерывное время для сложных задач. Попробуйте этот подход:
- Определите 2–3 самые приоритетные задачи на день.
- Выделите 90–120-минутные отрезки в графике для сосредоточенной работы над этими задачами.
- Установите статус «Не беспокоить» на эти периоды.
- Сгруппируйте встречи и административную работу в другие временные блоки.
- Оставляйте буферное время между блоками для непредвиденных проблем.
3. Правило 1–3–5
Помогает поддерживать реалистичные ожидания относительно того, что вы можете сделать за день. Планируйте выполнение:
- 1 большой задачи;
- 3 средних задач;
- 5 небольших задач.
Этот подход признаёт, что не все задачи требуют одинакового количества времени или умственной энергии, что помогает вам создать более сбалансированный и достижимый ежедневный план.
4. Когда сказать «нет» (и как это сделать)
Иногда лучшая стратегия расстановки приоритетов — научиться говорить «нет» новым задачам, когда вы по уши в работе. Это может быть особенно сложно для разработчиков, но это важно для поддержания фокуса и качества.
Когда поступает новый «срочный» запрос:
- Оцените, как он соотносится с текущими приоритетами.
- Если он действительно более важен, объясните, какая текущая задача будет отложена в результате.
- Если он менее важен, объясните свои текущие приоритеты и когда вы могли бы разумно взяться за новую задачу.
- Предложите альтернативы (Может ли кто-то другой справиться с этим? Можно ли это упростить? Можно ли отодвинуть срок?)
Помните: говорить «да» каждый раз тоже невыгодно, поэтому говорить «нет» новой работе означает, что вы заботитесь о том, чтобы качественно выполнять ту работу, которая действительно важна.
Итого
Эффективная расстановка приоритетов — это не разовое упражнение, а постоянная практика. Чтобы построить устойчивую систему:
- Ежедневно пересматривайте приоритеты: тратьте 10 минут каждое утро на оценку того, что заслуживает внимания сегодня.
- Проводите еженедельное планирование: тратьте 30 минут в начале каждой недели на то, чтобы согласовать свои задачи с более широкими целями.
- Обдумывайте и корректируйте: в конце каждой недели оценивайте, что сработало, а что нет в вашем подходе к расстановке приоритетов.
Помните: вы не можете сделать всё сразу, но при правильном подходе к расстановке приоритетов вы можете быть уверены, что всегда работаете над тем, что действительно важно.
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
Как Расставлять Приоритеты Задач, Когда Всё Кажется Срочным. Окончание
Начало
Продолжение
Стратегии приоритизации для разработчиков
1. Метод Айви Ли
- В конце каждого рабочего дня записывайте 6 самых важных задач на завтра.
- Расположите эти задачи в порядке важности.
- Когда вы начнёте работу на следующий день, сосредоточьтесь исключительно на первой задаче, пока она не будет завершена.
- Переходите к следующей задаче только после завершения предыдущей.
- Перемещайте все незавершённые задачи в список на завтра.
- Повторяйте ежедневно.
2. Блокировка времени для работы «в потоке»
Разработчикам нужно непрерывное время для сложных задач. Попробуйте этот подход:
- Определите 2–3 самые приоритетные задачи на день.
- Выделите 90–120-минутные отрезки в графике для сосредоточенной работы над этими задачами.
- Установите статус «Не беспокоить» на эти периоды.
- Сгруппируйте встречи и административную работу в другие временные блоки.
- Оставляйте буферное время между блоками для непредвиденных проблем.
3. Правило 1–3–5
Помогает поддерживать реалистичные ожидания относительно того, что вы можете сделать за день. Планируйте выполнение:
- 1 большой задачи;
- 3 средних задач;
- 5 небольших задач.
Этот подход признаёт, что не все задачи требуют одинакового количества времени или умственной энергии, что помогает вам создать более сбалансированный и достижимый ежедневный план.
4. Когда сказать «нет» (и как это сделать)
Иногда лучшая стратегия расстановки приоритетов — научиться говорить «нет» новым задачам, когда вы по уши в работе. Это может быть особенно сложно для разработчиков, но это важно для поддержания фокуса и качества.
Когда поступает новый «срочный» запрос:
- Оцените, как он соотносится с текущими приоритетами.
- Если он действительно более важен, объясните, какая текущая задача будет отложена в результате.
- Если он менее важен, объясните свои текущие приоритеты и когда вы могли бы разумно взяться за новую задачу.
- Предложите альтернативы (Может ли кто-то другой справиться с этим? Можно ли это упростить? Можно ли отодвинуть срок?)
Помните: говорить «да» каждый раз тоже невыгодно, поэтому говорить «нет» новой работе означает, что вы заботитесь о том, чтобы качественно выполнять ту работу, которая действительно важна.
Итого
Эффективная расстановка приоритетов — это не разовое упражнение, а постоянная практика. Чтобы построить устойчивую систему:
- Ежедневно пересматривайте приоритеты: тратьте 10 минут каждое утро на оценку того, что заслуживает внимания сегодня.
- Проводите еженедельное планирование: тратьте 30 минут в начале каждой недели на то, чтобы согласовать свои задачи с более широкими целями.
- Обдумывайте и корректируйте: в конце каждой недели оценивайте, что сработало, а что нет в вашем подходе к расстановке приоритетов.
Помните: вы не можете сделать всё сразу, но при правильном подходе к расстановке приоритетов вы можете быть уверены, что всегда работаете над тем, что действительно важно.
Источник: https://dev.to/teamcamp/how-to-prioritize-tasks-when-everything-feels-urgent-a-developers-guide-3d6o
День 2298. #TipsAndTricks
Очистка Кэшей NuGet
NuGet может кэшировать множество пакетов и других вещей с течением времени. Сегодня рассмотрим, как очистить большинство из этого.
Вы можете посмотреть используемые кэши и их местонахождения, выполнив следующую команду:
Вывод будет примерно таким:
Со временем там накапливается гигантский объём данных. У меня http-cache больше 2ГБ, а global-packages больше 20ГБ. Если у вас достаточно места, можете оставить всё как есть. Это просто кэшированные данные, которые на самом деле безвредны (кроме занятого места).
Кэш NuGet-пакетов
Папка global-packages — это то место, куда dotnet restore помещает все пакеты пользователя. Поэтому неважно, в каком репозитории вы находитесь, он всегда загружает каждый пакет (конечно, включая все зависимости, которые требуются пакету) в эту папку. Преимущество в том, что, если только это не nodejs и npm, у вас будет супербыстрое восстановление для пакетов, которые уже загружены и не являются локальными для вашего репозитория.
Чтобы удалить кэш (что приведёт к повторной загрузке требуемых пакетов), вы можете либо очистить содержимое папки, либо просто вызвать:
Кэш Http
То же самое относится к http-cache. По сути, он хранит метаданные в пакетов (например, в каких версиях они существуют в NuGet), но также, похоже, содержит некоторые бинарные файлы. В любом случае, если вы хотите удалить это:
Временные данные
Папка temp хранит временные файлы. Очистить её можно так:
Удалить всё
Следующая команда удалит все кэшированные данные NuGet:
После этого, при создании нового приложения, все данные NuGet будут скачаны заново из интернета. Но это также уберёт всё ненужное!
Источник: https://steven-giesel.com/blogPost/ef7e9271-3b8d-4658-988f-b48bbd11e320/clearing-nuget-caches
Очистка Кэшей NuGet
NuGet может кэшировать множество пакетов и других вещей с течением времени. Сегодня рассмотрим, как очистить большинство из этого.
Вы можете посмотреть используемые кэши и их местонахождения, выполнив следующую команду:
dotnet nuget locals all --list
Вывод будет примерно таким:
http-cache: C:\Users\sbenz\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\sbenz\.nuget\packages\
temp: C:\Users\sbenz\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\sbenz\AppData\Local\NuGet\plugins-cache
Со временем там накапливается гигантский объём данных. У меня http-cache больше 2ГБ, а global-packages больше 20ГБ. Если у вас достаточно места, можете оставить всё как есть. Это просто кэшированные данные, которые на самом деле безвредны (кроме занятого места).
Кэш NuGet-пакетов
Папка global-packages — это то место, куда dotnet restore помещает все пакеты пользователя. Поэтому неважно, в каком репозитории вы находитесь, он всегда загружает каждый пакет (конечно, включая все зависимости, которые требуются пакету) в эту папку. Преимущество в том, что, если только это не nodejs и npm, у вас будет супербыстрое восстановление для пакетов, которые уже загружены и не являются локальными для вашего репозитория.
Чтобы удалить кэш (что приведёт к повторной загрузке требуемых пакетов), вы можете либо очистить содержимое папки, либо просто вызвать:
dotnet nuget locals global-packages --clear
Кэш Http
То же самое относится к http-cache. По сути, он хранит метаданные в пакетов (например, в каких версиях они существуют в NuGet), но также, похоже, содержит некоторые бинарные файлы. В любом случае, если вы хотите удалить это:
dotnet nuget locals http-cache --clear
Временные данные
Папка temp хранит временные файлы. Очистить её можно так:
dotnet nuget locals temp --clear
Удалить всё
Следующая команда удалит все кэшированные данные NuGet:
dotnet nuget locals all --clear
После этого, при создании нового приложения, все данные NuGet будут скачаны заново из интернета. Но это также уберёт всё ненужное!
Источник: https://steven-giesel.com/blogPost/ef7e9271-3b8d-4658-988f-b48bbd11e320/clearing-nuget-caches
День 2299. #Оффтоп
Доброй субботы, дорогие подписчики. Давно не рекомендовал вам познавательных видосиков. Я обожаю истории про историю (извините за тавтологию) развития компьютеров и программирования. И сегодня порекомендую вам одну из таких ламповых – в прямом смысле – историй.
Как появились первые диоды и триоды? Почему алгебру логики называют булевой? Как «считают» компьютеры на самом нижнем уровне? Сколько энергии потреблял первый ЭНИАК?
Об этом и не только в видео с канала Veritasium. Приятного просмотра.
https://youtu.be/FU_YFpfDqqA
(видео с переводом на русский здесь)
А для тех, кому захочется ещё больше углубиться в историю и узнать про аналоговые компьютеры, вот видео в двух частях: часть 1, часть 2 (видео с переводом на русский: часть 1, часть 2).
Доброй субботы, дорогие подписчики. Давно не рекомендовал вам познавательных видосиков. Я обожаю истории про историю (извините за тавтологию) развития компьютеров и программирования. И сегодня порекомендую вам одну из таких ламповых – в прямом смысле – историй.
Как появились первые диоды и триоды? Почему алгебру логики называют булевой? Как «считают» компьютеры на самом нижнем уровне? Сколько энергии потреблял первый ЭНИАК?
Об этом и не только в видео с канала Veritasium. Приятного просмотра.
https://youtu.be/FU_YFpfDqqA
(видео с переводом на русский здесь)
А для тех, кому захочется ещё больше углубиться в историю и узнать про аналоговые компьютеры, вот видео в двух частях: часть 1, часть 2 (видео с переводом на русский: часть 1, часть 2).
YouTube
Why The First Computers Were Made Out Of Light Bulbs
How were the first computers made? Head to https://brilliant.org/veritasium to start your free 30-day trial, and the first 200 people get 20% off an annual premium subscription.
A huge thanks to David Lovett for showing me his awesome relay and vacuum tube…
A huge thanks to David Lovett for showing me his awesome relay and vacuum tube…
День 2300. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Начало
Разочарование неутешительными результатами — мощная мотивация попробовать другой подход. Однако при этом важно иметь уверенность, что любая новая стратегия, которую вы примете, имеет хорошие шансы на успех в решении вашей проблемы. Организации иногда выбирают модные решения и горячие новинки в области разработки ПО, считая их волшебным эликсиром, способным решить их задачи.
Руководитель может прочитать о многообещающей, но, возможно, чересчур разрекламированной методологии и настаивать на немедленном принятии её в организации. Этот феномен называют «менеджмент по Businessweek». Либо разработчик, посетив конференцию, узнаёт о новом способе решения своих задач и торопится попробовать его. Стремление к совершенствованию похвально, но вы должны направить эту энергию в правильное русло и оценить, насколько хорошо потенциальное решение соответствует вашей культуре, прежде чем принять его.
За прошедшие годы люди изобрели бесчисленное множество парадигм, методологий и систем управления разработкой ПО:
- анализ и проектирование структурированных систем;
- объектно-ориентированное программирование;
- информационная инженерия;
- быстрая разработка приложений;
- спиральная модель;
- разработка через тестирование;
- рациональный унифицированный процесс;
- DevOps.
Методология Agile-разработки во многих её вариациях (экстремальное программирование, адаптивная разработка, разработка на основе функциональности, Scrum, Lean, Kanban, Scaled Agile Framework и др.) ещё один пример стремления к идеальным решениям.
Увы, как учит дядюшка Брукс, «серебряной пули не существует». Все вышеперечисленные подходы имеют свои достоинства и недостатки и должны применяться к соответствующим задачам правильно подготовленными командами и руководителями. В качестве примера далее рассмотрим некий новый подход к разработке ПО под названием «Метод Х».
Сначала проблема, потом решение
В статьях и книгах, написанных изобретателями и первыми последователями «Метода Х», восхвалялись его преимущества. Некоторые компании выбрали «Метод Х», желая создавать продукты, которые лучше удовлетворяют потребности клиентов. Хотите быстрее доставлять полезное ПО? (А кто не хочет?) «Метод Х» поможет в этом. Хотите уменьшить количество дефектов, раздражающих клиентов и отнимающих у команды время на доработку? (Опять же, кто не хочет?) «Метод Х» придёт на помощь! В этом суть совершенствования процессов: постановка целей, выявление препятствий и выбор методов, которые, по вашему мнению, могут помочь их устранить.
Однако прежде, чем выбрать какой-либо новый подход к разработке, спросите себя: «Что мешает нам добиться таких же результатов, которые он обещает, уже сегодня?» Если вы хотите быстрее доставлять продукты, что вам мешает? Если цель — уменьшить количество дефектов, то почему сегодня их много? И т.п. Т.е., если «Метод Х» является решением проблем, в чём их причина?
Не все организации тщательно анализируют первопричины, прежде чем хвататься за решения, выглядящие многообещающими. Постановка целей совершенствования — отличное начало, но, помимо этого, важно понимать, какие препятствия стоят на пути к этим целям. Лечить нужно причины, а не симптомы. Если вы не понимаете причины проблем, то выбор любого нового подхода — выстрел в пустоту.
Предположим, вы хотите поставлять программные продукты, хорошо удовлетворяющие потребности клиентов. Вы прочитали, что в командах, применяющих «Метод Х», есть роль под названием «гуру», который отвечает за то, чтобы продукт достиг желаемого результата. «Отлично! — думаете вы. — Гуру позаботится о том, чтобы мы создали правильный продукт. Клиенты будут счастливы». Проблема решена? Может быть, но, прежде чем изменять процессы, ваша команда должна понять, почему ваши продукты не вызывают восторга у клиентов уже сейчас.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Начало
Разочарование неутешительными результатами — мощная мотивация попробовать другой подход. Однако при этом важно иметь уверенность, что любая новая стратегия, которую вы примете, имеет хорошие шансы на успех в решении вашей проблемы. Организации иногда выбирают модные решения и горячие новинки в области разработки ПО, считая их волшебным эликсиром, способным решить их задачи.
Руководитель может прочитать о многообещающей, но, возможно, чересчур разрекламированной методологии и настаивать на немедленном принятии её в организации. Этот феномен называют «менеджмент по Businessweek». Либо разработчик, посетив конференцию, узнаёт о новом способе решения своих задач и торопится попробовать его. Стремление к совершенствованию похвально, но вы должны направить эту энергию в правильное русло и оценить, насколько хорошо потенциальное решение соответствует вашей культуре, прежде чем принять его.
За прошедшие годы люди изобрели бесчисленное множество парадигм, методологий и систем управления разработкой ПО:
- анализ и проектирование структурированных систем;
- объектно-ориентированное программирование;
- информационная инженерия;
- быстрая разработка приложений;
- спиральная модель;
- разработка через тестирование;
- рациональный унифицированный процесс;
- DevOps.
Методология Agile-разработки во многих её вариациях (экстремальное программирование, адаптивная разработка, разработка на основе функциональности, Scrum, Lean, Kanban, Scaled Agile Framework и др.) ещё один пример стремления к идеальным решениям.
Увы, как учит дядюшка Брукс, «серебряной пули не существует». Все вышеперечисленные подходы имеют свои достоинства и недостатки и должны применяться к соответствующим задачам правильно подготовленными командами и руководителями. В качестве примера далее рассмотрим некий новый подход к разработке ПО под названием «Метод Х».
Сначала проблема, потом решение
В статьях и книгах, написанных изобретателями и первыми последователями «Метода Х», восхвалялись его преимущества. Некоторые компании выбрали «Метод Х», желая создавать продукты, которые лучше удовлетворяют потребности клиентов. Хотите быстрее доставлять полезное ПО? (А кто не хочет?) «Метод Х» поможет в этом. Хотите уменьшить количество дефектов, раздражающих клиентов и отнимающих у команды время на доработку? (Опять же, кто не хочет?) «Метод Х» придёт на помощь! В этом суть совершенствования процессов: постановка целей, выявление препятствий и выбор методов, которые, по вашему мнению, могут помочь их устранить.
Однако прежде, чем выбрать какой-либо новый подход к разработке, спросите себя: «Что мешает нам добиться таких же результатов, которые он обещает, уже сегодня?» Если вы хотите быстрее доставлять продукты, что вам мешает? Если цель — уменьшить количество дефектов, то почему сегодня их много? И т.п. Т.е., если «Метод Х» является решением проблем, в чём их причина?
Не все организации тщательно анализируют первопричины, прежде чем хвататься за решения, выглядящие многообещающими. Постановка целей совершенствования — отличное начало, но, помимо этого, важно понимать, какие препятствия стоят на пути к этим целям. Лечить нужно причины, а не симптомы. Если вы не понимаете причины проблем, то выбор любого нового подхода — выстрел в пустоту.
Предположим, вы хотите поставлять программные продукты, хорошо удовлетворяющие потребности клиентов. Вы прочитали, что в командах, применяющих «Метод Х», есть роль под названием «гуру», который отвечает за то, чтобы продукт достиг желаемого результата. «Отлично! — думаете вы. — Гуру позаботится о том, чтобы мы создали правильный продукт. Клиенты будут счастливы». Проблема решена? Может быть, но, прежде чем изменять процессы, ваша команда должна понять, почему ваши продукты не вызывают восторга у клиентов уже сейчас.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
День 2301. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Окончание
Начало
Анализ первопричин — это процесс размышлений, когда несколько раз задаётся вопрос «почему?», пока вы не доберётесь до проблем, на которые можно воздействовать с помощью тщательно подобранных действий по улучшению. Первая найденная причина может не оказывать прямого влияния и не быть первопричиной. Следовательно, её устранение не решит проблему. Вам нужно спросить «почему?» еще раз или два, чтобы убедиться, что вы добрались до основания дерева анализа.
На рисунке выше показан фрагмент диаграммы «Рыбий скелет» (диаграмма Исикавы) — удобного способа анализа первопричин. Ваша цель — выпускать продукты, лучше удовлетворяющие потребности клиентов. Напишите эту цель вдоль длинной горизонтальной линии. Это представляет вашу основную проблему. Затем спросите команду: «Почему мы не удовлетворяем потребности наших клиентов?» Один из возможных ответов: команда не получает адекватной информации о требованиях от конечных пользователей — обычная ситуация. Запишите эту причину вдоль диагональной линии, отходящей от формулировки цели. Хорошо, но решение проблемы требует более глубокого понимания. Поэтому далее вы спрашиваете: «Почему мы не получаем такой информации?» Один из членов группы говорит: «Мы пытались поговорить с реальными пользователями, но их руководители говорят, что они слишком заняты, чтобы работать с командой разработчиков». Кто-то ещё жалуется, что представители клиента, работающие с командой, не имеют полного представления о реальных потребностях конечных пользователей. Напишите эти причины второго уровня вдоль горизонтальных линий, отходящих от диагональной линии родительской проблемы.
Кто-то отмечает, что разработчики задают представителям клиента неправильные вопросы: «Почему задаются неправильные вопросы?» Причин может быть несколько, в том числе отсутствие образования или интереса у разработчиков к работе с требованиями. Возможно, бизнес-анализ не является основным навыком команды или в команде нет подготовленного бизнес-аналитика. Каждая причина записывается вдоль новой диагональной линии, соединяющейся с родительской.
Так вы приближаетесь к фактическим препятствиям, стоящим на пути к желаемой цели. Продолжайте анализ до тех пор, пока участники не придут к полному пониманию, почему не достигаются желаемые результаты. Такая диаграмма может стать неразборчивой, поэтому попробуйте записать причины на стикерах, чтобы их можно было перетасовывать по мере исследования.
Постановка диагноза ведёт к излечению
Дальше стоит перейти к поиску практических решений для устранения этих первопричин. Возможно, вы решите, что добавление бизнес-аналитика в команду более ценно, чем принятие «Метода Х» с его «гуру». Или вам нужна комбинация этих двух методов. Вы не узнаете этого, пока не продумаете всё до конца.
Вот несколько хороших вопросов, которые следует задать себе:
- Потребуется ли команде обучение, инструменты или консультации, чтобы начать работу и двигаться вперед?
- Принесёт ли решение выгоду по сравнению с вложениями?
- Какое культурное влияние окажет переход к новым методам на вашу команду, клиентов и их организации?
- Насколько крутой может быть кривая обучения?
Результаты анализа первопричин могут помочь выявить более эффективные методы решения каждой обнаруженной проблемы. Это разумное вложение средств в концентрацию усилий по совершенствованию процессов. Прежде, чем назначать лечение, нужно поставить диагноз.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Окончание
Начало
Анализ первопричин — это процесс размышлений, когда несколько раз задаётся вопрос «почему?», пока вы не доберётесь до проблем, на которые можно воздействовать с помощью тщательно подобранных действий по улучшению. Первая найденная причина может не оказывать прямого влияния и не быть первопричиной. Следовательно, её устранение не решит проблему. Вам нужно спросить «почему?» еще раз или два, чтобы убедиться, что вы добрались до основания дерева анализа.
На рисунке выше показан фрагмент диаграммы «Рыбий скелет» (диаграмма Исикавы) — удобного способа анализа первопричин. Ваша цель — выпускать продукты, лучше удовлетворяющие потребности клиентов. Напишите эту цель вдоль длинной горизонтальной линии. Это представляет вашу основную проблему. Затем спросите команду: «Почему мы не удовлетворяем потребности наших клиентов?» Один из возможных ответов: команда не получает адекватной информации о требованиях от конечных пользователей — обычная ситуация. Запишите эту причину вдоль диагональной линии, отходящей от формулировки цели. Хорошо, но решение проблемы требует более глубокого понимания. Поэтому далее вы спрашиваете: «Почему мы не получаем такой информации?» Один из членов группы говорит: «Мы пытались поговорить с реальными пользователями, но их руководители говорят, что они слишком заняты, чтобы работать с командой разработчиков». Кто-то ещё жалуется, что представители клиента, работающие с командой, не имеют полного представления о реальных потребностях конечных пользователей. Напишите эти причины второго уровня вдоль горизонтальных линий, отходящих от диагональной линии родительской проблемы.
Кто-то отмечает, что разработчики задают представителям клиента неправильные вопросы: «Почему задаются неправильные вопросы?» Причин может быть несколько, в том числе отсутствие образования или интереса у разработчиков к работе с требованиями. Возможно, бизнес-анализ не является основным навыком команды или в команде нет подготовленного бизнес-аналитика. Каждая причина записывается вдоль новой диагональной линии, соединяющейся с родительской.
Так вы приближаетесь к фактическим препятствиям, стоящим на пути к желаемой цели. Продолжайте анализ до тех пор, пока участники не придут к полному пониманию, почему не достигаются желаемые результаты. Такая диаграмма может стать неразборчивой, поэтому попробуйте записать причины на стикерах, чтобы их можно было перетасовывать по мере исследования.
Постановка диагноза ведёт к излечению
Дальше стоит перейти к поиску практических решений для устранения этих первопричин. Возможно, вы решите, что добавление бизнес-аналитика в команду более ценно, чем принятие «Метода Х» с его «гуру». Или вам нужна комбинация этих двух методов. Вы не узнаете этого, пока не продумаете всё до конца.
Вот несколько хороших вопросов, которые следует задать себе:
- Потребуется ли команде обучение, инструменты или консультации, чтобы начать работу и двигаться вперед?
- Принесёт ли решение выгоду по сравнению с вложениями?
- Какое культурное влияние окажет переход к новым методам на вашу команду, клиентов и их организации?
- Насколько крутой может быть кривая обучения?
Результаты анализа первопричин могут помочь выявить более эффективные методы решения каждой обнаруженной проблемы. Это разумное вложение средств в концентрацию усилий по совершенствованию процессов. Прежде, чем назначать лечение, нужно поставить диагноз.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
День 2302. #ЧтоНовенького #TipsAndTricks
Используем Расширения C# 14 для Парсинга Enum
Расширения ещё только в планах для C# 14, а умельцы уже предлагают интересные варианты их использования.
В .NET многие типы предоставляют статический метод Parse для преобразования строк в соответствующие им типы. Например:
В перечислениях используется обобщённый метод Enum.Parse:
А вот это не сработает:
Было бы более интуитивно понятно, если бы перечисления поддерживали метод Parse напрямую. С помощью C# 14 и его новой функции членов-расширений мы можем этого добиться.
Следующий код демонстрирует, как добавить методы Parse и TryParse к перечислениям с использованием расширений C# 14:
Теперь мы можем использовать методы Parse/TryParse для самого типа enum, так же как мы это делаем для других типов:
Источник: https://www.meziantou.net/use-csharp-14-extensions-to-simplify-enum-parsing.htm
Используем Расширения C# 14 для Парсинга Enum
Расширения ещё только в планах для C# 14, а умельцы уже предлагают интересные варианты их использования.
В .NET многие типы предоставляют статический метод Parse для преобразования строк в соответствующие им типы. Например:
int.Parse("123");
double.Parse("123.45");
DateTime.Parse("2023-01-01");
IPAddress.Parse("192.168.0.1");В перечислениях используется обобщённый метод Enum.Parse:
Enum.Parse<MyEnum>("Value1");А вот это не сработает:
MyEnum.Parse("Value1");Было бы более интуитивно понятно, если бы перечисления поддерживали метод Parse напрямую. С помощью C# 14 и его новой функции членов-расширений мы можем этого добиться.
Следующий код демонстрирует, как добавить методы Parse и TryParse к перечислениям с использованием расширений C# 14:
static class EnumExtensions
{
extension<T>(T _) where T : struct, Enum
{
public static T Parse(string value)
=> Enum.Parse<T>(value);
public static T Parse(string value, bool ignoreCase)
=> Enum.Parse<T>(value, ignoreCase);
public static T Parse(ReadOnlySpan<char> value)
=> Enum.Parse<T>(value);
public static T Parse(
ReadOnlySpan<char> value,
bool ignoreCase)
=> Enum.Parse<T>(value, ignoreCase);
public static bool TryParse(
[NotNullWhen(true)] string? value,
out T result)
=> Enum.TryParse(value, out result);
public static bool TryParse(
[NotNullWhen(true)] string? value,
bool ignoreCase,
out T result)
=> Enum.TryParse(value, ignoreCase, out result);
public static bool TryParse(
ReadOnlySpan<char> value,
out T result)
=> Enum.TryParse(value, out result);
public static bool TryParse(
ReadOnlySpan<char> value,
bool ignoreCase,
out T result)
=> Enum.TryParse(value, ignoreCase, out result);
}
}
Теперь мы можем использовать методы Parse/TryParse для самого типа enum, так же как мы это делаем для других типов:
MyEnum.Parse("Value1");
if (MyEnum.TryParse("Value1", out var result))
{
//…
}Источник: https://www.meziantou.net/use-csharp-14-extensions-to-simplify-enum-parsing.htm
День 2303. #ЗаметкиНаПолях
AsyncEnumerable в C#: Важность Атрибута EnumeratorCancellation
Сегодня рассмотрим IAsyncEnumerable<T> и почему атрибут EnumeratorCancellation для параметра CancellationToken имеет решающее значение для написания надёжного отменяемого асинхронного кода.
IAsyncEnumerable<T> — это асинхронный аналог IEnumerable<T> (см. подробнее про создание и потребление асинхронных потоков).
IAsyncEnumerable<T> позволяет:
- Выполнять асинхронные операции во время итерации последовательности;
- Выдавать результаты по мере их появления;
- Обрабатывать отмену.
Необходимость отмены
Поддержка отмены в асинхронных операциях нужна в следующих сценариях:
- Пользователь уходит с веб-страницы, которая извлекает данные;
- Операция поиска занимает слишком много времени, и пользователь отменяет её;
- Сервис завершает работу во время выполнения операций.
Без надлежащей поддержки отмены ресурсы могут быть потрачены впустую, а приложения могут перестать отвечать или произойдёт утечка ресурсов.
Атрибут EnumeratorCancellation
При применении к параметру CancellationToken в методе асинхронного итератора этот атрибут сообщает компилятору о необходимости передать этот токен методу GetAsyncEnumerator, когда итератор используется через await foreach. Вот простой пример:
Использование метода через вызов WithCancellation:
Без атрибута EnumeratorCancellation существует разрыв между токеном отмены, переданным в метод асинхронного итератора, и токеном, переданным в GetAsyncEnumerator при потреблении перечисляемого объекта. Атрибут EnumeratorCancellation гарантирует, что этот токен попадёт в метод асинхронного итератора, позволяя вам реагировать на запросы отмены от потребителя.
Чтобы помочь вам избежать этой ошибки, компилятор выдает предупреждение CS8425 в качестве напоминания о правильной реализации отмены в ваших методах асинхронного итератора:
CS8425: Async-iterator method 'MyMethod' has parameters that are declared with 'CancellationToken' but are not decorated with the 'EnumeratorCancellation' attribute, and will not be passed the cancellation token from 'WithCancellation' method calls
CS8425: Метод асинхронного итератора 'MyMethod' имеет параметры, объявленные с 'CancellationToken', но не декорированные атрибутом 'EnumeratorCancellation', и ему не будет передан токен отмены из вызовов метода 'WithCancellation'.
Предупреждение возникает, когда вы определяете метод асинхронного итератора, который возвращает IAsyncEnumerable<T> и включает параметр CancellationToken, но вы не декорировали этот параметр атрибутом [EnumeratorCancellation].
Игнорирование этого предупреждения может привести к неявным ошибкам, когда отмена, кажется, реализована, но на самом деле не работает. Код будет компилироваться и запускаться, но запросы на отмену от потребителей будут игнорироваться.
Итого
При работе с асинхронными потоками:
- Используйте атрибут EnumeratorCancellation для параметров токена отмены;
- Регулярно проверяйте отмену;
- Распространяйте токен на внутренние операции;
- Обратите внимание на предупреждение компилятора CS8425, поскольку оно указывает на потенциальную проблему отмены.
Источник: https://bartwullems.blogspot.com/2025/04/asyncenumerable-in-c-importance-of.html
AsyncEnumerable в C#: Важность Атрибута EnumeratorCancellation
Сегодня рассмотрим IAsyncEnumerable<T> и почему атрибут EnumeratorCancellation для параметра CancellationToken имеет решающее значение для написания надёжного отменяемого асинхронного кода.
IAsyncEnumerable<T> — это асинхронный аналог IEnumerable<T> (см. подробнее про создание и потребление асинхронных потоков).
IAsyncEnumerable<T> позволяет:
- Выполнять асинхронные операции во время итерации последовательности;
- Выдавать результаты по мере их появления;
- Обрабатывать отмену.
Необходимость отмены
Поддержка отмены в асинхронных операциях нужна в следующих сценариях:
- Пользователь уходит с веб-страницы, которая извлекает данные;
- Операция поиска занимает слишком много времени, и пользователь отменяет её;
- Сервис завершает работу во время выполнения операций.
Без надлежащей поддержки отмены ресурсы могут быть потрачены впустую, а приложения могут перестать отвечать или произойдёт утечка ресурсов.
Атрибут EnumeratorCancellation
При применении к параметру CancellationToken в методе асинхронного итератора этот атрибут сообщает компилятору о необходимости передать этот токен методу GetAsyncEnumerator, когда итератор используется через await foreach. Вот простой пример:
public async IAsyncEnumerable<int>
GenerateNumbersAsync(
int count,
[EnumeratorCancellation]
CancellationToken ct = default)
{
for (int i = 0; i < count; i++)
{
// Проверяем отмену
ct.ThrowIfCancellationRequested();
// Симулируем асинхронную работу
await Task.Delay(100, ct);
yield return i;
}
}
Использование метода через вызов WithCancellation:
CancellationTokenSource cts = new();
await foreach (var item in
GenerateNumbersAsync(10)
.WithCancellation(cts.Token))
{
Console.WriteLine(item);
}
Без атрибута EnumeratorCancellation существует разрыв между токеном отмены, переданным в метод асинхронного итератора, и токеном, переданным в GetAsyncEnumerator при потреблении перечисляемого объекта. Атрибут EnumeratorCancellation гарантирует, что этот токен попадёт в метод асинхронного итератора, позволяя вам реагировать на запросы отмены от потребителя.
Чтобы помочь вам избежать этой ошибки, компилятор выдает предупреждение CS8425 в качестве напоминания о правильной реализации отмены в ваших методах асинхронного итератора:
CS8425: Async-iterator method 'MyMethod' has parameters that are declared with 'CancellationToken' but are not decorated with the 'EnumeratorCancellation' attribute, and will not be passed the cancellation token from 'WithCancellation' method calls
CS8425: Метод асинхронного итератора 'MyMethod' имеет параметры, объявленные с 'CancellationToken', но не декорированные атрибутом 'EnumeratorCancellation', и ему не будет передан токен отмены из вызовов метода 'WithCancellation'.
Предупреждение возникает, когда вы определяете метод асинхронного итератора, который возвращает IAsyncEnumerable<T> и включает параметр CancellationToken, но вы не декорировали этот параметр атрибутом [EnumeratorCancellation].
Игнорирование этого предупреждения может привести к неявным ошибкам, когда отмена, кажется, реализована, но на самом деле не работает. Код будет компилироваться и запускаться, но запросы на отмену от потребителей будут игнорироваться.
Итого
При работе с асинхронными потоками:
- Используйте атрибут EnumeratorCancellation для параметров токена отмены;
- Регулярно проверяйте отмену;
- Распространяйте токен на внутренние операции;
- Обратите внимание на предупреждение компилятора CS8425, поскольку оно указывает на потенциальную проблему отмены.
Источник: https://bartwullems.blogspot.com/2025/04/asyncenumerable-in-c-importance-of.html
День 2304. #ЧтоНовенького
Режим ИИ-Агента в Превью для Visual Studio
Режим ИИ-агента теперь доступен превью VS 17.14. Он позволяет определять задачи с использованием естественного языка, при этом Copilot автономно планирует, редактирует вашу кодовую базу, вызывает инструменты и выполняет итерации для решения проблем. В отличие от Чата Copilot или отдельных правок, режим агента не останавливается на одном предложении или редактировании файла, а работает итеративно до тех пор, пока задача не будет выполнена.
Что может делать режим агента?
Режим агента не просто помогает вам писать код — он помогает вам сделать работу. Всё делается итеративно, то есть Copilot продолжит изучать и выполнять вашу задачу на своём собственном выводе и результатах этого вывода, пока не выполнит ваш запрос. Т.е. режим агента может:
- Автономно определять соответствующий контекст и файлы для редактирования;
- Предлагать вам команды терминала для одобрения и выполнения;
- Выполняться итеративно до тех пор, пока задача не будет выполнена: проверять наличие ошибок и запускать сборки/тесты для проверки результатов;
- Вызывать доверенные инструменты через серверы MCP — включая линтеры, среды исполнения тестовые и статические анализаторы в вашей среде разработки.
Как включить
Режим агента по умолчанию отключен на данном этапе превью. Чтобы включить его в Visual Studio 17.14+ перейдите в раздел поиска функций (
Использование
Режим агента позволяет создавать приложения с нуля, рефакторить код в нескольких файлах, писать и запускать тесты, генерировать документацию, интегрировать новые библиотеки и отвечать на вопросы о сложных кодовых базах. При определении того, является ли режим агента подходящим инструментом для работы, учтите следующее.
1. Область редактирования: режим агента просматривает вашу кодовую базу и определяет соответствующий контекст и файлы для редактирования.
2. Сложность задачи: агент обрабатывает вызовы инструментов и команды терминала, что делает его идеальным для сложных проектов.
3. Длительность: режим агента включает несколько этапов обработки запроса. Получение ответа может занять больше времени, так как он определяет контекст, планирует действие и многое другое.
4. Самостоятельная итерация: агент оценивает результат сгенерированных правок и выполняет итерации несколько раз для решения промежуточных проблем.
5. Множественные запросы: в зависимости от сложности задачи режим агента может привести к нескольким запросам к бэкенду из одного запроса.
Вот несколько примеров запросов для агента:
- Добавить обработку ошибок в этот API;
- Преобразовать этот проект для использования переменных среды;
- Написать тесты для этого класса и исправить всё, что даёт сбой;
- Добавить структурированное ведение журнала с помощью Serilog;
- Заменить HttpClient на IHttpClientFactory.
Важно предоставить агенту достаточный контекст о ваших предпочтительных стандартах кодирования, предпочтениях команды, библиотеках и многом другом. Это можно сделать с помощью пользовательских инструкций (см. документацию).
Серверы MCP
Model Context Protocol (MCP) серверы предоставляют агенту Copilot дополнительный контекст и дают ему доступ к инструментам, данным и ресурсам. MCP позволяют подключать приложения ИИ к другим данным и инструментам без необходимости создания настраиваемого соединения с каждым источником данных. Например, напрямую подключаться к БД и анализировать схемы, извлекать информацию для репозиториев GitHub, такую как проблемы и пул-реквесты, автоматизировать сквозное тестирование с помощью Playwright и т.п.
У Тима Кори появилось видео с примером использования режима агента.
Источник: https://devblogs.microsoft.com/visualstudio/agent-mode-has-arrived-in-preview-for-visual-studio/
Режим ИИ-Агента в Превью для Visual Studio
Режим ИИ-агента теперь доступен превью VS 17.14. Он позволяет определять задачи с использованием естественного языка, при этом Copilot автономно планирует, редактирует вашу кодовую базу, вызывает инструменты и выполняет итерации для решения проблем. В отличие от Чата Copilot или отдельных правок, режим агента не останавливается на одном предложении или редактировании файла, а работает итеративно до тех пор, пока задача не будет выполнена.
Что может делать режим агента?
Режим агента не просто помогает вам писать код — он помогает вам сделать работу. Всё делается итеративно, то есть Copilot продолжит изучать и выполнять вашу задачу на своём собственном выводе и результатах этого вывода, пока не выполнит ваш запрос. Т.е. режим агента может:
- Автономно определять соответствующий контекст и файлы для редактирования;
- Предлагать вам команды терминала для одобрения и выполнения;
- Выполняться итеративно до тех пор, пока задача не будет выполнена: проверять наличие ошибок и запускать сборки/тесты для проверки результатов;
- Вызывать доверенные инструменты через серверы MCP — включая линтеры, среды исполнения тестовые и статические анализаторы в вашей среде разработки.
Как включить
Режим агента по умолчанию отключен на данном этапе превью. Чтобы включить его в Visual Studio 17.14+ перейдите в раздел поиска функций (
Ctrl+Q), выполните поиск «copilot agent», либо перейдите в Tools > Options > GitHub > Copilot (Инструменты > Параметры > GitHub > Copilot) и отметьте флажок Enable Agent mode in chat pane (Включить режим агента в панели чата). Внизу окна чата Copilot переключитесь с Ask на Agent.Использование
Режим агента позволяет создавать приложения с нуля, рефакторить код в нескольких файлах, писать и запускать тесты, генерировать документацию, интегрировать новые библиотеки и отвечать на вопросы о сложных кодовых базах. При определении того, является ли режим агента подходящим инструментом для работы, учтите следующее.
1. Область редактирования: режим агента просматривает вашу кодовую базу и определяет соответствующий контекст и файлы для редактирования.
2. Сложность задачи: агент обрабатывает вызовы инструментов и команды терминала, что делает его идеальным для сложных проектов.
3. Длительность: режим агента включает несколько этапов обработки запроса. Получение ответа может занять больше времени, так как он определяет контекст, планирует действие и многое другое.
4. Самостоятельная итерация: агент оценивает результат сгенерированных правок и выполняет итерации несколько раз для решения промежуточных проблем.
5. Множественные запросы: в зависимости от сложности задачи режим агента может привести к нескольким запросам к бэкенду из одного запроса.
Вот несколько примеров запросов для агента:
- Добавить обработку ошибок в этот API;
- Преобразовать этот проект для использования переменных среды;
- Написать тесты для этого класса и исправить всё, что даёт сбой;
- Добавить структурированное ведение журнала с помощью Serilog;
- Заменить HttpClient на IHttpClientFactory.
Важно предоставить агенту достаточный контекст о ваших предпочтительных стандартах кодирования, предпочтениях команды, библиотеках и многом другом. Это можно сделать с помощью пользовательских инструкций (см. документацию).
Серверы MCP
Model Context Protocol (MCP) серверы предоставляют агенту Copilot дополнительный контекст и дают ему доступ к инструментам, данным и ресурсам. MCP позволяют подключать приложения ИИ к другим данным и инструментам без необходимости создания настраиваемого соединения с каждым источником данных. Например, напрямую подключаться к БД и анализировать схемы, извлекать информацию для репозиториев GitHub, такую как проблемы и пул-реквесты, автоматизировать сквозное тестирование с помощью Playwright и т.п.
У Тима Кори появилось видео с примером использования режима агента.
Источник: https://devblogs.microsoft.com/visualstudio/agent-mode-has-arrived-in-preview-for-visual-studio/
День 2305. #ЧтоНовенького #TipsAndTricks
Используем Расширения C# 14 для Написания Защитных Конструкций
Продолжаем рассматривать примеры применения ещё не вышедших расширений в C# 14 (первая часть тут).
В C# есть много хороших защитных конструкций, расположенных поверх статических классов исключений, таких как ArgumentNullException, ArgumentOutOfRangeException и т.д. Например, ArgumentException.ThrowIfNullOrEmpty, ArgumentException.ThrowIfNullOrWhiteSpace. Теперь мы можем легко их расширить!
Расширения в C#14 позволяют добавлять новые защитные конструкции к существующим классам. Например, если мы хотим иметь такую «жутко полезную» семантику, как: «Выбрасывать исключение, если строка содержит ровно один символ», мы можем сделать что-то вроде этого:
Теперь мы можем использовать этот метод-расширение так:
Он прекрасно вливается в семейство существующих защитных конструкций:
Конечно, это слишком упрощённый пример. Но вы поняли идею. Мы получаем что-то похожее на существующие защитные конструкции.
Заметьте, что до C#14 этого сделать нельзя, т.к. здесь мы использовали статический метод-расширение, который можно вызвать так:
Существующие на данный момент методы-расширения позволяют делать только экземплярные методы, которые пришлось бы вызывать так:
Источник: https://steven-giesel.com/blogPost/e2552b7a-293a-4f46-892f-95a0cd677e4d/writing-new-guards-with-extensions-in-c-14
Используем Расширения C# 14 для Написания Защитных Конструкций
Продолжаем рассматривать примеры применения ещё не вышедших расширений в C# 14 (первая часть тут).
В C# есть много хороших защитных конструкций, расположенных поверх статических классов исключений, таких как ArgumentNullException, ArgumentOutOfRangeException и т.д. Например, ArgumentException.ThrowIfNullOrEmpty, ArgumentException.ThrowIfNullOrWhiteSpace. Теперь мы можем легко их расширить!
Расширения в C#14 позволяют добавлять новые защитные конструкции к существующим классам. Например, если мы хотим иметь такую «жутко полезную» семантику, как: «Выбрасывать исключение, если строка содержит ровно один символ», мы можем сделать что-то вроде этого:
static class EnumExtensions
{
extension(ArgumentException)
{
public static void
ThrowIfHasOneCharacter(
string arg,
[CallerArgumentExpression("arg")]
string? paramName = null)
{
if (arg.Length == 1)
throw new ArgumentException($"Аргумент '{paramName}' не может иметь только один символ.", paramName);
}
}
}
Теперь мы можем использовать этот метод-расширение так:
public void MyMethod(string arg)
{
ArgumentException.ThrowIfHasOneCharacter(arg);
…
}
Он прекрасно вливается в семейство существующих защитных конструкций:
public void MyMethod(string arg)
{
ArgumentException.ThrowIfNullOrEmpty(arg);
ArgumentException.ThrowIfHasOneCharacter(arg);
…
}
Конечно, это слишком упрощённый пример. Но вы поняли идею. Мы получаем что-то похожее на существующие защитные конструкции.
Заметьте, что до C#14 этого сделать нельзя, т.к. здесь мы использовали статический метод-расширение, который можно вызвать так:
ArgumentException.ThrowIfHasOneCharacter(…);
Существующие на данный момент методы-расширения позволяют делать только экземплярные методы, которые пришлось бы вызывать так:
var ex = new ArgumentException();
ex.ThrowIfHasOneCharacter(…);
Источник: https://steven-giesel.com/blogPost/e2552b7a-293a-4f46-892f-95a0cd677e4d/writing-new-guards-with-extensions-in-c-14
День 2306. #ЗаметкиНаПолях
Проверка на null, Которая не Проверяет на null
Рассмотрим следующий код:
Мы сопоставляем массив строк с шаблоном (массив из одного элемента) и, если этот элемент не пустая строка, выводим его. Код красивый и краткий. Но мы внезапно получаем ошибку NullReferenceException во время выполнения.
Посмотрим на пример в SharpLab, что поможет быстро понять, что происходит «под капотом» для подобного синтаксиса.
Вы можете видеть 3 версии проверки по приведённой выше ссылке:
Оказывается, есть различие между шаблоном var (допускает null) и шаблоном не-var. Третий вариант — это шаблон не-null, который делает то же самое (но не требует явного указания типа). Обычно var используется вместо явного типа лишь для удобства чтения, но здесь у нас есть реальная разница в поведении.
Источник: https://ayende.com/blog/202403-B/the-null-check-that-didnt-check-for-nulls
Проверка на null, Которая не Проверяет на null
Рассмотрим следующий код:
string Test1(List<string> strs)
{
if(strs is [var s])
{
if (s.Length > 0)
return s;
}
return string.Join(",", strs);
}
Мы сопоставляем массив строк с шаблоном (массив из одного элемента) и, если этот элемент не пустая строка, выводим его. Код красивый и краткий. Но мы внезапно получаем ошибку NullReferenceException во время выполнения.
Посмотрим на пример в SharpLab, что поможет быстро понять, что происходит «под капотом» для подобного синтаксиса.
Вы можете видеть 3 версии проверки по приведённой выше ссылке:
// if (text.Length > 0)
// нет проверки на null!!!
if(strs is [var s])
// if (text != null && text.Length > 0)
if(strs is [string s])
// if (text != null && text.Length > 0)
if(strs is [{} s])
Оказывается, есть различие между шаблоном var (допускает null) и шаблоном не-var. Третий вариант — это шаблон не-null, который делает то же самое (но не требует явного указания типа). Обычно var используется вместо явного типа лишь для удобства чтения, но здесь у нас есть реальная разница в поведении.
Источник: https://ayende.com/blog/202403-B/the-null-check-that-didnt-check-for-nulls
День 2307. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 52. Не спрашивайте: «Что это даст мне?» Спрашивайте: «Что это даст нам?»
Когда людям предлагают использовать новый подход к разработке, следовать другой процедуре или взяться за неожиданное задание, они инстинктивно задаются вопросом: «Что это даст мне?» Это естественная реакция, но не совсем правильный вопрос. Правильный вопрос: «Что это даст нам?»
«Нам» тут может относиться к остальным членам команды, IT-отделу, компании или даже индустрии, только не к отдельному человеку. Инициативы по внедрению изменений должны учитывать коллективные результаты работы, а не только влияние на продуктивность, эффективность или уровень комфорта каждого человека.
Может показаться, что просьба к занятому коллеге, например проверить вашу работу, не принесёт ему выгоды. Однако все вместе такие усилия позволят команде сэкономить больше времени, и тем самым внести чистый положительный вклад в проект. Ревью кода может занять два-три часа времени каждого участника. Эти часы рецензенты не смогут потратить на выполнение своих обязанностей. Но проверка выявит дефекты, а чем раньше они обнаруживаются, тем дешевле их исправление.
Выгода для команды
Предположим, Ари (бизнес-аналитик) написала несколько страниц требований и попросила троих коллег просмотреть их. Каждый из четверых потратил по часу на изучение материала перед встречей команды, которая тоже длилась час:
затраты на подготовку = 1 час/рецензент × 4 рецензента = 4 часа;
затраты на встречу = 1 час/рецензент × 4 рецензента = 4 часа;
общие затраты на рецензирование = 4 часа + 4 часа = 8 часов
Предположим, в процессе рецензирования обнаружены 24 дефекта разной степени серьёзности и на исправление каждого у Ари ушло в среднем 5 минут:
фактические затраты на доработку = 24 дефекта × 0,0833 часа/дефект = 2 часа
Теперь представьте, что Ари не запросила рецензирование. Дефекты останутся в наборе требований и будут обнаружены позже, при разработке. Ари всё так же придётся исправить их, а другим членам команды — переделывать проектное решение, код, тесты и документацию после исправления дефектов. На все эти работы легко может понадобиться в десять раз больше времени. Стоимость переделки может возрасти ещё, если дефекты попадут в конечный продукт:
потенциальные затраты на доработку = 24 дефекта × 0,833 часа/дефект = 20 часов
То есть это гипотетическое рецензирование требований предотвратило потенциальные затраты 18 часов на доработку на последних этапах реализации проекта. Поэтому минимальная окупаемость затрат на рецензирование составляет 225% (18 часов сэкономленного времени ÷ 8 часов на рецензирование). Многие крупные компании оценивают рентабельность вложений в раннее рецензирование как десятикратную. У вас могут получиться другие цифры, но лишь немногие методы разработки ПО могут десятикратно окупить вложения.
Вносите свой вклад в общее дело
В следующий раз, когда коллега или руководитель попросит вас сделать в проекте что-то, что не принесёт вам личной выгоды, думайте не только о своих интересах. Сотрудники несут ответственность за соблюдение установленных правил и приёмов разработки. Справедливо спросить: «Что нам это даст, если я это сделаю?» На просителе лежит бремя объяснения того, какую пользу всей команде принесет ваш вклад. А вы старайтесь внести свой вклад в общий успех команды.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 52. Не спрашивайте: «Что это даст мне?» Спрашивайте: «Что это даст нам?»
Когда людям предлагают использовать новый подход к разработке, следовать другой процедуре или взяться за неожиданное задание, они инстинктивно задаются вопросом: «Что это даст мне?» Это естественная реакция, но не совсем правильный вопрос. Правильный вопрос: «Что это даст нам?»
«Нам» тут может относиться к остальным членам команды, IT-отделу, компании или даже индустрии, только не к отдельному человеку. Инициативы по внедрению изменений должны учитывать коллективные результаты работы, а не только влияние на продуктивность, эффективность или уровень комфорта каждого человека.
Может показаться, что просьба к занятому коллеге, например проверить вашу работу, не принесёт ему выгоды. Однако все вместе такие усилия позволят команде сэкономить больше времени, и тем самым внести чистый положительный вклад в проект. Ревью кода может занять два-три часа времени каждого участника. Эти часы рецензенты не смогут потратить на выполнение своих обязанностей. Но проверка выявит дефекты, а чем раньше они обнаруживаются, тем дешевле их исправление.
Выгода для команды
Предположим, Ари (бизнес-аналитик) написала несколько страниц требований и попросила троих коллег просмотреть их. Каждый из четверых потратил по часу на изучение материала перед встречей команды, которая тоже длилась час:
затраты на подготовку = 1 час/рецензент × 4 рецензента = 4 часа;
затраты на встречу = 1 час/рецензент × 4 рецензента = 4 часа;
общие затраты на рецензирование = 4 часа + 4 часа = 8 часов
Предположим, в процессе рецензирования обнаружены 24 дефекта разной степени серьёзности и на исправление каждого у Ари ушло в среднем 5 минут:
фактические затраты на доработку = 24 дефекта × 0,0833 часа/дефект = 2 часа
Теперь представьте, что Ари не запросила рецензирование. Дефекты останутся в наборе требований и будут обнаружены позже, при разработке. Ари всё так же придётся исправить их, а другим членам команды — переделывать проектное решение, код, тесты и документацию после исправления дефектов. На все эти работы легко может понадобиться в десять раз больше времени. Стоимость переделки может возрасти ещё, если дефекты попадут в конечный продукт:
потенциальные затраты на доработку = 24 дефекта × 0,833 часа/дефект = 20 часов
То есть это гипотетическое рецензирование требований предотвратило потенциальные затраты 18 часов на доработку на последних этапах реализации проекта. Поэтому минимальная окупаемость затрат на рецензирование составляет 225% (18 часов сэкономленного времени ÷ 8 часов на рецензирование). Многие крупные компании оценивают рентабельность вложений в раннее рецензирование как десятикратную. У вас могут получиться другие цифры, но лишь немногие методы разработки ПО могут десятикратно окупить вложения.
Вносите свой вклад в общее дело
В следующий раз, когда коллега или руководитель попросит вас сделать в проекте что-то, что не принесёт вам личной выгоды, думайте не только о своих интересах. Сотрудники несут ответственность за соблюдение установленных правил и приёмов разработки. Справедливо спросить: «Что нам это даст, если я это сделаю?» На просителе лежит бремя объяснения того, какую пользу всей команде принесет ваш вклад. А вы старайтесь внести свой вклад в общий успех команды.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.