День 2528.
Дорогие подписчики и все разработчики ПО, с новым 2026м годом!

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

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

Ну и чтобы скоротать время после отмечания нового года, вот вам лёгкое видео от Айти Бороды. Вайбкодинг, наверное, слово года в IT-мире. Что это, с чем его едят, почему многие воспринимают его как ругательство и что нас ждёт в мире разработки, который захватывают ИИ-агенты. Приятного просмотра.

https://youtu.be/2EZxvgRiaoY

День 2529. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Начало
Тысячи статей, выступлений на конференциях и десятки книг были посвящены техническому долгу, проповедованию принципов чистого кода и надёжной архитектуры. Разработчиков учили, как его избегать, гасить, как вести переговоры с менеджерами.
В чём проблема? Не в практиках — они по-прежнему хороши. А вот технический долг не просто неправильно понимается; это принципиально неверная метафора, которая искажает наше представление о разработке ПО. И что хуже всего, мы продолжаем использовать её, потому что это единственная финансовая метафора, понятная руководителям, а это значит, что мы застряли в объяснении инженерных проблем в терминах, которые маскируют то, что происходит на самом деле.

Проблема с метафорой
Уорд Каннингем в 1992 году ввёл термин «технический долг» для описания конкретной ситуации: преднамеренный выбор быстрой реализации с пониманием того, что позже её нужно будет переписать. Как и финансовый долг, вы берёте время взаймы сейчас с обещанием вернуть его с процентами.

Но вот что на самом деле происходит в большинстве организаций:
Менеджер: «Почему эта функция так долго разрабатывается? Я думал, вы сказали, что она будет готова за две недели?»
Инженер: «Ну, у нас много технического долга, который нужно преодолеть…»
М: «Так почему вы не писали более качественный код с самого начала?»

И вот так инженеры оказываются плохими парнями. Теми, кто «накопил долг». Теми, кто «выбирал короткие пути». Теми, кто теперь тормозит развитие компании. Только это полная чушь.

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

Что происходит с техническим долгом:
М: «Нам нужно выпустить это к пятнице для демонстрации инвесторам».
И: «Этого времени недостаточно, чтобы сделать это как следует. Нам понадобится как минимум три недели, чтобы все сделать правильно».
М: «Сделайте так, чтобы это работало. Мне все равно, как».
[Три месяца спустя]
М: «Этот код — полный бардак».

Видите проблему? Инженер ничего не «заимствовал». Он не выбирал долг. Ему поставили невыполнимые задачи, и он сделал всё, что мог. А теперь его обвиняют в «процентах». Это не технический долг. Это технические последствия решений руководства.

Любой код стареет (это не долг, это энтропия)
Ещё одна странность - называть любой старый код «техническим долгом». Ваш 4-летний код, использующий .NET 6 вместо последней версии, — это не «долг». API, возвращающий XML вместо GraphQL, — это не «долг». Монолит, который все теперь хотели бы видеть в виде микросервисов, — это не «долг». Это просто код, существующий во времени.

Требования меняются. Платформы развиваются. Лучшие практики меняются. Появляются новые фреймворки. Контекст, в котором был написан ваш код, отличается от контекста, в котором он существует сегодня.

Называть это «долгом» подразумевает, что кто-то совершил ошибку. Это подразумевает халатность. Это подразумевает, что, если бы инженеры были умнее, дальновиднее, компетентнее, этой проблемы не было бы. Но так ПО не работает. Так не работает ничего. Вы не можете предсказать будущее. Невозможно создавать решения, отвечающие требованиям, которых ещё не существует. И даже если бы это было возможно, вы бы переусложнили систему и потратили время на создание гибкости, которая вам никогда не понадобится.

Продолжение следует…

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k

День 2530. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Продолжение
Начало

«Долг» - обычно правильное решение
Поговорим о том самом MVP, который вы создали 2 года назад. О том, который теперь «устарел», «нуждается в переработке», «тормозит ваше развитие».

Знаете, что ещё сделал этот MVP? Он подтвердил жизнеспособность бизнес-модели. Он привлек первую тысячу пользователей. Он сгенерировал доход, который позволяет нам вести этот разговор. Без этого «плохого кода» у вас ничего бы не было. Вы бы обанкротились в ожидании «идеальной архитектуры».

Но теперь, когда он успешен, когда он масштабируется, когда вы хотите двигаться быстрее… внезапно это становится «техническим долгом». Внезапно инженеров, которые создали то, что сделало вашу компанию жизнеспособной, обвиняют в том, что они сделали это «неправильно». Это сочетание ошибки выжившего и крепости задним умом.

То, что менеджеры называют «долгом», инженеры называют «компромиссами»
Каждое инженерное решение — это компромисс. Не некоторые из них. Не большинство. Все!
- Скорость или гибкость;
- Простота или функциональность;
- Проверенные технологии или передовые решения;
- Разработка собственными силами или покупка;
- Монолитная архитектура или микросервисы;
- SQL или NoSQL;
- Покрытие тестами или скорость выпуска.
На эти вопросы нет «правильного» ответа. Есть только «правильный для нашего текущего контекста, ограничений и приоритетов». Хорошие менеджеры это понимают. Они участвуют в принятии этих решений. Они говорят что-то вроде: «Сейчас нас заботит скорость выпуска, потому что нам нужно проверить рынок. Мы вернемся к архитектуре, когда достигнем соответствия продукта рынку».
Плохие менеджеры говорят: «Просто заставьте это работать. Разберитесь».
А потом: «Почему так много технического долга?»

Реальная проблема: Накопление невежества
Вот что на самом деле происходит, когда менеджеры не понимают накопительного характера затрат на поддержку ПО:
Год 1: «Выпускайте быстро! Не беспокойтесь о идеальном коде!»
Год 2: «Почему новые функции требуют больше времени? Раньше мы выпускали их так быстро!»
Год 3: «Нам нужно остановить всю работу над функциями и переписать код».
Это не технический долг. Это непонимание руководством того, что поддержка ПО не бесплатна. Что каждая функция увеличивает площадь покрытия. Что каждая зависимость нуждается в обновлении. Что каждый API нуждается в версионировании.
Инженеры знали это. Они говорили вам. Вы не слушали, потому что были сосредоточены на показателях следующего квартала.

А что насчёт реального срезания углов?
Да, иногда инженеры действительно халтурят. Мы пропускаем написание тестов, жёстко кодируем значения, неправильно обрабатываем ошибки, копируем и вставляем вместо того, чтобы переиспользовать код. Но это почти всегда происходит из-за внешнего давления:
- «Нам это нужно для демонстрации завтра».
- «Клиент угрожает уйти, если мы не выпустим продукт на этой неделе».
- «Мы теряем деньги и нам нужна прибыль прямо сейчас».

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

Продолжение следует…

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k

День 2531. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Продолжение
Начало
Продолжение

Неприятная правда: иногда дело действительно в плохой работе
Будем честны: иногда код действительно просто плохой, и это не вина руководства. Иногда вы нанимаете разработчика, который:
- Не понимает язык или фреймворк, который использует;
- Копирует ответы ИИ, не понимая их;
- Пишет кучу вложенных if;
- Создает «божественные» классы, потому что «проще хранить всё в одном месте»;
- Отказывается учиться или развиваться, потому что «я всегда так делал»…
А иногда ваш процесс проверки кода настолько несовершенен, что всё это попадает в прод.

Формальные ревью кода
Вы знаете, как это бывает. Кто-то открывает пул-реквест в 16:45 в пятницу. Там 847 строк изменений в 23 файлах. Рецензент бегло просматривает код, не видит очевидных ошибок и нажимает «Одобрить» и уходит на выходные.
Или ещё хуже, есть сеньор, который агрессивно воспринимает критику, и все боятся давать реальную обратную связь, т.к. когда-то кто-то предложил ему рефакторинг, и получил эссе на 2000 слов о том, почему он не прав, а затем три недели пассивно-агрессивной переписки.

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

Джун без присмотра
Встречается чаще, чем нам хотелось бы признать: вы нанимаете джуна, даёте ему задачу, и… никто не проверяет, как он справляется. Он две недели мучается, в конце концов, методом проб и ошибок добивается работоспособности и выпускает продукт. Продукт (в принципе) работает, поэтому запускается в прод.
Шесть месяцев спустя кому-то приходится модифицировать этот код, и – внезапно - всё держится на честном слове и молитвах. Никаких тестов или обработки ошибок, переменные temp1, temp2, бизнес-логика смешана с UI-кодом и запросами к БД.
Это технический долг или вина руководства? Руководство не обеспечило наставничество и контроль. Но и инженер мог попросить о помощи, посмотреть на существующий код на предмет шаблонов и т.п.

Тут и начинаются сложности. Потому что даже когда код действительно плох из-за инженерных ошибок, формулировка «технический долг» всё равно неверна, т.к. отнесение этого к «долгу» всё равно:
- Представляет это как преднамеренный компромисс (чего не было);
- Подразумевает, что долг нужно «вернуть» (это нужно исправить);
- Маскирует первопричину (проблемы с наймом, обучением, проверкой кода или стандартами).
Если вы наняли кого-то недостаточно хорошего, это проблема с наймом. Если код-ревью не выявляют проблемы - проблема с процессом. Если у команды нет стандартов - проблема с руководством. Если джуны выпускают неподдерживаемый код - проблема с наставничеством.

Ничто из этого не является «долгом». Это организационные сбои, которые проявляются как проблемы с качеством кода. И даже эти неудачи часто сводятся к решениям руководства. Кто-то решил:
- Нанять дешёвых разработчиков вместо лучших;
- Пропустить техническую часть собеседования, потому что кандидат «казался умным»;
- Не выделить время старших инженеров на проверку кода и наставничество;
- Не инвестировать в установление командных стандартов или архитектурных принципов;
- Приоритет отдавать баллам истории, а не качеству кода.
Мы постоянно возвращаемся к проблемам с руководством.

Окончание следует…

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k

День 2532. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Окончание
Начало
Продолжение 1
Продолжение 2

Когда инженерам нужно брать на себя ответственность
Как инженеры, мы должны брать на себя ответственность за своё дело. Нам необходимо:
- Действительно проверять код, а не просто одобрять пул-реквест, не глядя;
- Давать и получать обратную связь как профессионалы;
- Инвестировать в обучение и развитие;
- Просить о помощи, когда мы застряли;
- Отказывать ужасному коду в пул-реквестах, даже если неудобно перед коллегами;
- Устанавливать и поддерживать стандарты в команде.
Если вы одобрили пул-реквест, не прочитав его, вы несёте ответственность за этот код. Если вы написали небрежный код, потому что вам было лень, это ваша вина. Если вы совершаете одни и те же ошибки в течение пяти лет и отказываетесь учиться, проблема в вас.

В чём разница? Когда мы признаём эти ошибки, мы можем их исправить. Мы можем улучшить культуру проверки кода. Мы можем повысить свой уровень квалификации. Мы можем внедрить лучшие практики. Но когда мы прячемся за «техническим долгом» как за расплывчатым общим термином, мы ничего не можем исправить, потому что даже не выявляем реальную проблему.

Так как же это называть?
Вместо «технического долга» попробуйте следующие варианты:
- «Технические последствия прошлых бизнес-решений» — многословно, но точно. Это позволяет сохранить ответственность там, где ей место.
- «Затраты на обслуживание» — в каждом коде есть свои затраты. Они растут со временем. Заложите их в «бюджет».
- «Сдвиг контекста» — то, что имело смысл два года назад, сейчас не имеет смысла. Это нормально.
- «Необходимый рефакторинг» — ПО развивается. Рефакторинг — это нормально. Перестаньте относиться к нему как к наказанию.
- «Стоимость обучения» — вы не знали, что то, что вы создавали, будет успешным. Теперь знаете. Пора оптимизировать.

Итого
Технический долг — миф не потому, что коротких путей не существует. Это миф, потому что метафора искажена до неузнаваемости. Он стал способом для менеджеров:
- Обвинять инженеров в бизнес-решениях;
- Избегать ответственности за распределение ресурсов;
- Рассматривать нормальную эволюцию ПО как халатность;
- Уклоняться от ответственности за невыполнимые сроки.

Хорошие менеджеры берут на себя ответственность за компромиссы. Они говорят: «Мы выбрали скорость вместо гибкости, и теперь нужно заново оптимизировать. Это потребует времени и ресурсов. Я распределяю и то, и другое».
Плохие менеджеры используют ретроспективный анализ в качестве оружия. Они говорят: «Вы должны были сделать это правильно с первого раза. Почему так много технического долга?»

Если вы менеджер, читающий это, и вы когда-либо жаловались на технический долг, спросите себя: дали ли вы своей команде время и ресурсы, чтобы сделать это «правильно»? Знали ли вы вообще, что значит «правильно»? Или вы просто хотели, чтобы это было выпущено?

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

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

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k

День 2533. #Оффтоп
Праздники продолжаются, поэтому снова представляю вам полуразвлекательное видео.

Мы все заняты софтом, алгоритмами, оптимизациями. Но редко задумываемся, на чем весь этот софт выполняется. Максимум - выбираем SKU виртуальной машины или контейнера.

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

В общем, любителям железячек и физики должно зайти. Приятного просмотра.

https://youtu.be/MiUHjLxm3V0

День 2535. #ЗаметкиНаПолях
Снижаем Нагрузку на CPU при Использовании GitHub Actions
Если вы используете GitHub Actions на собственных серверах, вы могли заметить, что они могут быть удивительно ресурсоемкими для ЦП, даже в режиме ожидания. При более внимательном рассмотрении становится ясно, что один раннер может загружать CPU на 100%. Это не ошибка в вашем рабочем процессе; это преднамеренное проектное решение в механизме сна раннера.

Проблема: «Занятое ожидание»
Вместо использования стандартных, эффективных функций сна, предоставляемых операционной системой, раннер GitHub Actions использует цикл «занятого ожидания» (Busy-waiting). Это означает, что он постоянно проверяет системные часы в плотном цикле, ожидая истечения заданного промежутка времени. Хотя такой подход обеспечивает совместимость в широком диапазоне сред, включая некоторые без традиционных функций сна, он крайне неэффективен для подавляющего большинства систем, таких как стандартные виртуальные машины Linux или Windows. Эта постоянная проверка поддерживает полную активность CPU, что приводит к нерациональному использованию ресурсов, повышению температуры и потенциальному снижению производительности других задач на той же машине.

Решение: интеллектуальный скрипт установки режима сна
К счастью, мы можем решить эту проблему, заменив стандартный скрипт установки режима сна на более интеллектуальную версию. Цель — использовать наиболее эффективный метод установки режима сна, доступный в системе. Вот скрипт, который отдаёт приоритет стандартным командам установки режима сна и предоставляет резервные варианты, обеспечивая как эффективность, так и совместимость.

Перейдите в папку, где установлен ваш раннер, и отредактируйте файл safe_sleep.sh. Замените его содержимое следующим:

#!/bin/bash

# Используем нативную команду 'sleep', если доступна (наиболее эффективно)
if [ -x "$(command -v sleep)" ]; then
    sleep $1
    exit 0
fi

# Пробуем 'read' с таймаутом (встроено в bash)
if [[ -n "$BASH_VERSINFO" && "${BASH_VERSINFO[0]}" -ge 4 ]]; then
    read -rt "$1" <> <(:) || :
    exit 0
fi

# Креативный вариант с 'ping'
if [ -x "$(command -v ping)" ]; then
    ping -c $1 127.0.0.1 > /dev/null
    exit 0
fi

# Оригинальное «занятое ожидание» (в крайнем случае)
SECONDS=0
while [[ $SECONDS != $1 ]]; do
    :
done

Этот скрипт сначала пытается использовать стандартную команду sleep. Если она недоступна, он пытается использовать read с таймаутом, что является встроенной функцией оболочки и всё ещё эффективнее, чем ожидание в активном режиме. В качестве запасного варианта используется ping. Только если ни один из этих вариантов недоступен, скрипт возвращается к исходному циклу «занятого ожидания».

Предупреждение:
Средства запуска GitHub Actions могут обновляться автоматически. При обновлении ваши изменения в файле safe_sleep.sh могут быть перезаписаны. Чтобы гарантировать сохранение исправления, вы можете настроить задание cron или запланированную задачу для периодического повторного применения этого изменения.

Дополнительные ресурсы
Для получения более подробной технической информации и обсуждения этой темы в сообществе вы можете обратиться к этим проблемам и пул-реквестам на GitHub:
- https://github.com/actions/runner/issues/2380
- https://github.com/actions/runner/issues/3792
- https://github.com/actions/runner/pull/3870

Источник: https://www.meziantou.net/reduce-github-actions-runner-cpu-usage.htm

День 2536. #Карьера
Топ Советов по Повышению Продуктивности. Часть 3
Часть 1
Часть 2

3. Правило 15 минут: секретное оружие против прокрастинации и бесконечных отвлекающих задач
У каждого разработчика есть два заклятых врага: задача, которую не хочется начинать, и задача, от которой невозможно оторваться.

Сценарий 1: нужно переписать устаревший модуль, которого все боятся касаться. С 800 строками в одном файле, без тестов и с комментариями на трёх разных языках. Одна мысль об этом уже изматывает. Поэтому вы… проверяете email и чаты, проводите генеральную уборку клавиатуры и т.п. Всё что угодно, лишь бы не погружаться в эту бездну.

Сценарий 2: Вы выясняете, почему медленно загружается страница. Нужно проверить всего несколько метрик, это займёт десять минут. Три часа спустя вы перестроили всю свою инфраструктуру мониторинга, прочитали 12 статей о производительности запросов в EF и сделали бенчмарк для сравнения трёх разных решений — но всё ещё не решили первоначальную проблему.

Правило 15 минут
1. Для задач, которых вы избегаете: пообещайте себе, что поработаете над задачей всего 15 минут. Через 15 минут вы сможете остановиться без чувства вины.
2. Для задач, в которые вы вкладываете слишком много сил: установите 15-минутный таймер, прежде чем углубляться в какую-либо тему. Когда он зазвонит, спросите себя: «Действительно ли это решает мою проблему, или я просто наслаждаюсь процессом исследования?»

Почему это работает?
Самое сложное — начать. Наш мозг запрограммирован на избегание дискомфорта, и большие, неопределённые задачи провоцируют эту реакцию избегания. Но 15 минут? Это не страшно. Любой сможет делать что угодно в течение 15 минут. Вы не обязуетесь закончить — вы обязуетесь начать.
Прелесть в том, что в большинстве случаев вы не остановитесь через 15 минут. Как только вы начнёте, инерция возьмёт верх. Вы обнаружите, что задача не так уж и сложна, как вы себе представляли. Или же вы войдете в состояние потока и совсем забудете о таймере. Правило 15 минут — это психологический лом для вашей мотивации.

Что касается отвлечений, проблема обратная. Разработчики от природы любопытны и стремятся решать проблемы. Мы видим интересное ответвление, и наш мозг активизируется: «О, я мог бы это оптимизировать! Дайте-ка я быстренько…» Проходит 4 часа, а вы ничего не сделали для достижения реальной цели.
15-минутный таймер заставляет быть предельно честным:
- Важен ли для текущей задачи рефакторинг этой функции?
- Нужно ли изучить все внутренности EF, чтобы этот запрос к БД работал оптимальнее?
Иногда ответ — да! Иногда действительно нужно копнуть глубже. Но часто ответ — нет, и правило 15 минут даёт вам право сделать прагматичный выбор, а не перфекционистский.

Практика
1. Ведите список «задач на 15 минут». Того, чего вы избегали: написание документации для модуля, исправление проблем с тестами, обновление зависимостей и т.п. Когда у вас появится время в течение дня (отмена встречи, ожидание тестов/сборки), выполните одну 15-минутную задачу.
За месяц вы выполните 20-30 таких небольших задач, которые иначе откладывались бы навсегда. Код станет лучше, «технический долг» уменьшится, появится чувство удовлетворения.

2. Когда вы ловите себя на том, что исследуете что-то отвлечённое, установите таймер и спросите себя: «Какой минимум нужно знать, чтобы двигаться дальше?» Найдите ответ на этот конкретный вопрос, задокументируйте полученные знания в комментарии или на странице вики для дальнейшего использования, а затем вернитесь к работе. Вы усвоили знания, не утонув в них.

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

Источник: https://dev.to/thebitforge/top-10-productivity-hacks-every-developer-should-know-151h

День 2537. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

15. Промежуточное ПО в ASP.NET Core
«Объясните роль промежуточного ПО в приложениях ASP.NET Core. Приведите пример того, как можно реализовать пользовательское промежуточное ПО в приложении .NET, и опишите сценарий, в котором это промежуточное ПО может быть особенно полезно».

Хороший ответ
Промежуточное ПО в ASP.NET Core — это блоки кода (классы), которые собираются в конвейер приложения для обработки запросов и ответов. Каждый компонент в конвейере промежуточного ПО отвечает за вызов следующего компонента в цепочке или за прерывание цепочки, если это необходимо. Компоненты промежуточного ПО выполняются в порядке их добавления в конвейер приложения.

Промежуточное ПО может обрабатывать такие задачи, как аутентификация, обработка ошибок, обслуживание статических файлов и сложная обработка запросов. Оно также может изменять входящий запрос или исходящий ответ. Некоторые популярные компоненты промежуточного ПО уже реализованы в платформе .NET: аутентификация, авторизация, обслуживание статических файлов и т.п. Для реализации пользовательского промежуточного ПО в приложении .NET нужно определить класс промежуточного ПО с методом Invoke или InvokeAsync, который обрабатывает контекст HTTP.

Вот пример пользовательского промежуточного ПО в .NET-приложении, которое регистрирует время выполнения каждого HTTP-запроса:

using System.Diagnostics;

public class RequestTimingMiddleware
{
  private readonly RequestDelegate _next;

  public RequestTimingMiddleware(
   RequestDelegate next)
  {
    _next = next;
  }

  public async Task InvokeAsync(
   HttpContext context)
  {
    var sw = Stopwatch.StartNew();
    await _next(context);
    sw.Stop();
    var time = sw.ElapsedMilliseconds;
    context.Response.Headers.Add(
      "X-Response-Time-ms", time.ToString());
  }
}

// в Program.cs
var builder =
 WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseMiddleware<RequestTimingMiddleware>();

app.Run(async (context) =>
{
  await context.Response
   .WriteAsync("Hello Middleware!");
});

app.Run();

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

Преимущества
- Модульность: компоненты промежуточного ПО могут быть разработаны, протестированы и повторно использованы в различных приложениях.
- Гибкость: позволяет создавать конвейер обработки запросов, соответствующий потребностям приложения.
- Контроль: вы получаете контроль над запросом и можете манипулировать как объектами запроса, так и объектами ответа.
Понимая и используя промежуточное ПО, разработчики могут значительно улучшить функциональность и производительность приложений ASP.NET Core.

Часто встречающийся неверный ответ
«Чтобы добавить промежуточное ПО в .NET, можно использовать app.Use() в Program.cs и добавить лямбда-функцию с любым кодом для обработки запроса и ответа непосредственно внутрь этого метода».

Почему это неверно
- Чрезмерное упрощение использования промежуточного ПО: встроенный код в Program.cs с использованием app.Use() удобен для простых сценариев, но не подходит для сложного или многократно используемого промежуточного ПО.

- Игнорирование лучших практик: написание сложной логики непосредственно в Program.cs может привести к коду, который трудно поддерживать и тестировать. Это нивелирует преимущества создания отдельных классов, инкапсулирующих функциональность и помогающих тестировать логику.

Обычно эта ошибка возникает, когда разработчики знакомы с настройкой промежуточного ПО на базовом уровне, но не обладают глубокими знаниями лучших практик создания масштабируемых и поддерживаемых компонентов промежуточного ПО в ASP.NET Core.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

День 2538. #Оффтоп
Под конец праздников предлагаю вам развлекательное видео от канала The PrimeTime. Я уже, кажется, рекомендовал какие-то из его видео. Автор - бывший разработчик из Netflix и частенько, с юмором, комментирует статьи по разработке, новости ИТ-индустрии (вроде очередного краха Cloudflare) и рассказывает прочие истории из мира разработки.

Это его видео про… пузырьковую сортировку.

Да. Это алгоритм сортировки, которому нас учили в школе/институте (обычно даже не упоминая про его неэффективность). Причина в его невероятной простоте.

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

https://youtu.be/qGH8gKdpZMQ

День 2539. #ЗаметкиНаПолях
Создаём BinaryData из MemoryStream без Копирования
При работе с BinaryData и MemoryStream в .NET может потребоваться преобразование данных потока в экземпляр BinaryData. Типичный подход с использованием BinaryData.FromStream() предполагает копирование всего буфера, что может повлиять на производительность и увеличить объем выделяемой памяти. Однако существует более эффективный способ достижения этой цели без копирования памяти.

Проблема с BinaryData.FromStream()
Стандартный способ создания BinaryData из потока прост, но сопряжен с затратами:

var stream = new MemoryStream();
stream.Write([1, 2, 3]);
stream.Seek(0, SeekOrigin.Begin);

// Это требует копирования памяти
var data = BinaryData.FromStream(stream);

При вызове метода BinaryData.FromStream(), метод считывает поток и копирует его содержимое в новый буфер. Для больших потоков или приложений, где производительность критична, это дополнительное копирование может быть неэффективным.

Подход без копирования
Если вы работаете с MemoryStream, вы можете напрямую получить доступ к его базовому буферу и создать экземпляр BinaryData без копирования:

var stream = new MemoryStream();
stream.Write([1, 2, 3]);

// Это не требует копирования памяти
var data = new BinaryData(stream.GetBuffer().AsMemory(0, (int)stream.Position));

Этот подход использует GetBuffer() для доступа к базовому массиву байт MemoryStream, а затем оборачивает его в срез Memory<byte>, представляющий только записанную часть. Конструктор BinaryData принимает ReadOnlyMemory<byte>, поэтому преобразование происходит неявно.

Предупреждение: Изменчивость буфера: поскольку вы используете общий буфер, любые изменения исходного буфера MemoryStream могут повлиять данные в BinaryData. Убедитесь, что вы закончили запись в поток, прежде чем создавать BinaryData.

Интересно, что сама реализация BinaryData.FromStream создаёт новый экземпляр BinaryData таким же образом.

Источник: https://www.meziantou.net/zero-copy-binarydata-creation-from-memorystream-in-dotnet.htm