Шарп рулит)

🔥 Не понимаешь, что происходит внутри .NET приложения

Значит у тебя нет нормальной трассировки

Минимальный сетап, который стоит добавить почти в любой проект

OpenTelemetry с базовой инструментализацией
ASP.NET Core, HttpClient, EF Core, Redis и база через Npgsql или SqlClient

Этого хватает, чтобы видеть полный путь запроса
от входа в API до базы и внешних сервисов

Дальше всё становится прозрачным
• где тормозит
• где падает
• где утекает время

Для визуализации можно подключить любой стек

• Aspire Dashboard под быстрый старт
• Grafana если нужен прод уровень
• Jaeger для классического трейсинга
• Seq если хочешь объединить логи и трейсы

Seq особенно удобен, потому что нормально работает со структурированными логами

По факту это один из самых дешёвых апгрейдов инфраструктуры, а профит даёт сразу

Гайд

🔥 Самая недооценённая фича HttpClient в .NET

DelegatingHandler - это middleware для исходящих HTTP-запросов, про который многие забывают.

По сути, ты собираешь pipeline для запросов так же, как в ASP.NET для входящих.

И вместо того чтобы пихать логику в каждый вызов, выносишь всё в одно место.

Авторизация, логирование, ретраи, кеш, аудит, всё навешивается как цепочка обработчиков.

Код становится чище, повторного кода меньше, а поведение запросов контролируется централизованно.

Один раз настроил и это работает для всех клиентов.

Если используешь HttpClient и до сих пор не трогаешь DelegatingHandler, ты реально упускаешь мощный инструмент

🚨 Тихий убийца производительности в EF Core, о котором забывают почти все.

Запрос выглядит идеально - пока у тебя мало данных. Потом начинается ад.

Ты пишешь обычный Include, потом ещё один на ту же сущность… и не замечаешь, как EF Core превращает это в монструозный SQL с кучей JOIN’ов.
Что происходит под капотом:
EF делает несколько JOIN’ов → получается cross product → строки начинают дублироваться
Итог:

• данных в ответе становится в разы больше
• память улетает
• запросы резко тормозят

И всё это без единой ошибки в коде.

Решение есть и оно банально простое - Query Splitting.

Вместо одного жирного запроса EF разбивает его на несколько аккуратных. Без дублирования, без раздувания результата, без боли.
Одна настройка - и ты экономишь кучу ресурсов на проде.

P.S. Если работаешь с EF Core - такие нюансы решают, будет ли твой сервис летать или умирать под нагрузкой.

Никогда не возвращай null для коллекций в C#

Спорное мнение, но на практике это один из самых частых источников багов.

Когда метод возвращает null вместо списка, ты заставляешь каждого, кто его вызывает, писать дополнительную проверку.

Иначе всё ломается на самом банальном месте:

foreach (var transaction in GetTransactions(userId))
{
    // boom, если null
}

В итоге получаешь:

• лишние null-проверки повсюду
• более громоздкий код
• ошибки в рантайме, если кто-то забыл проверить

Всегда этого возвращай пустую коллекцию:

Enumerable.Empty<T>()
new List<T>()
[] в C# 12
var transactions = GetTransactions(userId) 
                   ?? Enumerable.Empty<TransactionDto>();

Теперь код становится чище и понятнее.

Ты всегда можешь итерироваться и не думаешь о null каждый раз.

Хороший API - это тот, в работе с которым ошибиться почти невозможно.

Представь обычную ситуацию.

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

В базе у тебя остаётся только финальное состояние. Просто запись “как есть сейчас”. Всё, что происходило до этого, исчезает.

Ты не увидишь, какие товары удаляли, где пользователь сомневался, на каком шаге что-то пошло не так. Для отладки, аналитики и аудита это слепая зона.

Пока у тебя простой CRUD на ASP.NET Core и Entity Framework Core, это может не мешать. Но как только появляются бизнес-процессы посложнее, начинаются проблемы. Нет истории - нет понимания.

Здесь пригодится Event Sourcing.

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

События неизменяемые. Ты их не редактируешь и не удаляешь. Только добавляешь новые.

Каждая сущность превращается в поток событий. У корзины своя последовательность: создали, добавили товар, удалили, оформили заказ.

Текущее состояние собирается из этих событий. В

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

Для чтения строятся отдельные модели. Например, через Marten или тот же PostgreSQL. Они обновляются сразу или асинхронно и отдают данные в API.

В итоге у тебя не просто таблица с текущими значениями, а полная история системы. Можно откатиться на любой момент, разобрать баг, посмотреть реальные действия пользователя.

CRUD отвечает на вопрос “что сейчас в базе”.
Event Sourcing отвечает на вопрос “что реально происходило”.

И для сложных систем это уже не архитектурный стиль, а вопрос выживания проекта.

Гайд по эвент-сорсингу

В C# 15 появились union types. И это не косметика, это смена подхода к обработке ошибок.

Вы можете явно описать результат как “либо значение, либо ошибка”, прямо на уровне языка.

Без самодельных Result-классов, без лишних обёрток, без попыток использовать исключения там, где они неуместны.

Раньше, ты либо городишь свой Result и работаешь с лишним бойлерплейтом.
Либо тащишь сторонние библиотеки.

Либо кидаешь исключения и теряешь контроль над потоком.

С union types эта проблема решается .

Pattern matching начинает работать так, как и должен. Ты не гадаешь, что вернул метод, а явно разбираешь все варианты.

Код становится проще читать, проще тестировать и сложнее сломать.

Хватит копировать один и тот же unit test

Если тест отличается только входными данными, не нужно плодить десятки одинаковых методов.

В xUnit для этого есть parameterized tests, они же data-driven tests. Вы пишете один тест, а потом прогоняете его на разных наборах данных.

Самый простой вариант - [InlineData(...)], когда параметры можно прямо указать над тестом.

Если данных больше или нужна нормальная типизация, можно вынести их в TheoryData<T> и подключить через [ClassData(typeof(...))].

Смысл простой: меньше копипасты, чище тесты, проще добавлять новые кейсы.

Вместо пяти почти одинаковых тестов - один понятный сценарий и набор входных данных.

Для xUnit это один из тех приемов, который быстро окупается в любом C# проекте.

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

В 1988 году в стандартной библиотеке C была функция `gets()`. Она читала ввод пользователя в буфер, но не проверяла его размер. Если данных приходило больше, чем помещалось, они просто начинали затирать соседнюю память.

Именно это использовал Robert Morris в знаменитом Morris Worm. Червь атаковал `fingerd`, переполнял буфер и заставлял систему выполнять чужой код.

Итог: около 6000 машин были заражены за считанные часы. По оценкам того времени, это была примерно десятая часть всего интернета.

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

Позже `gets()` признали настолько опасной, что её фактически выкинули из современного C.

Урок простой: в системном программировании безопасность часто ломается не на сложной криптографии, а на банальном «а что будет, если ввод окажется длиннее, чем мы ожидали?»

#history