C# 1001 notes

⚙️ Почему async void ломает ваш код В C# у async void есть дурная репутация, и не зря. Такой метод не возвращает Task, а значит, его нельзя await-ить, нельзя встроить в пайплайн и невозможно корректно отследить завершение. Исключения из него не ловятся обычным образом — они пробиваются в синхронизационный контекст или в пул потоков, где легко превращаются в необработанные и могут уронить процесс.

    
        
// Контроллер ASP.NET Core
[HttpPost]
public async void Create() { await _svc.DoAsync(); } // Исключения мимо pipeline

// Библиотека
public async void SaveAsync(Item item) { await _repo.Save(item); } // Вызывающему не сконтролировать{}
    

Правильно — всегда возвращать Task:

    
        
[HttpPost]
public async Task<IActionResult> Create() { await _svc.DoAsync(); return Ok(); }

public Task Invoke(HttpContext ctx) => _next(ctx);

public Task SaveAsync(Item item) => _repo.Save(item);{}
    

Единственный сценарий, где async void уместен, — обработчики событий в UI-фреймворках вроде WPF или WinForms, где сигнатура задаётся самим фреймворком. Там приходится мириться, но даже там стоит ловить исключения локально и логировать их.

🚀 Ты всё ещё называешь обёртку над ChatGPT «AI-продуктом»? Пока ты пишешь промпты - рынок уже ушёл дальше. Сейчас выигрывают не те, кто умеет красиво формулировать запросы, а те, кто строит агентные системы: - принимают решения сами - ходят в API - работают с Postgres и Redis - управляют браузером через Playwright - доводят задачи до результата без человека И вот правда, о которой мало говорят: 90% таких систем умирают между ноутбуком и продом. Работает локально. Ломается в реальности. Нет архитектуры. Нет устойчивости. Нет деплоя. AI Agents Engineering - курс со Stepik, который закрывает этот разрыв. - LangGraph, AutoGen, Computer Use - архитектура агентов, а не «скрипты на коленке» - LLMOps, логирование, стабильность - деплой в Docker и работа в проде 8 модулей, 120+ шагов, всё через практику. На выходе не «сертификат ради галочки», а: - рабочий production-агент - понимание, как строить такие системы с нуля - навыки, за которые уже платят Сейчас самое окно входа. Через полгода это станет базой, а не преимуществом. Скидка 55% действует ещё 48 часов: https://stepik.org/a/276971/

⚙️ Когда Hash Join быстрее Nested Loops Внутри SQL-движка соединение таблиц — это не магия, а конкретный алгоритм. Сравним два подхода к соединению таблиц. Nested Loops работает буквально так, как звучит: берём строку из первой таблицы и ищем совпадения во второй. Если вторая таблица имеет подходящий индекс, поиск по нему будет очень быстрым, и такой алгоритм блестяще справляется с задачей маленькое соединяется с большим. Hash Join подходит там, где Nested Loops захлёбывается. Он сначала строит хэш-таблицу по одной из входных таблиц, а затем пробегается по второй и ищет совпадения через хэш-функцию. Это даёт огромный выигрыш, когда нужно соединить два больших набора данных, и когда индексов для ускорения поиска нет. Цена такого подхода — расход памяти. В итоге — если речь идёт о маленьком наборе строк против большого и есть индекс, Nested Loops окажется быстрее. Но если обе таблицы крупные и индексы не спасают, Hash Join чаще всего становится оптимальным выбором. #dotnet_challenge

👩‍💻 Приглашаем на открытый урок «Облегчённые (Slim) примитивы синхронизации»🗓 16 апреля в 20:00 МСК🆓 На открытом уроке рассмотрим:✔️ Проблему синхронизации доступа к общему ресурсу в многопоточном приложении в рамках внутрипроцессного взаимодействия;✔️ Разберём классическую задачу читателей–писателей и её реализацию с использованием примитивов синхронизации из пространства имён System.Threading;✔️ Отдельно обсудим, в каких случаях облегчённые версии примитивов (например, SemaphoreSlim и ReaderWriterLockSlim) оказываются эффективнее стандартных решений, таких как Monitor, Mutex и конструкция lock.🌿 Вебинар является частью курса «C# разработчик. Экспертный уровень»🔗 Ссылка на регистрацию: https://otus.pw/GyYC/?erid=2W5zFGGTxgHРеклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🔥 Ты не проверишь весь код, если он большой, но нужные инструменты проверят Невозможно вручную ревьюить каждую строчку. Даже в маленьком проекте что-то ускользает. Здесь и подключается статический анализ. Он работает как второй слой контроля прямо во время разработки. Подсвечивает баги, плохие паттерны и потенциальные уязвимости ещё до запуска кода. В итоге ты ловишь проблемы на раннем этапе, а не после релиза. Для C# это особенно просто внедряется. Пара настроек и у тебя уже есть автоматический аудит кода без лишней боли. Если пишешь на C# и не используешь статический анализ, ты реально теряешь быстрые фиксы и чистоту кода. Начать можно отсюда

🚨 «Нет времени на тесты» уже не работает В 2026 писать тесты стало проще, чем придумывать оправдания ИИ генерит шаблоны, дописывает кейсы и закрывает рутину Если у тебя есть нормальная структура, всё остальное ускоряется в разы Вот минимальный стек, который покрывает почти всё • Для юнитов • xUnit остаётся стандартом • TUnit можно смотреть как более современную альтернативу Для ассёртов • Shouldly даёт максимально читаемые проверки • FluentAssertions теперь платный, это стоит учитывать Для интеграционных тестов Aspire сильно упрощает жизнь WebApplicationFactory плюс TestContainers дают реальные зависимости в тестах Respawn чистит базу между прогонами Для фронта • Playwright сейчас лучший выбор • Selenium уже больше про легаси Для моков • NSubstitute самый чистый по API • Moq как дефолт, если привык Для данных Bogus и AutoFixture закрывают генерацию тестовых сценариев Для перфома нса • BenchmarkDtNet для микро-бенчей • k6 для нагрузки • NBomber если хочешь остаться в C# Что по факту важно Тебе не нужен весь этот стек сразу Достаточно двигаться по порядку • Сначала юнит-тесты • Потом интеграция • Потом нагрузка • Потом E2E Самый частый фейл не в инструментах А в том, что тесты откладывают «на потом» В 2026 это уже странное решение Гайд по интеграционным тестам в Aspire https://antondevtips.com/blog/dotnet-aspire-integration-testing-best-practices-for-distributed-applications?utm_source=twitter&utm_medium=social&utm_campaign=09-04-2026

👩‍💻 Открытый урок «Облегчённые (Slim) примитивы синхронизации» 🗓 16 апреля в 20:00 МСК 🆓 На открытом уроке рассмотрим: ✔ Проблему синхронизации доступа к общему ресурсу в многопоточном приложении в рамках внутрипроцессного взаимодействия; ✔ Разберём классическую задачу читателей–писателей и её реализацию с использованием примитивов синхронизации из пространства имён System.Threading; ✔ Отдельно обсудим, в каких случаях облегчённые версии примитивов (например, SemaphoreSlim и ReaderWriterLockSlim) оказываются эффективнее стандартных решений, таких как Monitor, Mutex и конструкция lock. Для кого: Вебинар будет полезен разработчикам, которые уже знакомы с базовыми механизмами синхронизации в .NET и хотят углубить понимание инструментов, предоставляемых стандартной библиотекой для построения безопасных и производительных многопоточных приложений. 🔗 Ссылка на регистрацию: https://otus.pw/ncbR/

🚀 Почему этот EF Core код тормозит? Технически - всё ок. По производительности не очень. Вот типичная ошибка: ❌ Загружаешь всю сущность (все колонки) ❌ Потом фильтруешь и мапишь уже в памяти Что происходит: - лишние данные тянутся из БД - растёт нагрузка на сеть - увеличивается потребление памяти - замедляется приложение ✅ Как правильно: Используй проекцию через `.Select()` прямо в запросе: - берёшь только нужные поля - меньше данных из БД - быстрее запрос - меньше нагрузка на систему 📌 Правило простое: Не тащи всё - бери только то, что используешь Именно такие мелочи чаще всего дают x2–x10 к скорости.

⚡️ Что происходит внутри инфраструктурных сервисов Yandex Cloud? Разработчики Yandex Cloud и Yandex Infrastructure расскажут об этом на встрече для разработчиков, архитекторов и инженеров, которая пройдет 16 апреля. В программе вас ждут реальные технические варианты реализации и опыт нетривиальных решений разработчиков платформы: — Инфраструктура как код для управления оповещениями: и никаких проблем — Развёртывание в ритме танго: как мы заменили оркестрацию процесса установки «хореографией» — Как мы оптимизируем вывод больших языковых моделей: кэширование, время отклика и ресурсы графических ускорителей — Как мы строили собственную сеть доставки контента и через что нам пришлось пройти? — Как мы работаем с уязвимостями на примере современных аппаратных атак Также команда расскажет о разработке программных решений, которые устанавливаются в инфраструктуре заказчика, и о том, как в процессе установки оркестрацию заменили «хореографией». Участники смогут обсудить волнующие вопросы, варианты реализации и ошибки с разработчиками сервисов Yandex Cloud и другими участниками. Встреча пройдет офлайн в Москве и онлайн. Помимо экспертных докладов, офлайн участников ждут секретная техническая сессия и развлекательная программа, а онлайн-участников ждёт инженерное соревнование в прямом эфире. Зарегистрируйтесь, чтобы послушать реальные истории от разработчиков, обменяться опытом и узнать, что скрыто под «капотом» инфраструктурных сервисов, а также какие планы у команды на будущее.

Полезный паттерн для Minimal APIs в .NET, если вы хотите организовать проект по принципу Vertical Slice Architecture. Идея очень простая. Вместо того чтобы держать все роуты в Program.cs, каждый endpoint выносится в отдельный класс. Создаётся небольшой интерфейс:

    
        
public interface IEndpoint
{
    void MapEndpoint(IEndpointRouteBuilder app);
}
{}
    

Дальше каждый endpoint просто реализует этот интерфейс:

    
        
public class GetFollowerStats : IEndpoint
{
    public void MapEndpoint(IEndpointRouteBuilder app)
    {
        app.MapGet("users/{userId}/followers/stats", async (
            Guid userId,
            ISender sender) =>
        {
            var query = new GetFollowerStatsQuery(userId);

            Result<FollowerStatsResponse> result = await sender.Send(query);

            return result.Match(Results.Ok, CustomResults.Problem);
        })
        .WithTags(Tags.Users);
    }
}
{}
    

Что это даёт: • endpoints изолированы по фичам • код становится намного чище • проще масштабировать API • удобно использовать вместе с CQRS / MediatR Регистрация таких endpoints занимает буквально пару миллисекунд при старте приложения. Отличный способ держать Minimal API структурированным даже в больших проектах.