📎 Task.Run внутри ASP.NET пайплайна

Один из самых распространённых антипаттернов в .NET, который выглядит как хорошая практика, но на деле замедляет систему.

Обычный код:

await Task.Run(() => _logger.LogInformation("Processing..."));
await Task.Run(() => MapToDto(entity));
await Task.Run(() => ValidateHeaders(request));

Выглядит современно и async везде.

Что происходит на самом деле

Каждый Task.Run внутри ASP.NET запроса:

— ставит задачу в очередь thread pool
— вызывает context switch
— добавляет scheduling overhead

При этом ASP.NET уже работает на оптимально управляемом thread pool. Вы не освобождаете поток, а создаёте дополнительную нагрузку на планировщик.

Как надо:

// Логирование — всегда синхронно
_logger.LogInformation("Processing...");

// Маппинг — синхронно
var dto = MapToDto(entity);

// Валидация заголовков — синхронно
ValidateHeaders(request);

// async оставляем только для реального I/O
var data = await _repository.GetAsync(id);
var response = await _httpClient.GetAsync(url);

Есть ситуация, где он оправдан: долгая CPU-bound работа, которую нужно вынести за пределы потока запроса, чтобы не блокировать пайплайн.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

⚡️ Никаких больше var

Microsoft официально объявила: в C# 15 ключевое слово var признаётся устаревшим.

Команда языка ссылается на исследования читаемости кода: оказывается, явное указание типов снижает когнитивную нагрузку на 34% и ускоряет код ревью. Roslyn уже умеет автоматически выводить тип, но теперь хочет, чтобы это делал и программист.

Миграция через dotnet-upgrade-assistant проставит типы автоматически. Но 40 000 строк кода всё равно ждут вас в ближайшем будущем.

➡️ Источник

Попались? С первым апреля!😁

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

Читать полностью…

🚫 Span<T> и async несовместимы

Span<T> это ref struct. А ref struct не может существовать в куче. Это не ограничение реализации, это гарантия безопасности по дизайну.

Async-методы компилятор превращает в state machine — объект, который живёт в куче и может приостанавливаться между await-точками. Локальные переменные такого метода становятся полями этого объекта. Поле типа ref struct в объекте на куче — запрещено. Поэтому компилятор просто не даст использовать Span<T> в async-методе.

// Не скомпилируется
async Task ProcessAsync(byte[] data)
{
    Span<byte> span = data; // CS4012: Span нельзя использовать в async
    await Task.Delay(100);
    Process(span);
}

Что происходит под капотом

Компилятор превращает async-метод примерно в это:

// Упрощённо — что генерирует компилятор
private struct ProcessAsyncStateMachine : IAsyncStateMachine
{
    public byte[] data;
    public Span<byte> span; // ← невозможно: ref struct не может быть полем
    public int _state;
    // ...
}

Стек фрейм между await не гарантирован, потому что поток может смениться, метод может возобновиться на другом потоке. Span на стеке к тому моменту уже не существует.

Как работать с данными в async-коде

Memory<T> — это то, для чего он и создан. Может жить в куче, передаётся через await, конвертируется в Span в синхронных участках:

async Task ProcessAsync(Memory<byte> memory)
{
    await Task.Delay(100); // можно
 
    // Span получаем только там, где нет await
    Span<byte> span = memory.Span;
    Process(span);
}

Паттерн: Memory<T> для хранения и передачи через async-границы, Span<T> для фактической работы с данными в синхронном контексте.

async Task<int> ReadAndProcessAsync(Stream stream)
{
    // Memory живёт в куче — await доволен
    var buffer = new byte[4096];
    Memory<byte> memory = buffer;
 
    int bytesRead = await stream.ReadAsync(memory);
 
    // Переходим в sync-контекст — достаём Span
    Span<byte> span = memory.Span[..bytesRead];
    return CountNewlines(span);
}
 
static int CountNewlines(Span<byte> data)
{
    int count = 0;
    foreach (var b in data)
        if (b == '\n') count++;
    return count;
}

Коротко

Span<T> — инструмент для горячего пути в синхронном коде. Как только появляется await переходите на Memory<T> и конвертируйте в Span только там, где он нужен непосредственно для вычислений.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

Читать полностью…

🎶 Разработчик написал программу для управления самодельным проигрывателем винила

Разработчик с Reddit строит автоматический проигрыватель пластинок с нуля: механику, электронику и прошивку для STM32. Чтобы тестировать и отлаживать железо в процессе разработки, он написал десктопное управляющее приложение на C#.

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

Для него это первый опыт написания control software для физического железа и судя по его словам, ощущение от того, что код управляет реальным устройством в реальном мире, совершенно другое.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#entry_point

Читать полностью…

👨‍💻 Разделяемое состояние в многопоточке

Кажется, что примитивы атомарны. Это не так в смысле видимости между потоками: процессор и компилятор переупорядочивают инструкции, каждое ядро держит своё значение в кэше:

private bool _cacheLoaded;

// Поток A
_cacheLoaded = true;

// Поток B — может прочитать false, даже если A уже записал true
if (!_cacheLoaded) LoadCache(); // загружается дважды, данные затираются

Как это исправить

1. lock. Подходит для составных операций: «прочитать → изменить → записать» должны выполняться как одно целое:

private readonly object _sync = new object();
private int _count;

public void Increment()
{
    lock (_sync) { _count++; }
}

2. volatile. Запрещает кэширование значения в регистре. Не заменяет lock. Только для простого чтения/записи одного поля без зависимостей от других.

private volatile bool _cacheLoaded;

3. Interlocked. Атомарная операция на уровне процессора. Быстрее lock, но только для простых числовых операций:

private int _count;

public void Increment()
{
    Interlocked.Increment(ref _count);
}

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

⚙️ Substring или Slice

Substring и Slice выглядят похоже, но работают принципиально по-разному.

Substring — это new string(...). Каждый вызов:

— выделяет новый объект в хипе
— копирует символы в него
— создаёт нагрузку на GC

Slice не создаёт объектов. Это просто новый указатель + длина поверх той же памяти. int.Parse(ReadOnlySpan<char>) читает символы напрямую оттуда.

Частая ошибка

// Так делать не надо — убивает весь смысл
int id = int.Parse(span.Slice(5, 2).ToString());

ToString() на Span создаёт новую строку. Вернулись к исходной проблеме.

Одно правило: если Substring перед Parse это кандидат на замену.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

Читать полностью…

⚙️ Покрытие кода для .NET

Coverlet — инструмент для измерения покрытия кода в .NET-проектах. Он работает на Windows, macOS и Linux, поддерживает .NET Framework и .NET Core, и умеет считать покрытие по строкам, ветвям и методам.

Без инструмента покрытия вы пишете тесты вслепую. Можно потратить часы на тесты, которые проверяют одно и то же, и совсем не касаться критических участков кода.

Coverlet показывает точную картину: вот этот метод не вызывается ни одним тестом, а вот эта ветка if никогда не выполняется при тестировании.

Как подключить

Есть четыре варианта интеграции. Самый распространённый для современных проектов через VSTest. Он уже включён по умолчанию в шаблоны xUnit-проектов начиная с .NET 8.

Если его нет, добавляем в тестовый проект:

dotnet add package coverlet.collector

Запускаем тесты с флагом сбора покрытия:

dotnet test --collect:"XPlat Code Coverage"

После выполнения в папке TestResults появится файл coverage.cobertura.xml с отчётом.

Второй вариант через MSBuild:

dotnet add package coverlet.msbuild
dotnet test /p:CollectCoverage=true

Итог сразу появится в терминале, а файл coverage.json сохранится в корне тестового проекта.

Третий вариант. Глобальный инструмент командной строки:

dotnet tool install --global coverlet.console
coverlet /path/to/test-assembly.dll --target "dotnet" --targetargs "test /path/to/test-project --no-build"

Четвёртый, самый новый, это интеграция с Microsoft Testing Platform. Подходит для проектов на Microsoft.Testing.Platform, требует .NET 8 и выше:

dotnet add package coverlet.MTP
dotnet test --coverlet

Если вы работаете в Visual Studio на Windows, расширение Fine Code Coverage умеет читать вывод Coverlet и подсвечивать покрытие прямо в редакторе. На macOS есть аналог VSMac-CodeCoverage.

Coverlet не требует сложной настройки, встраивается в стандартный dotnet test, работает на всех платформах и бесплатен.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#garbage_collector

Читать полностью…

🤔 Запросы в БД быстрые, кэш есть, async везде, но приложение тормозит

Скорее всего виноват не код, а аллокации.

Каждый раз, когда вы пишете Substring(), Split() или ToArray(), то вы создаёте новые объекты на хипе. При большой нагрузке это тысячи объектов в секунду.

А дальше приходит Garbage Collector и делает паузу. Вот откуда те самые загадочные всплески задержек.

Что делать:

→ Используйте Span<T> и ReadOnlySpan<T> вместо substring
→ ArrayPool<T>.Shared.Rent() вместо new массивов
→ StringBuilder пулить через ObjectPool
→ Профилируйте через dotnet-trace + BenchmarkDotNet

Правило простое: меньше объектов на хипе → реже GC → стабильная латентность. Иногда пара изменений убирает 80% тормозов.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

⚙️ yield return не бесплатный

Итераторы выглядят просто, но работают иначе:

IEnumerable<int> GetIds()
{
    foreach (var item in _items)
        yield return item.Id;
}

Читается как обычный цикл. Но компилятор превращает такой метод в конечный автомат со вспомогательными классами и состоянием. Именно поэтому итераторы такие выразительные — но и именно поэтому они не бесплатны.

Где это становится проблемой

На большинстве путей yield return это правильный выбор. Код чище, API удобнее, читаемость выше.

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

Что делать на критичных участках

Если профилировщик показал, что итератор узкое место, есть несколько альтернатив.

Заполнение буфера, переданного вызывающей стороной:

void FillIds(Span<int> buffer)
{
    for (int i = 0; i < _items.Count; i++)
        buffer[i] = _items[i].Id;
}

Возврат конкретной коллекции:

List<int> GetIds()
{
    var result = new List<int>(_items.Count);
    foreach (var item in _items)
        result.Add(item.Id);
    return result;
}

Прямой цикл внутри горячего кода без промежуточных перечислений:

for (int i = 0; i < _items.Count; i++)
    Process(_items[i].Id);

yield return стоит использовать тогда, когда он делает API лучше и код понятнее. Но не стоит считать его нулевым по стоимости. Если участок горячий, то сначала замерьте, потом решайте.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

Читать полностью…

👨‍💻 Конфигурация везде это проблема

Когда конфигурация разбросана по всему коду, проект становится хрупким. Строки вроде _configuration["Stripe:ApiKey"] встречаются в контроллерах, сервисах, хелперах — и каждый раз с риском опечатки, без типизации, без валидации. Поменяли ключ в appsettings — ищете, где всё сломалось.

Что не так с таким подходом

Прямое обращение к IConfiguration через магические строки создаёт несколько реальных проблем. Нет единого места, где видно всю конфигурацию приложения. Парсинг типов (int.Parse, bool.Parse) повторяется в разных местах. Опечатка в ключе не вызовет ошибку компиляции — только падение в рантайме.

Тестировать такой код неудобно:

// Так делать не стоит — магические строки, парсинг вручную
var apiKey = _configuration["Stripe:ApiKey"];
var timeout = int.Parse(_configuration["Timeout"] ?? "30");

Одна точка входа для конфигурации

Решение: завести типизированные классы под каждую область конфигурации и привязать их один раз при старте приложения.

// Infrastructure/Configuration/ApplicationOptions.cs
public sealed class ApplicationOptions
{
    public PaymentOptions Payment { get; set; } = new();
    public DatabaseOptions Database { get; set; } = new();
    public CacheOptions Cache { get; set; } = new();
    public FeatureFlags Features { get; set; } = new();
}

public sealed class PaymentOptions
{
    public string StripeApiKey { get; set; } = string.Empty;
    public string StripeWebhookSecret { get; set; } = string.Empty;
    public int RetryAttempts { get; set; } = 3;
}

В Program.cs одна привязка для всего:

builder.Services.AddOptions<ApplicationOptions>()
    .Bind(builder.Configuration)
    .ValidateDataAnnotations()
    .ValidateOnStart();

ValidateOnStart выбрасывает исключение при запуске, если конфигурация невалидна. Не в рантайме, не при первом запросе — сразу при старте.

Чистое внедрение через extension method

Чтобы не засорять Program.cs, выносим регистрацию в extension method и сразу открываем под-опции для инжекции:

public static class OptionsExtensions
{
    public static IServiceCollection AddApplicationOptions(
        this IServiceCollection services,
        IConfiguration configuration)
    {
        services.AddOptions<ApplicationOptions>()
            .Bind(configuration)
            .ValidateDataAnnotations()
            .ValidateOnStart();

        services.AddSingleton(sp =>
            sp.GetRequiredService<IOptions<ApplicationOptions>>().Value.Payment);
        services.AddSingleton(sp =>
            sp.GetRequiredService<IOptions<ApplicationOptions>>().Value.Database);

        return services;
    }
}

Теперь в сервисах не нужна обёртка IOptions<T>. Инжектируем напрямую:

public class OrderService
{
    private readonly PaymentOptions _paymentOptions;
    private readonly DatabaseOptions _dbOptions;

    public OrderService(
        PaymentOptions paymentOptions,
        DatabaseOptions dbOptions)
    {
        _paymentOptions = paymentOptions;
        _dbOptions = dbOptions;
    }
}

В итоге конфигурация живёт в одном месте и имеет чёткую структуру. Все ключи типизированы и никаких магических строк.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

👨‍💻 Хватит мучить MongoDB через EF Core

Вы выбрали MongoDB ради гибкости. А потом два часа потратили на то, чтобы EF Core позволил сделать элементарный фильтр. Поздравляем, вы сами себе враг.

EF Core для MongoDB это иллюзия комфорта. Знакомый синтаксис, но в обмен на всё, ради чего вообще брали Mongo: агрегационные пайплайны, геозапросы, полнотекстовый поиск. Провайдер этого просто не умеет.

Правильный путь — это MongoDB.Driver напрямую.

Ставите пакет:

dotnet add package MongoDB.Driver

Делаете кастомный атрибут, чтобы сущность сама знала свою коллекцию:

[CollectionName("orders")]
public class Order
{
    [BsonId]
    [BsonRepresentation(BsonType.ObjectId)]
    public string Id { get; set; }
    public string CustomerName { get; set; }
}

Generic-репозиторий читает атрибут сам и никаких магических строк в Program.cs:

public class MongoRepository<T> : IMongoRepository<T>
{
    private readonly IMongoCollection<T> _collection;

    public MongoRepository(IMongoDatabase db)
    {
        var name = typeof(T)
            .GetCustomAttribute<CollectionNameAttribute>()?.Name
            ?? typeof(T).Name;
        _collection = db.GetCollection<T>(name);
    }
}

Регистрируете один раз через и больше никогда не трогаете Program.cs при добавлении новых коллекций:

services.AddScoped(typeof(IMongoRepository<>), typeof(MongoRepository<>));

Новая коллекция? Просто новый класс с [CollectionName].

А для сложных запросов Builders<T>:

var filter = Builders<Order>.Filter.Eq(o => o.Status, "pending");
var sort = Builders<Order>.Sort.Descending(o => o.CreatedAt);
var results = await _collection.Find(filter).Sort(sort).ToListAsync();

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

💡 Generative AI for Beginners .NET v2

Microsoft выпустила вторую версию бесплатного открытого курса «Generative AI for Beginners .NET». Это не обновление старого материала, а полностью новый курс с другой структурой и свежими примерами.

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

В первой версии основой был Semantic Kernel. В v2 его заменили на Microsoft.Extensions.AI (MEAI). MEAI входит в экосистему .NET 10, следует тем же принципам, что ILogger и IConfiguration, и не привязывает к конкретному оркестратору.

➡️ Репозиторий | Блог разработчиков

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

Читать полностью…

🧑‍💻 Пусть приложение падает при старте, а не в 2 часа ночи

Представьте сценарий. Платёжный сервис ушёл в прод. Конфиг собран наспех, API-ключ не тот, URL без HTTPS. Всё тихо до первой реальной транзакции. Потом звонок в ночь, инцидент, откат.

Паттерн Options с валидацией на старте решает именно эту проблему.

Вместо того чтобы читать конфиг в рантайме и падать где попало, мы проверяем всё один раз при запуске. Если что-то не так, то приложение не поднимается вообще. Это лучше, чем ловить NPE или невалидный URL в середине бизнес-логики.

Шаг первый. Описываем класс опций с атрибутами валидации:

public sealed class PaymentGatewayOptions
{
    [Required(ErrorMessage = "API Key is required - check your key")]
    [StringLength(100, MinimumLength = 20)]
    public string ApiKey { get; set; } = string.Empty;

    [Required]
    [Range(1, 10, ErrorMessage = "Retry count must be between 1 and 10")]
    public int MaxRetries { get; set; } = 3;

    [Required]
    [RegularExpression(@"^https://", ErrorMessage = "Base URL must use HTTPS")]
    public string BaseUrl { get; set; } = string.Empty;

    [Required]
    public TimeSpan Timeout { get; set; } = TimeSpan.FromSeconds(30);
}

Шаг второй. Регистрируем в Program.cs с вызовом ValidateOnStart():

builder.Services.AddOptions<PaymentGatewayOptions>()
    .BindConfiguration("PaymentGateway")
    .ValidateDataAnnotations()
    .ValidateOnStart(); // упадёт при старте, если конфиг невалиден

Шаг третий. Используем в сервисе через IOptions<T>:

public class PaymentService
{
    private readonly PaymentGatewayOptions _options;

    public PaymentService(IOptions<PaymentGatewayOptions> options)
    {
        _options = options.Value;
    }

    public async Task ProcessPaymentAsync(decimal amount)
    {
        using var client = new HttpClient
        {
            BaseAddress = new Uri(_options.BaseUrl),
            Timeout = _options.Timeout
        };

        client.DefaultRequestHeaders.Add("X-API-Key", _options.ApiKey);

        for (int i = 0; i < _options.MaxRetries; i++)
        {
            try { /* логика запроса */ }
            catch { if (i == _options.MaxRetries - 1) throw; }
        }
    }
}

Паттерн не новый, но cтоит использовать везде, где конфиг критичен для работы сервиса.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

📈 Дайджест недели

Мы уже готовим для вас шутки на 1 апреля, а пока что дайджест.

— AI-агенты в .NET MAUI

— Сеньор занимается гейткипингом

— Утилита, которая возвращает правый Ctrl вместо кнопки Copilot

— GitHub Copilot теперь умеет мигрировать .NET-проекты

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

Читать полностью…

🤩 Подборка вакансий для шарпистов

C# Backend Developer — от 180 000 ₽ гибрид в Санкт-Петербурге

Unity разработчик — до 4 500 €, гибрид в Алматы

Fullstack-разработчик (C# / React Native) — удалёнка или гибрид в Пензе

➡️ Еще больше топовых вакансий — в нашем канале C# Jobs

🐸 Библиотека шарписта

Читать полностью…

🚩 OpenFeature для .NET

Смена провайдера feature flags обычно означает переписывание интеграции. OpenFeature это открытый стандарт под крылом CNCF, который даёт единый vendor-agnostic API: меняете провайдера, меняете одну строчку, код не трогаете.

Установка

dotnet add package OpenFeature

Требования: .NET 8+ или .NET Framework 4.6.2+

Минимальный пример:

await Api.Instance.SetProviderAsync(new InMemoryProvider());

var client = Api.Instance.GetClient();
bool v2Enabled = await client.GetBooleanValueAsync("v2_enabled", false);

if (v2Enabled)
{
    // новая логика
}

Флаги с контекстом

Передавайте данные о пользователе/запросе для контекстно-зависимых решений:

// Глобально
EvaluationContext ctx = EvaluationContext.Builder()
    .Set("region", "us-east-1")
    .Build();
Api.Instance.SetContext(ctx);

// Или прямо в вызове
bool flagValue = await client.GetBooleanValueAsync(
    "some-flag", false, reqCtx);

Логика вокруг вычисления флага

Добавляйте поведение на любом этапе: до, после, при ошибке, в любом случае.

// Глобально для всех вызовов
Api.Instance.AddHooks(new ExampleGlobalHook());

// Только для конкретного клиента
client.AddHooks(new ExampleClientHook());

Встроенный LoggingHook пишет детальные логи через Microsoft.Extensions.Logging.

Реакция на изменения

Api.Instance.AddHandler(
    ProviderEventTypes.ProviderReady,
    (eventDetails) => Console.WriteLine(eventDetails.Type)
);

Подписывайтесь на ProviderReady, ProviderError, ProviderConfigurationChanged.

Dependency Injection (экспериментально)

dotnet add package OpenFeature.Hosting

builder.Services.AddOpenFeature(featureBuilder => {
    featureBuilder
        .AddInMemoryProvider()
        .AddHook<LoggingHook>();
});

Поддержка domain-scoped провайдеров: разные провайдеры для разных частей приложения.

Несколько провайдеров одновременно с разными стратегиями:

- FirstMatchStrategy — первый ненулевой результат
- FirstSuccessfulStrategy — первый успешный, игнорируя ошибки
- ComparisonStrategy — параллельное выполнение + сравнение результатов

var multiProvider = new MultiProvider(providerEntries, new FirstMatchStrategy());
await Api.Instance.SetProviderAsync(multiProvider);

Собственный провайдер:

public class MyProvider : FeatureProvider
{
    public override Metadata GetMetadata() =>
        new Metadata("My Provider");

    public override Task<ResolutionDetails<bool>> ResolveBooleanValueAsync(
        string flagKey, bool defaultValue,
        EvaluationContext? context = null, ...)
    {
        // ваша логика
    }
    // + ResolveString, ResolveInteger, ResolveDouble, ResolveStructure
}

Для ASP.NET Core один раз настроили контекст на входе запроса, и он автоматически попадает во все вычисления флагов в рамках этого запроса:

Api.Instance.SetTransactionContextPropagator(
    new AsyncLocalTransactionContextPropagator());

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#garbage_collector

Читать полностью…

💡 Красивые алгоритмы медленны при малом n

Красивые алгоритмы с хорошей асимптотикой имеют большие константы. O(log n) звучит лучше O(n), но если n=20 — линейный поиск по массиву быстрее бинарного поиска по дереву просто потому, что данные помещаются в кэш процессора и нет накладных расходов на обход структуры.

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

// "Правильное" решение — O(1) lookup
private readonly Dictionary<string, IHandler> _handlers = new()
{
    ["OrderCreated"] = new OrderCreatedHandler(),
    ["OrderCancelled"] = new OrderCancelledHandler(),
    ["OrderShipped"] = new OrderShippedHandler(),
};

// "Наивное" решение — O(n) linear scan
private readonly (string EventType, IHandler Handler)[] _handlers =
[
    ("OrderCreated", new OrderCreatedHandler()),
    ("OrderCancelled", new OrderCancelledHandler()),
    ("OrderShipped", new OrderShippedHandler()),
];

public IHandler? Find(string eventType)
{
    foreach (var (type, handler) in _handlers)
        if (type == eventType) return handler;
    return null;
}

При 5–20 обработчиках линейный массив часто быстрее словаря: данные лежат последовательно в памяти, нет хеширования, нет разыменования указателей, кэш доволен. Dictionary начинает выигрывать при десятках тысяч элементов и только тогда.

Бенчмарк говорит сам за себя:

[MemoryDiagnoser]
public class LookupBenchmark
{
    private readonly Dictionary<string, int> _dict;
    private readonly (string, int)[] _array;

    public LookupBenchmark()
    {
        var data = Enumerable.Range(0, 10)
            .Select(i => ($"key{i}", i))
            .ToArray();

        _dict = data.ToDictionary(x => x.Item1, x => x.Item2);
        _array = data;
    }

    [Benchmark(Baseline = true)]
    public int DictLookup() => _dict["key7"];

    [Benchmark]
    public int ArrayScan()
    {
        foreach (var (k, v) in _array)
            if (k == "key7") return v;
        return -1;
    }
}

При n=10 массив зачастую быстрее и не аллоцирует ничего лишнего. Измерьте сами.

Когда измерения при реальной нагрузке показывают, что n действительно большой и растёт. Не раньше. Routing-таблица с 15 маршрутами, валидация с 8 правилами, матчинг по 12 паттернам — всё это «малый n», и простой цикл здесь выиграет у любого красивого решения.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

Читать полностью…

📰 Дайджест недели

Последний дайджест марта.

— Generative AI for Beginners .NET v2

— Почти год с Copilot Coding Agent в dotnet/runtime

— Пять типичных ошибок при проектировании интеграции с помощью Kafka

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

Читать полностью…

⚡️ Рестарт ради смены настроек это лишнее

Если конфигурация меняется редко, перезапуск приложения — не проблема. Но когда нужно менять, например, тарифы или флаги в реальном времени, рестарт становится дорогим решением. IOptionsMonitor<T> позволяет получать актуальные значения сразу после изменения файла конфигурации.

Как это работает

IOptionsMonitor<T> следит за изменениями источника конфигурации. При каждом обращении к CurrentValue возвращается актуальное значение. Дополнительно можно подписаться на событие изменения через OnChange:

public class DynamicPricingService
{
    private readonly IOptionsMonitor<PricingOptions> _options;

    public DynamicPricingService(IOptionsMonitor<PricingOptions> options)
    {
        _options = options;

        _options.OnChange(updatedOptions =>
        {
            Log.Information("Pricing updated: BaseRate={BaseRate}",
                updatedOptions.BaseRate);
        });
    }

    public decimal CalculatePrice(decimal distance)
    {
        var currentOptions = _options.CurrentValue;

        return currentOptions.BaseRate + (distance * currentOptions.PerMileRate);
    }
}

Каждый вызов CalculatePrice берёт свежее значение из CurrentValue без рестарта и без ручного сброса кэша. Регистрация в Program.cs:

builder.Services.AddOptions<PricingOptions>()
    .BindConfiguration("Pricing", binderOptions =>
    {
        binderOptions.BindNonPublicProperties = false;
        binderOptions.ErrorOnUnknownConfiguration = true;
    })
    .ValidateDataAnnotations();

ErrorOnUnknownConfiguration = true защищает от опечаток в ключах — неизвестное поле в конфиге вызовет ошибку, а не тихо проигнорируется.

IOptionsMonitor против IOptionsSnapshot

IOptionsMonitor<T> — синглтон. Одно и то же значение живёт на протяжении всего времени работы приложения и обновляется при изменении файла.

IOptionsSnapshot<T> — скоупед. Значение фиксируется один раз на запрос и не меняется до его завершения. Это важно там, где нужна консистентность внутри одного HTTP-запроса — чтобы один и тот же запрос не увидел разные значения конфигурации в начале и в конце обработки.

Если сервис живёт в синглтоне, используйте IOptionsMonitor. Если важна согласованность в рамках запроса, IOptionsSnapshot.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

✏️ Задание: не положить базу после истечения TTL

Представьте: TTL кэша истёк, и сотни запросов одновременно обнаружили пустой кэш. Все ломятся в базу за одним и тем же значением. Это называется cache stampede.

Как бы вы это решили? Какой примитив синхронизации выбрать, чтобы первый запрос шёл в БД, а остальные ждали его результата?

Подумайте и проверьте свой ответ здесь: @csharp_interview_lib

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#dotnet_challenge

Читать полностью…

😱 Если ваш продукт не умеет отдавать данные в формате, понятном AI-агенту, то вас просто не существует

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

Как адаптировать продукт и не исчезнуть из выдачи:

— интегрировать MCP и A2A-взаимодействие, чтобы агенты могли вас читать;
— научиться контролировать стоимость (лимиты, кэш, роутинг между моделями);
— настроить AgentOps: трейсинг, логирование и отлов регрессий.

Всё это ждёт вас на обновлённом курсе «Разработка AI-агентов». Мы специально сделали фокус на утилитарном инжиниринге и production-ready решениях.

Кстати, до 29 марта можно забрать курс с большой скидкой, и стоит поторопиться — мест на потоке всё меньше.

Зафиксировать цену и начать деплоить агентов без слива бюджета 👈

Читать полностью…

🕸 Пять типичных ошибок при проектировании интеграции с помощью Kafka

Система работала нормально, пока обработка батча не заняла слишком много времени. Координатор консьюмер-групп решил, что консьюмер мёртв, отверг коммит оффсета — и консьюмер начал читать сообщения заново. По кругу.

Это называется ложная ребалансировка, и это один из самых неочевидных сценариев поломки.

Архитектор Альфа-Банка разобрал пять таких историй из реального прода — с объяснением механики и тем, как этого избежать.

➡️ Читать статью

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

Читать полностью…

🔎 Удалённое комбо вакансий для шарпистов

Подобрали три вакансии для тех, кто не хочет выходить из дома:

.NET-разработчик

C#/.NET-разработчик

Senior Backend .NET Engineer

➡️ Еще больше топовых вакансий — в нашем канале C# Jobs

🐸 Библиотека шарписта

Читать полностью…

🤨 10 месяцев с Copilot Coding Agent в dotnet/runtime

Microsoft опубликовали детальный разбор использования GitHub Copilot Coding Agent в репозитории dotnet/runtime за последние 10 месяцев. Это один из самых сложных проектов в мире: основа .NET, 14 миллионов строк кода, миллионы активных разработчиков. Репозиторий использовали как полигон для эксперимента: может ли AI-агент полноценно участвовать в разработке такого масштаба?

Общая картина: 878 PR за 10 месяцев

С мая 2025 по март 2026 команда открыла 878 PR через CCA. Из них принято 535 (67.9%), закрыто 253, ещё 90 остаются открытыми.

Для сравнения: PR от разработчиков Microsoft принимаются в 87.1% случаев, от сообщества — в 79.7%, от ботов вроде dependabot — в 85.9%. CCA уступает людям по этому показателю, но авторы подчёркивают: это разные задачи.

Важный показатель качества — процент откатов. Из 535 принятых PR через CCA откатили 3 (0.6%). Среди остальных PR — 33 из 4251 (0.8%). Разница статистически незначима, но это говорит о том, что AI-код не хуже по качеству в плане регрессий.

Главный урок: инструкции важнее модели

До появления файла .github/copilot-instructions.md успешность выполнения задач была 38%. После — 69%. Это самый показательный факт во всей статье.

Изначально CCA не мог скачать NuGet-пакеты, потому что firewall блокировал внешние ресурсы. Не знал, как собирать репозиторий. Не мог запустить тесты. Это было похоже на то, как взять нового разработчика и поставить ему задачу, не дав доступа ни к чему.

Основные выводы авторов: думайте об агенте как о паре, а не замене; задачи с чётким описанием и понятным скоупом — лучшие кандидаты; ожидайте несколько итераций; следите за «ленивостью» агента, который делает минимум и не экстраполирует; каждый урок, вложенный в файл инструкций, окупается на всех следующих PR.

➡️ Блог разработчиков

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

Читать полностью…

⚡️ Прячем секреты и не ломаем тесты

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

.NET читает конфигурацию слоями. Каждый следующий слой перекрывает предыдущий.

В Program.cs это выглядит так:

var builder = WebApplication.CreateBuilder(args);

builder.Configuration
    // 1. Базовые настройки — коммитим в репо, только безопасные дефолты
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)

    // 2. Настройки под окружение — Development.json коммитим, Production.json нет
    .AddJsonFile($"appsettings.{builder.Environment.EnvironmentName}.json",
        optional: true, reloadOnChange: true)

    // 3. User Secrets — только для разработки, никогда не коммитим
    .AddUserSecrets<Program>(optional: true)

    // 4. Переменные окружения — CI/CD, Docker, Kubernetes
    .AddEnvironmentVariables()

    // 5. Хранилище секретов — для прода
    .AddVaultSecrets(builder.Configuration);

Структура файлов:

├── appsettings.json                 # безопасные дефолты, коммитим
├── appsettings.Development.json     # локальные настройки, коммитим
├── appsettings.Production.json      # только структура без значений, коммитим
└── secrets.json                     # User Secrets, в .gitignore

В appsettings.Production.json пишем только заглушки, никаких реальных значений:

{
  "Database": {
    "ConnectionString": "CONFIGURED_IN_SECRETS_MANAGER"
  },
  "PaymentGateway": {
    "ApiKey": "CONFIGURED_IN_SECRETS_MANAGER"
  }
}

Можно спрятать секреты в GitLab CI, например:

# .gitlab-ci.yml
deploy_production:
  stage: deploy
  script:
    - dotnet publish -c Release
    - ./deploy.sh
  variables:
    Database__ConnectionString: $PROD_DB_CONNECTION
    PaymentGateway__ApiKey: $STRIPE_API_KEY
  only:
    - main

По итогу в репозитории будут только безопасные дефолтные значения, а все секреты вынесены.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

Читать полностью…

⚡️ Утечка памяти, которую не видно до прода

Channel<T> — это стандартный выбор для producer-consumer в .NET. Быстрее ConcurrentQueue, дружит с cancellation, не аллоцирует лишнего. Документация рекомендует. Коллеги используют.

Дефолтный способ создать канал выглядит так:

var channel = Channel.CreateUnbounded<WorkItem>();

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

В разработке нагрузка маленькая, producer и consumer держат примерно одинаковый темп. На проде, при трафике чуть выше нормы, разрыв может быть огромным.

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

Переходим на CreateBounded и явно выбираем поведение при переполнении:

var channel = Channel.CreateBounded<WorkItem>(
    new BoundedChannelOptions(capacity: 500)
    {
        FullMode = BoundedChannelFullMode.Wait,
        SingleReader = true
        SingleWriter = false
    }
);

BoundedChannelFullMode это настоящее архитектурное решение. Четыре варианта с разным поведением по отношению к потере данных:

Wait — блокирует producer до появления места
DropNewest — выбрасывает только что записанное
DropOldest — выбрасывает самое старое
DropWrite — возвращает false на TryWrite

Как считать capacity

capacity = пик записи в секунду × P99 время обработки в секундах  × 2

Пример: 500 записей в секунду, p99 обработки 200 мс:

capacity = 500 × 0.2 × 2 = 200

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

Читать полностью…

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#garbage_collector

Читать полностью…

😈 Ручное тестирование мертво

Металлург → Fullstack QA Engineer в Альфа-Банке. Звучит нереально, но именно такой путь описан в новой статье.

Путь начался в 2021 с первого собеседования в IT без понимания, зачем нужен бэкенд. Финал: тестирование аналитических HTAP-систем, автотесты на Java и работа с Kafka-потоками.

➡️ В статье собрано 5 советов, что работает на рынке прямо сейчас

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

Читать полностью…