Ура! 🎉

Леонид был спасён уже через 5 минут после публикации поста в пятницу. Всё благодаря опытным подписчикам #codaza, которые не дали джуну утонуть в неведомых дебрях асинхронного кода C#. Лёне одобрили его первый merge в master, от чего он начал праздновать День Пельменей с невиданным размахом!

В чём же была проблема? Почему злой тим лид отмахивался комментарием “Просадка в производительности” и отклонял merge? Всё дело в 3-ей и 5-ой строках исходного кода. Что делает Леонид:

1. Запускает асинхронное выполнение задачи GroupDataChunkAsync().
2. Ожидает окончания её выполнения.
3. Запускает асинхронное выполнение задачи CalculateCypherPhraseAsync().
4. Ожидает окончания её выполнения.

Все эти 4 действия выполняются последовательно. Но Лёня не задаётся вопросом, а нужно ли выполнять эти действия последовательно? Может быть, они могут быть выполнены параллельно? И, как вы уже догадались, эти действия могут быть выполнены параллельно. Мы можем вызвать асинхронное выполнение методов GroupDataChunkAsync() и CalculateCypherPhraseAsync() независимо, так как результат их выполнения потребуется только на 7-ой строке. То есть, следовало сделать так:

1. Запустить асинхронное выполнение задачи GroupDataChunkAsync().
2. Запустить асинхронное выполнение задачи CalculateCypherPhraseAsync().
3. Дождаться результата выполнения обеих задач и продолжить логику метода ProcessItemsAsync().

Один из вариантов, который предложил подписчик Eugene Potashkin, это воспользоваться статическим методом WhenAll, который реализован в классе Task. То есть, код будет выглядеть так:

var groupTask = GroupDataChunksAsync(limit);
var phraseTask = CalculateCypherPhraseAsync(limit);
await Task.WhenAll(groupTask, phraseTask);
bool check = CheckEncryption(groupTask.Result, phraseTask.Result, limit);

Но более лаконичный вариант для данной конкретной реализации, предложил подписчик Руслан Петряев, где мы ожидаем результата выполнения задач непосредственно в вызове метода CheckEncryption(). Именно такую реализацию вы можете видеть на картинке выше. Так или иначе, оба варианты равнозначны и являются верными.

Всем хорошего вечера! ☕️

#капитану_на_заметку

Всем привет!

Вы когда-нибудь заглядывали в System.Collections.Concurrent? Если вам доводилось писать многопоточный код, скорее всего вы там были неоднократно. Как только мне нужно писать многопоточный код, я на 99% уверен, что найду там структуру данных, которая решит большинство моих технических вопросов. Но есть коллекция, которая была разработана для очень специфических случаев - ConcurrentBag<T>.

ConcurrentBag<T> - это потокобезопасная реализация коллекции, оптимизированная для сценариев, в которых один и тот же поток будет создавать и потреблять данные, хранящиеся в ней.

Не рекомендуется использовать её без предварительного бенчмаркинга (замеров производительности). Если вы на 100% не уверены, что вам нужен именно ConcurrentBag<T>, отдайте предпочтение ConcurrentQueue<T> ✅

#капитану_на_заметку

Всем привет!

Вы уже знаете про очень полезный атрибут [DebuggerDisplay], который находится в пространстве имён System.Diagnostics? Если нет, то только что ваш дебаггинг вышел на уровень комфорт-класса 😎. С помощью этого атрибута мы можем указать способ отображения экземпляра класса во всплывающем окне дебаггера переменной, которое появляется при наведении курсора мыши.

+1 к премудростям дебага ✅

Поделитесь в комментариях какими полезными плюшками дебага вы пользуетесь и как они помогают решать возникающие проблемы.

#капитану_на_заметку

Всем привет!

Сегодня понедельник, а значит, нужно сделать еще один шаг к чистому коду. Вы слышали про конструкцию "catch - when" в C#?

Это ещё одна суперспособность на уровне языка, которая делает программирование на C# по-настоящему чем-то особенным. Фишка в том, что мы можем фильтровать одно и то же исключение в блоке catch написав логическое выражение после оператора when. Это позволит ловить исключения одного и того же типа несколько раз, но фильтровать их по разным условиям. Данный подход сделает обработку исключений более структурной и системной. Мне нравится применять этот способ при обработке исключений, где логика обработки выходит за рамки определения типа исключения.

+1 к чистому коду ✅

Всем спокойной недели!

#codaza_спрашивает

Единственная причина для существования времени — чтобы все не случилось одновременно.

Альберт Эйнштейн

Всем привет!

Вчера не code review мне попался этот фрагмент кода. Метод проходит все модульные тесты. Я думаю, этот код сможет работать в production. Но... Кажется, он может тратить меньше времени... 🕙

Что думаете?

Любые улучшения только приветствуются 🙂

Дааа... Кажется, из последнего примера ребята действительно выжали максимум. Это был мастер-класс по code review на высоком уровне 😎 Если вы не успели пробежаться по комментариям в предыдущем посте, то сделайте это.

Итак, главную проблему, первым заметил подписчик Алексей. Он увидел, что ожидание выполнения всех задач (Task.WhenAll()) - расточительно. По логике метода необходимо:

1. Обратиться ко всем имеющимся адресам, которые возвращает метод GetReplicationUrls(). Нам предоставляют множество резервных адресов, так как подразумевается, что некоторые могут быть недоступны по самым разным причинам (неисправен, находится на техническом обслуживании и т. д.). Разумеется, какие адреса и в какой момент они будут нам доступны, нам никто не сообщит.
2. Получить цены.
3. Вернуть одну цену.

Исходя из этой логики, ожидание всех цен абсолютно не требуется. Достаточно дождаться первой полученной цены и вернуть её. В этом нам поможет статический метод WhenAny(), который реализован в классе Task. Как только одна из задач будет завершена (цена получена), мы сразу же вернём её результат. В противном случае, мы будем вынуждены ждать столько времени, сколько занимает самая длительная задача, что увеличит время выполнения метода LoadItemPriceAsync(). Это будет особенно критично в тех случаях, когда будут сетевые задержки, таймауты и прочие сценарии, которые нельзя назвать успешными.

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

На этом можно было закончить, но подписчик Alexander Radchenko заметил, что производительность можно поднять еще выше. Александр очень точно написал эту мысль в комментарии, поэтому я приведу цитату:

"Для ещё более быстрого решения надо добавить CancellationToken чтобы останавливать цикл создания задач, как только первая задача выполнена и даже возможно прерывание уже выполняемых задач."

Безусловно, в Enterprise разработке высоконагруженных систем, применить такой подход можно и нужно.

Завершил картину Руслан Петряев, предложив лаконичный вариант рефакторинга, который мне очень понравился:

private async Task<int> LoadItemPriceAsync(int itemId) =>
    await Task.WhenAny(GetReplicationServersUrls()
              .Select(async url => await LoadCurrentPriceAsync(itemId, url)))
              .Result;

Здесь не подразумевается обработка исключений. Это вам на самостоятельную работу 😉 Главная суть полностью раскрыта!

Что же... Это была прекрасная командная работа. Всем нам очень повезло поучаствовать в этом полезном образовательном действе.

Спасибо! 👍

#капитану_на_заметку

Всем привет!

Enum — это тип значения, определенный набором именованных констант и т.д. и т.п. далее по тексту из MSDN.

Это понятно. Есть вещи важнее понятных истин. Я говорю про дизайн. Вы знаете про хороший дизайн для Enum в C#?
Если нет, то скорее ловите, чтобы уже с понедельника ваш код стал выглядеть более профессионально.

Когда мы создаём новый Enum, мы всегда должны предоставлять значение по умолчанию (default value). В противном случае, первое значение в созданном Enum может быть рассмотрено как значение по умолчанию. Такое поведение нельзя считать верным и может вести к потенциально опасным и трудно отлаживаемым ошибкам.

Добавьте значение по умолчанию, которое будет адекватно вашему бизнес-домену. Это может быть "None", "Unknown" и прочее. Тем самым вы явно укажете то, как следует обращаться с вашим типом.

+1 к чистому коду ✅

Всем хороших выходных!

Всем привет! 👻

Продолжаем разбираться с шаблонами проектирования "банды четырёх (GoF)". Сегодня на повестке: Builder (Строитель). Строитель отделяет конструирование сложного объекта от его представления, так что в результате одного и того же процесса конструирования могут получаться разные представления.

Внимание❗️ Ролик может вызывать сильное чувство аппетита. Перекусите что-нибудь перед просмотром 😉

Приятного просмотра! 💙

https://www.youtube.com/watch?v=2ReKJaM2glI

#капитану_на_заметку

Всем привет!

В прошлой рубрике #капитану_на_заметку мы говорили про хороший дизайн для Enum. Сегодня мы затронем вопрос производительности использования Enum.

Получение строкового представления для перечисляемого типа — весьма частая операция. Это может потребоваться при формировании JSON, выводе данных в интерфейс Web или Desktop приложений, логировании в системы сбора логов и т. д. Для решения такой задачи, естественным действием разработчика на C# будет вызов метода ToString().

Если же значение перечисляемого типа известно заранее (на этапе компиляции), хорошей практикой является использование выражения nameof. Значение выражения nameof вычисляется во время компиляции, и это не влияет на время выполнения. В ряде случаев, это может существенно повысить общую производительность вашего приложения. Поэтому, в следующий раз, перед вызовом ToString(), задумайтесь... может лучше nameof? 😉

+1 к производительному коду ✅

Всем хороших выходных!

#codaza_спрашивает

Всем привет! 👋

Сегодня у нас еще один занятный кусочек кода, которому стоит провести code review. Как обычно, всё компилируется и все тесты проходят на ура. Сомнений нет — код рабочий. Но всё же есть ощущение что в production-среду этому методу рановато. В production предстоит работа с большим массивом данных и, возможно, этот метод еще не готов к таким нагрузкам. А может и готов...

Есть идеи? 🤔

#codaza_отвечает

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

Где же был зарыт "главный слон" 🐘? Проблема, с которой данный код никак нельзя было допускать в production-среду. Проблема была на строках 12-13:

int keyWordIndex = dataSlice.Value.TextFraction.Substring(actualPosition).IndexOf(keyWord);

Вызов метода Substring() - вот основная проблема. Дело в том, что при каждом вызове этого метода, в памяти будет создаваться полная копия строки, содержащаяся в свойстве TextFraction. Это не проблема при нечастных вызовах на небольших строках и без использования циклов. Для нашей ситуации это совершенно не годится, так как методу предстоит работать с большим массивом данных. Только представьте что может произойти с оперативной памятью при частых вызовах метода ExtractStochasticDataAsync(). И первым проблему заметил Александр Максименко, указав на то что вместо вызова Substring() следует делать вызов метода расширения для класса String - AsSpan(). Такой подход позволит не создавать копию строки TextFraction в оперативной памяти, что существенно снизит нагрузку на неё.

Далее, Александр увидел возможность для параллельной обработки данных в словаре dataSlices. При параллельной обработке нужно учитывать проблемы совместного доступа, поэтому, для словаря indexes, вместо Dictionary<int, int>, Александр взял потокобезопасную коллекцию ConcurrentDictionary<int, int>.

Метод ExtractStochasticDataAsync() является асинхронным и хорошей практикой является предоставления возможности для остановки метода (тем более метод работает в цикле с большим объемом данных). На эту проблему обратил внимание Aleksandr Radchenko, предложив использование CancellationToken.

Итоговый вариант после рефакторинга стал выглядеть так:

public async Task<IDictionary<int, int>> ExtractStochasticDataAsync(string keyWord, CancellationToken ct = default)
{
    IDictionary<int, AnalyticalDataSlice> dataSlices = await LoadAnalyticalDataSlicesAsync(ct);

    ConcurrentDictionary<int, int> indexes = new();

    var tasks = dataSlices.Select(async ds =>
    {
        ct.ThrowIfCancellationRequested();

        int actualPosition = await LoadActualPositionAsync(ct);

        int keyWordIndex = ds.Value.TextFraction
            .AsSpan(actualPosition).IndexOf(keyWord);

        indexes.TryAdd(ds.Key, keyWordIndex + actualPosition);
    });
    
    await Task.WhenAll(tasks);

    return indexes;
}

Кроме того, Aleksandr Radchenko предложил еще ряд важных улучшений с примерами листингов (за что ему отдельное спасибо). Например, использовать в качестве возвращаемого значения метода ExtractStochasticDataAsync() асинхронную реализацию интерфейса IAsyncEnumerable и оператор yield, что позволит организовать асинхронную обработку данных из вызываемого метода. Это потребует изменение выходного API у метода ExtractStochasticDataAsync(), но если это возможно по имеющимся бизнес-требованиям, сделать это точно стоит. Этот вариант будет выглядеть так:

public async IAsyncEnumerable<(int Key, int Position)> ExtractStochasticDataAsync01(string keyWord, [EnumeratorCancellation] CancellationToken ct = default)
{
    IDictionary<int, AnaliticalDataSlice> dataSlices = await LoadAnalyticalDataSlicesAsync(ct);
    
    foreach(var dataSlice in dataSlices)
    {
        int actualPosition = await LoadActualPositionAsync(ct);

        int keyWordIndex = dataSlice.Value.TextFraction
            .AsSpan(actualPosition).IndexOf(keyWord);
        
        ct.ThrowIfCancellationRequested();

        yield return (dataSlice.Key, keyWordIndex + actualPosition);
    };
}

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

Всем активным участникам огромное спасибо за вклад! 💙

#капитану_на_заметку

Всем привет!

В прошлый раз мы поговорили об использовании метода расширения AsSpan(), который можно вызывать на объектах класса String и предотвратить ненужные аллокации в оперативной памяти. В продолжении темы, мне хотелось бы рассказать про похожую возможность, но уже для коллекции List.

Возникают ситуации, когда нам нужно получить некоторый диапазон значений из List. Как поступал разработчик на C# до появления .NET5? Очень просто, он вызывал метод GetRange() и получал желаемый диапазон значений. Такое действие неминуемо сопровождается выделениями в оперативной памяти. Сегодня мы можем этого избежать и значительно снизить нагрузку на оперативную память воспользовавшись статическим методом AsSpan(), который располагается в классе CollectionsMarshal. Этот метод вернёт нам Span<T> представление данных в списке, после чего можно вызвать метод Slice() c такими же параметрами, как у GetRange().

+1 к производительному коду ✅

Всем хороших выходных!

#капитану_на_заметку

Я никогда не делаю исключений. Исключения опровергают правило.

Артур Конан Дойл

Всем привет!

Тема правильной работы с исключениями (exceptions) весьма холиварна и едва ли подлежит окончательному разрешению 🙂 Но сегодня я хочу обратить вниманием на другое — на цену. Цену использования исключений. Работаете вы с ними правильно или неправильно, держите в голове что за это придётся заплатить цену. При работе с большими массивами данных это может привести к значительной деградации производительности вашего приложения. Я не говорю о том, что мы не должны генерировать исключения, но разработчик обязан понимать, что выбрасывать исключения без аргументированной необходимости — плохая идея.

Руководствуйтесь простым правилом: Исключения для исключительных ситуаций.

Вы знаете как обработать исключение? Просто сделайте это без лишних throw 😉

+1 к исключительному коду ✅

Всем хороших выходных!

#капитану_на_заметку

Всем привет!

Спешу поделиться с вами интересным практическим случаем работы со строками. Недавно мне довелось работать с одним из австрийских сервисов обработки сообщений из различных мессенджеров (WhatsApp, Viber и пр). Ребята собирают аналитическую статистику по отправляемым сообщениям и столкнулись с тем, что данные в этой статистике, время от времени, искажались непонятным образом.

Я проанализировал исходный код сервиса и обнаружил, что проблема в подсчёте длины строки сообщений. Разработчик сервиса воспользовался свойством Length у экземпляра класса String. Это решение было логично и казалось единственно верным. Проблема в том, что люди часто используют Emoji в своих сообщениях и 1 символ Emoji не равен длине одного символа, так как для их кодировки используется Unicode.

Для правильного сбора статистки требовалась именно посимвольная длина строки. Свойство LengthInTextElements (класс StringInfo) решает именно эту задачу.

+1 к опыту работу со строками ✅

Всем хороших выходных!

Всем привет!

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

Уверен, что в самых разных источниках, вы читали, что в качестве параметра метода следует использовать IEnumerable<T>, если не требуется функциональность IList<T> или List<T>. Кроме того, хорошей практикой всегда считается следование принципу: Принимай наиболее общее (generic), а возвращай наиболее частное (specific). Это важные принципы, которых стоит придерживаться в подавляющем большинстве случаев. Всё же, бывают ситуации, в которых от этих принципов приходится отступать.

Как вы думаете, есть ли разница в определении параметра метода как IEnumerable<T> или List<T>?

Короткий ответ: да, разница есть.

Дело в том, что, когда параметр метода определяется через интерфейс IEnumerable<T>, в списке выполняются операции boxing и unboxing, что неизбежно ведет к лишним аллокациям в оперативной памяти. Как следствие, мы получаем потери в производительности. Иногда не критичные, а иногда вполне ощутимые. Таким образом, поменяв только тип параметра, мы можем существенно поднять производительность без внесения значительных правок. В моём случае, поставленные цели были достигнуты, и задача решена.

+1 к производительному коду ✅

Всем хороших выходных!

#капитану_на_заметку

Всем привет!

Как здорово генерировать исключения в секции try и ловко ловить их в секции catch 🌈 Одно удовольствие работать с синхронным кодом. Мрачнее дела обстоят при работе с асинхронным кодом. Это как классическая механика и квантовая физика: в асинхронном коде постоянно возникает "квантовая запутанность" и работает там всё по другим законам 🤯

Взгляните на два примера на картинке. В первом варианте мы не ожидаем (await) результата выполнения Task.FromException(), а сразу возвращаем Task, что приводит к несрабатыванию блока catch. Во втором примере мы решаем эту проблему ожидая результат выполнения Task.FromException().

Такая ситуация может приводить к аварийному завершению всего приложения и отыскать причины будет очень непросто. Будьте внимательны!

Поиграться с примером можно по ссылке: https://clck.ru/hcRSc

+1 к тонкостям работы с асинхронным кодом ✅

Всем хороших выходных!

#капитану_на_заметку

Всем привет!

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

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

Посмотрите на пример выше. Вам хочется установить ширину прямоугольника? Сделайте это через свойство Width. Вам хочется установить длину прямоугольника? Да просто сделайте это уже в конце концов! Не пытайтесь препятствовать собственным желаниям 😉

Рефакторингов много, но начните применять этот принцип сегодня, и вы увидите, как радуга падает на ваш исходник 🌈

+1 к простым мудростям ✅

Всем хороших выходных!

Всем привет! 👻

Недавно на канале вышло короткое видео, где я рассказал о 10 лучших практиках, которые стоит применять при разработке приложений на ASP.NET. Одна из этих практик - Глобальная Обработка Исключений (Global Exceptions Handling). В сегодняшнем ролике я раскрываю эту тему более подробно. Наливайте чайку и присаживайтесь поудобнее. Воскресенье — отличный день, чтобы обрабатывать исключения глобально.

Приятного просмотра! 💙

https://youtu.be/RAcpAc0EYV0