Вакансии для С# разработчиков

Ищите работу на С#? Устали пролистывать сотни неактуальных предложений?
Подписывайтесь на канал 👉 «Вакансии для С# разработчиков»

Что тебя ждёт:
✔️ Свежие вакансии каждый день
✔️ Junior, Middle, Senior — для любого уровня
✔️ Только проверенные работодатели

Не упусти шанс найти работу мечты!

🗂 Подписывайся и будь первым, кто узнает о новых вакансиях.

[Вакансии для С# разработчиков]

👨‍💻 Когда if начинает распухать

Паттерн стратегия подходит, когда один и тот же сценарий можно выполнить несколькими способами, и выбор зависит от условий. Вместо большого switch внутри сервиса разные варианты выносятся в отдельные классы с общим интерфейсом, а контекст просто делегирует работу выбранной реализации.

Типовая схема такая. Есть интерфейс Strategy, есть несколько конкретных стратегий, и есть контекст, который держит ссылку на стратегию и вызывает ее метод, не зная деталей реализации. Это снижает связность и позволяет добавлять новые варианты без переписывания старого кода.

Мини пример на C#:

public interface IDiscountStrategy
{
    decimal Apply(decimal total);
}

public sealed class RegularDiscount : IDiscountStrategy
{
    public decimal Apply(decimal total) => total;
}

public sealed class VipDiscount : IDiscountStrategy
{
    public decimal Apply(decimal total) => total * 0.9m;
}

public sealed class Checkout
{
    private readonly IDiscountStrategy _discount;

    public Checkout(IDiscountStrategy discount) => _discount = discount;

    public decimal TotalWithDiscount(decimal total) => _discount.Apply(total);
}

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

var checkout = serviceProvider.GetRequiredService<Checkout>();
var total = checkout.TotalWithDiscount(100m);

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

Профессор Си

📎 Когда хочется коротко, но выходит долго

GroupBy в LINQ удобный и выразительный, поэтому его часто тянут в любой код, где надо что то посчитать по ключу.

Проблема в том, что GroupBy решает задачу группировки, а агрегация это частный случай, и за него иногда приходится платить лишним.

Типичный паттерн выглядит так:

var totals = orders
    .GroupBy(o => o.CustomerId)
    .Select(g => new
    {
        CustomerId = g.Key,
        Total = g.Sum(o => o.Amount)
    })
    .ToList();

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

Если нужна именно аккумуляция, проще и дешевле сделать один проход и складывать суммы в словарь:

var totals = new Dictionary<int, decimal>();
foreach (var order in orders)
{
    if (totals.TryGetValue(order.CustomerId, out var current))
        totals[order.CustomerId] = current + order.Amount;
    else
        totals[order.CustomerId] = order.Amount;
}

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

Профессор Си

✏️ Не копируйте gitignore, генерируйте

Мы раньше кидали эту команду. dotnet new gitignore делает все за вас. В ней уже прописаны все типичные исключения: каталоги bin/, obj/, кэш NuGet, файлы публикаций, временные артефакты IDE и прочие служебные данные, которые не должны попадать в репозиторий.

Не нужно искать шаблон на GitHub или копировать его вручную — всё доступно из коробки.

Профессор Си

⭐️ ValueTask в C#

Мы уже разбирали ValueTask раньше, но сейчас напомним ключевые моменты. ValueTask это структура, которая может хранить либо готовый результат, либо Task, чтобы избежать аллокаций в простых случаях.

Особенности использования ValueTask:

• Повторное ожидание запрещено

Вызывать await несколько раз для одного и того же ValueTask нельзя, так как это может привести к неожиданным результатам:

ValueTask<int> task = GetValueAsync();
int value1 = await task;
int value2 = await task; // Ошибка

• Конвертация в Task

Eсли требуется передать ValueTask в API, которое ожидает Task, можно вызвать метод .AsTask():

Task<int> task = GetValueAsync().AsTask();

• Когда использовать ValueTask:

+ Операция часто завершается синхронно.
+ Создание объекта Task может быть слишком накладным.
+ Вы пишете библиотеку с высокой производительностью.

• Когда НЕ использовать ValueTask:

- Операция всегда асинхронна.
- Производительность не является критически важной.
- Приложение не оптимизировано под работу с ValueTask.

Профессор Си

👀 Сортировать все ради одного значения — это дорогая привычка

В продакшене до сих пор встречается LINQ паттерн, где коллекцию сначала сортируют, а потом берут первый элемент:

var youngest = people
    .OrderBy(p => p.Age)
    .First();

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

Правильнее выразить намерение напрямую через MinBy:

var youngest = people.MinBy(p => p.Age);

MinBy возвращает элемент с минимальным ключом и не требует полной сортировки последовательности. Если в коде встречается OrderBy().First() или OrderByDescending().First(), это повод остановиться и проверить, не ищется ли просто минимум или максимум.

Профессор Си