.NET Разработчик

День 2628. #SystemDesign101
Что Происходит, Когда вы Вводите google.com в Браузере?

1. Вы вводите адрес веб-сайта в адресную строку браузера.

2. Браузер сначала проверяет свой кэш. Если адрес не найден в кэше, он должен найти IP-адрес.

3. Начинается поиск DNS (представьте, что вы ищете номер телефона). Запрос проходит через различные DNS-серверы (корневой, TLD - сервер имен доменов верхнего уровня - и авторитативный). Наконец, извлекается IP-адрес.

4. Браузер инициирует TCP-соединение, начиная с рукопожатия. Например, в случае HTTP 1.1 клиент и сервер выполняют трёхстороннее TCP-рукопожатие с сообщениями SYN, SYN-ACK и ACK.

5. Браузер отправляет HTTP-запрос на сервер, и сервер отвечает файлами HTML, CSS и JS.

6. Браузер обрабатывает ответ. Он анализирует HTML-документ и создаёт деревья DOM и CSSOM.

7. Браузер выполняет код JavaScript и отображает страницу, проходя через различные этапы (токенизатор, парсер, дерево рендеринга, компоновка и отрисовка).

8. Веб-страница появляется на экране.

Источник: https://bytebytego.com/guides/what-happens-when-you-type-google/

День 2627. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Окончание
Часть 1
Часть 2
Часть 3
Часть 4

Ресурсы
Существует множество видео, курсов и книг по теме. Платные курсы рекламировать не буду, решайте сами, стоят ли они того.

Книги:
1) «System Design. Подготовка к сложному интервью» Сюй А.
- Красивые диаграммы;
- Более 15 вариантов системного проектирования.

2) «Высоконагруженные приложения. Программирование, масштабирование, поддержка» Клеппман М.
- Глубокий технический анализ;
- Читать после изучения основ;
- Отличный справочник.

Сдвиг мышления, который изменил всё
Перед изучением системного проектирования.
Синдром самозванца:
- «Я недостаточно опытен»
- «Это слишком сложно»
- «Я никогда не пойму распределённые системы»

Тревога перед собеседованием:
- Надеюсь, я сталкивался с этой проблемой;
- Паника, когда застреваю;
- Заучивание решений.

Карьерный застой:
- Ограничен задачами по программированию;
- Неучастие в принятии архитектурных решений;
- Мимо руководящих должностей.

После освоения системного проектирования
Уверенность:
- Возможность обсуждать архитектуру с кем угодно;
- Понимание компромиссов;
- Мышление в масштабе.

Успех на собеседованиях:
- Возможность ответить на любой вопрос по проектированию;
- Сосредоточенность на размышлении, а не на запоминании.

На собеседованиях по системному проектированию (и в реальной работе):
Плохой ответ: «Мы будем использовать микросервисы и Kafka».
Хороший ответ: «Мы могли бы использовать микросервисы для независимого масштабирования, но, учитывая размер нашей команды (5 инженеров) и текущий масштаб (10 000 пользователей), хорошо структурированный монолит с чёткими границами модулей будет проще в обслуживании. Мы можем выделить сервисы позже, когда достигнем 100 тыс пользователей или нам потребуется независимое развёртывание».

Что изменилось:
- Продемонстрировал понимание компромиссов;
- Учел команду и масштаб;
- Предоставил обоснование;
- Обсудил эволюцию.

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

Итого
Проектирование систем — это навык, а не талант.
Вам не нужны:
- 10 лет опыта;
- Степень в области компьютерных наук;
- Фотографическая память;
- Природный талант.

Нужно только:
- Любопытство изучать, как всё работает;
- Готовность к систематическому обучению;
- Практика проектирования реальных систем;
- Терпение.

Проектирование систем — это не магия. Это навык, которому можно научиться, как приготовление пищи, вождение или игра на гитаре. Начните с основ. Практикуйтесь постоянно. Развивайте свои знания. Помните: каждый архитектор, каждый сеньор, каждый системный проектировщик начинал с того места, где вы сейчас.

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

День 2626. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Продолжение
Часть 1
Часть 2
Часть 3

6. Применение в работе (реальные системы и ограничения)
Теория бесполезна, пока вы не создадите что-то реальное. На работе я был в команде, разрабатывавшей систему обработки платежей:
- Большой объём транзакций;
- Требуется строгая согласованность данных;
- Нулевая терпимость к потере данных;
- Сложная бизнес-логика.

Что я применил
1) Архитектурное решение - разделить монолит на сервисы:
- платежи;
- уведомления;
- бухгалтерия;
- обнаружение мошенничества.
Почему: Каждый сервис имеет разные потребности в масштабировании.

2) Стратегия коммуникаций:
- Синхронная: REST API для операций, ориентированных на пользователя.
- Асинхронная: Kafka для внутренних событий:
Платеж обработан
→ Уведомить пользователя;
→ Обновить учётную запись;
→ Провести проверку на мошенничество.

3) Согласованность данных:
Проблема: деньги не могут быть дублированы или потеряны.
Решение:
- Ключи идемпотентности (предотвращение дублирования транзакций);
- Паттерн Saga для распределённых транзакций;
- Паттерн Источники Событий для аудита.

4) Надёжность:
- Прерыватели цепи (предотвращение каскадных сбоев)
- Повторные попытки с экспоненциальной задержкой;
- Очереди недоставленных сообщений.

5) Мониторинг:
- Отслеживание задержек (P50, P95, P99);
- Оповещения об уровне ошибок;
- Уровень успешности транзакций;
- Панель мониторинга в реальном времени.

Создание реальных систем научило меня:
1) Идеальных проектов не существует
- Каждый выбор — это компромисс;
- Бизнес-ограничения имеют значение;
- Технический долг неизбежен.

2) Эксплуатация важнее проектирования
- Мониторинг и оповещения критически важны;
- Отладка распределённых систем сложна;
- Необходимо планирование отката.

3) Важна команда
- Самый лучший проект ничего не значит, если команда не может его поддерживать;
- Документация имеет решающее значение;
- Привлечение новых инженеров занимает время.

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

7. Я обучал других (лучший способ учиться)
Обучение выявляет пробелы в понимании.

Что я начал делать
1) Наставлял младших инженеров:
- Объяснял кэширование, базы данных, масштабирование;
- Разбирал реальные системные проекты;
- Отвечал на их вопросы «почему».

2) Проводил внутренние технические презентации:
- «Как работает наша платежная система»;
- «Введение в очереди сообщений»;
- «Базы данных: когда что использовать».

3) Писал посты в блоге с диаграммами:
- Помогает систематизировать мысли;
- Приходится ясно объяснять;
- Появляется обратная связь от читателей.

4) Проводил пробные собеседования с коллегами:
- Практика в формулировании мыслей;
- Умение справляться с трудностями;
- Разные подходы к решению.

Почему обучение сработало?
Если вы не можете объяснить что-то просто, значит, вы недостаточно хорошо это понимаете.

Каждый раз, когда я обучал кого-то:
- Я прояснял собственное мышление;
- Я обнаруживал пробелы в своих знаниях;
- Я учился на вопросах, на которые не мог ответить.

Преподавание превращает понимание в мастерство.

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

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

День 2625. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Продолжение
Начало
Продолжение

5. Я проектировал реальные системы (на бумаге, а затем в коде)
Теория без практики бесполезна. Освоив основы, я перестал просто наблюдать. Я начал проектировать системы. Каждое воскресенье я выбирал реальную систему: WhatsApp, YouTube, Uber, Instagram, TinyURL, Netflix, Twitter, Dropbox.

Шаблон разработки системы
1) Функциональные требования (Что нужно делать?)
Пример (Twitter):
- Публиковать твиты (280 символов);
- Подписываться на пользователей;
- Просматривать ленту (твиты от людей, на которых вы подписаны);
- Лайки/ретвиты.

2) Нефункциональные требования (Масштабируемость, производительность, доступность)
- 300 млн активных пользователей;
- 500 млн твитов в день;
- Загрузка ленты <300 мс;
- 99,95% времени безотказной работы.

3) Оценка (приблизительные расчёты)
Хранилище:
- 500 млн твитов в день × 280 символов × 365 дней = 51 ТБ/год (только текст);
- Фотографии: 200 млн/день × 200 КБ = 40 ТБ/день;
- Видео: отдельный расчёт.

Трафик:
500 млн твитов/день ÷ 86400 секунд = ~5800 твитов/секунду.
Пик: 5x среднее значение = 29000 твитов/секунду

4) Высокоуровневый дизайн (нарисуйте архитектуру)
Клиент (веб/мобильное приложение) -> Балансировщик нагрузки -> API-серверы (сервис твитов, сервис ленты, сервис пользователей) -> Кэш (Redis) + БД (PostgreSQL, Cassandra) -> Объектное хранилище (S3 для медиафайлов).

5) Детальный дизайн (подробный анализ компонентов)
Как сгенерировать ленту?
- Подход 1: Пул-модель (интенсивное чтение)
Когда пользователь открывает приложение, запросить все подписки, получить последние твиты, объединить и отсортировать по времени.
Проблема: медленно для пользователей, подписанных на тысячи человек.

- Подход 2: Пуш-модель (интенсивная запись)
Когда кто-то публикует твит, отправить его во все ленты подписчиков. Быстрое чтение (предварительно вычислено).
Проблема: дорого для знаменитостей (миллионы подписчиков).

- Подход 3: Гибридный
Пул для твитов знаменитостей. Пуш для обычных пользователей.

6) Масштабирование и оптимизация
- Добавить кэширование (Redis);
- Шардирование базы данных (по user_id);
- Асинхронная обработка (очереди сообщений);
- CDN для медиафайлов.

7) Обработка сбоев
- Что если БД выйдет из строя? (Репликация)
- Что если сервер приложения выйдет из строя? (Проверки работоспособности балансировщика нагрузки)
- Что если кэш выйдет из строя? (стратегия Cache-aside).

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

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

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

День 2624. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Продолжение
Начало

3. Я перестал смотреть обучающие видео и начал смотреть, как люди думают
Переломный момент: пробные собеседования. Вместо того чтобы смотреть, как кто-то объясняет концепции, я смотрел, как люди решают задачи в реальном времени.

Обучающие видео учат вас, что делать. Пробные собеседования учат, как думать. Кандидаты на пробных собеседованиях:
- Задавали уточняющие вопросы;
- Совершали ошибки и исправляли их;
- Обсуждали компромиссы;
- Меняли подходы в процессе проектирования.
Я научился процессу, а не только ответам.

Что я узнал, наблюдая?
1) Всегда задавайте уточняющие вопросы
- Каков масштаб? (1000 пользователей? 1 миллиард?)
- Каковы основные функции?
- Что важнее: скорость или стабильность?
- Для чего мы оптимизируем (время или размер)?

2) Чётко определите требования
Функциональные:
- Публикация фото;
- Подписка на других;
- Просмотр ленты.

Нефункциональные:
- 100 миллионов активных пользователей в день;
- Загрузка ленты менее чем за 200 мс;
- 99,9% времени безотказной работы;
- 10 миллионов фотографий загружается ежедневно.

3) Всегда обсуждайте компромиссы
Никогда не говорите: «Мы будем использовать Redis для кэширования».
Говорите: «Мы будем использовать Redis для кэширования, потому что он работает в оперативной памяти (быстро), но нам понадобится стратегия резервного копирования, поскольку данные изменчивы».

4. Я начал рисовать (хотя не умею)
Неожиданное открытие: эскизы помогли во всём разобраться.
Я не художник. Мои диаграммы — это просто прямоугольники и стрелки. Но рисунок «клиент → балансировщик нагрузки → серверы приложений → база данных» позволяет наглядно представить абстрактные понятия.

1) Поток запроса стал реальным
Когда я нарисовал путь запроса пользователя, стало:
- Видно, где возникают узкие места;
- Понятно, почему помогает кэширование;
- Очевидны точки отказа.

2) Компоненты обрели смысл
Рисование поможет понять:
- Зачем размещать кэш между приложением и БД;
- Где разместить очередь сообщений;
- Когда следует разделять на микросервисы.

3) Компромиссы стали очевидны
Рисование двух подходов рядом покажет:
- Какой дизайн проще;
- Какой масштабируется лучше;
- Какой стоит дороже.

Процесс рисования
1) Нарисуйте счастливый сценарий (всё работает);
2) Добавьте сценарии сбоев (что ломается?);
3) Добавьте решения (кэширование, репликация, балансировка нагрузки);
4) Оцените показатели (запросы в секунду, хранилище, пропускная способность).

Даже сегодня, когда я застреваю, я беру бумагу и ручку. 5-минутный набросок часто даст больше ясности, чем 2 часа чтения.

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

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

День 2623. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Начало
Путь от провала на собеседовании до проектирования масштабируемых производственных систем.
Автор оригинала: Soma Sharma

Собеседование, которое изменило всё
Google. Второй раунд. Собеседование по системному проектированию: «Спроектируйте ленту Instagram для 2 миллиардов пользователей». У меня в голове всё помутнело. Я начал мямлить что-то о REST API. Упомянул MySQL. Поговорил о кэшировании… А потом тишина. Я понятия не имел, как это делать.
Шесть месяцев спустя я успешно прошёл собеседования по проектированию систем в Meta, Amazon и Netflix. Вот путь от полной растерянности до уверенного в себе системного проектировщика.

1. Я признал, что ничего не знал (и это нормально)
Годами я избегал проектирования систем. Я видел видео под названием «Разрабатываем Твиттер» и думал: «Это для архитекторов, а не для разработчиков, как я». Нет. Проектирование систем — это для всех, кто хочет понять, как ПО работает в масштабе. Я перестал спрашивать: «Достаточно ли я умён для этого?» и начал спрашивать: «Что нужно изучить в первую очередь?»

Проектирование систем — это набор концепций:
1) Инфраструктура:
- Как запросы проходят через интернет;
- Что происходит, когда вы вводите URL-адрес;
- DNS, балансировщики нагрузки, CDN.

2) Данные:
- Где хранить различные типы данных;
- Как сделать БД быстрыми;
- Когда использовать SQL, а когда NoSQL.

3) Масштабирование:
- Обработка 1 тыс пользователей против 1 млн;
- Стратегии кэширования;
- Горизонтальное и вертикальное масштабирование.

4) Надёжность:
- Что происходит при сбоях серверов;
- Как избежать единой точки отказа;
- Стратегии резервного копирования и восстановления.

2. Я разбил «проектирование систем» на части
1) Основы (недели 1–2)
Что происходит, когда вы набираете google.com?
- Поиск DNS (домен → IP-адрес);
- Установление TCP-соединения;
- Отправка HTTP-запроса;
- Обработка запроса сервером;
- Отправка ответа;
- Отображение страницы браузером.

Изученные концепции:
- DNS (телефонная книга интернета);
- Балансировка нагрузки (распределение трафика);
- CDN (сети доставки контента);
- Протоколы HTTP/HTTPS.

2) Данные и хранилища (недели 3–4)
SQL или NoSQL — когда что использовать?
Изученные концепции:
- SQL: структурированные данные, связи, ACID-транзакции;
- NoSQL: гибкая схема, горизонтальное масштабирование, итоговая согласованность;
- Индексирование: ускорение запросов в 100 раз;
- Репликация: копирование данных для повышения надёжности;
- Шардинг: разделение данных между несколькими БД.
Вывод: нет «лучшей» БД, есть подходящая для конкретного случая.

3) Методы масштабирования (недели 5–6)
Как системы обрабатывают миллионы пользователей?
- Вертикальное масштабирование: большие серверы (ограниченно, дорого);
- Горизонтальное масштабирование: больше серверов (неограниченно, сложно).

Кэширование:
- Хранение часто используемых данных в памяти (Redis, Memcached);
- 90% запросов попадают в кэш, а не в БД;
- Ускоряет работу систем в 100 раз.

Балансировка нагрузки:
- Распределение запросов между несколькими серверами: по очереди, по наименьшему количеству соединений, по хэшу IP;
- Предотвращает перегрузку какого-либо отдельного сервера.

Очереди сообщений:
- Разделение сервисов;
- Обработка пиковых нагрузок;
- Асинхронная обработка задач.

4) Архитектурные шаблоны (недели 7–8)
Монолитная архитектура:
✅ Простота разработки и развёртывания;
✅ Лёгкость понимания;
❌ Сложность масштабирования отдельных частей независимо друг от друга;
❌ Сбой в одном месте ведёт к сбою всей системы.

Микросервисы:
✅ Независимое масштабирование компонентов;
✅ Разные команды отвечают за разные сервисы;
❌ Сложное развёртывание;
❌ Проблемы распределённых систем.

Архитектура, управляемая событиями:
- Сервисы взаимодействуют посредством событий;
- Слабая связанность;
- Kafka, RabbitMQ для передачи сообщений.

Архитектура — это не вопрос «что лучше», а вопрос «что подходит для вашего масштаба и команды».

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

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

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

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

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

- Регулярная коммуникация: я выступаю за ежедневные совещания или встречи в виртуальном формате. Эти встречи помогают всем быть в курсе прогресса проекта и любых препятствий, которые могут потребовать решения. Например, во время недавнего проекта мы использовали Microsoft Teams для ежедневных митингов, что поддерживало вовлечённость и информированность удалённых членов команды.

- Проверки кода: внедрение надёжного процесса проверки кода имеет жизненно важное значение. Мы используем пул-реквесты, которые не только облегчают коллегиальную проверку, но и интегрируют проверки в конвейер CI/CD, где код автоматически собирается и запускаются тесты. Этот процесс гарантирует, что код соответствует стандартам качества до слияния, и способствует обмену знаниями и наставничеству внутри команды.

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

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

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

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

Часто встречающийся плохой ответ
«Пока каждый выполняет свою работу и соблюдает сроки, нет особой необходимости в дополнительном сотрудничестве или частых встречах. Мы просто отправляем дневные отчёты через e-mail или общаемся в чатах, чтобы держать всех в курсе».

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

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

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

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

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

День 2621. #ЧтоНовенького #МоиИнструменты
Bookmark Studio Закладки на Стеройдах в Visual Studio
Закладки в Visual Studio всегда были простой и надёжной функцией. Многие разработчики регулярно ими пользуются. Он полезны, но имеют несколько недостатков, которые мешали им быть настолько эффективными и актуальными, насколько они могли бы быть.

Навигация - одна из самых больших проблем. Можно было перемещаться между закладками, но не было простого способа перейти непосредственно к конкретной закладке с помощью клавиатуры. Это неудобно, когда закладок больше нескольких штук. Ещё один распространённый запрос пользователей – возможность делиться закладками с коллегами или повторно использовать их в разных репозиториях, ветках или пул-реквестах.

Bookmark Studio - новое экспериментальное расширение Visual Studio от Мэдса Кристенсена, которое развивает существующий опыт работы с закладками. Вот его основные функции.

1. Навигация по слотам. Закладки можно назначать слотам с 1 по 9 и переходить к ним напрямую с помощью простых сочетаний клавиш, таких как Alt+Shift+1 – Alt+Shift+9. Это делает закладки более продуманными и удобными для быстрого доступа к нескольким важным разделам. Новые закладки автоматически назначаются следующему доступному слоту, если это возможно, поэтому быстрая навигация часто работает без дополнительной настройки. Bookmark Studio также интегрируется с существующими командами закладок Visual Studio, т.е. текущие сочетания клавиш продолжат работать.

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

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

4. Экспорт. Закладки часто наиболее ценны, когда они отражают намерение, а не просто местоположение. Bookmark Studio позволяет легко экспортировать закладки в виде обычного текста, Markdown или CSV. Т.е. вы можете включать закладки в пул-реквесты, делиться с коллегами или перемещать полезные наборы закладок между репозиториями.

5. Отслеживание. Bookmark Studio отслеживает закладки по мере перемещения текста во время редактирования, поэтому они остаются прикрепленными к соответствующему коду, а не смещаются на неправильную строку.

Итого
Если вы уже используете закладки в Visual Studio, Bookmark Studio покажется вам знакомым за считанные минуты. А если вы когда-либо хотели, чтобы закладки могли делать немного больше, это расширение стоит посмотреть.

Источник: https://devblogs.microsoft.com/visualstudio/bookmark-studio-evolving-bookmarks-in-visual-studio/

День 2620. #ЗаметкиНаПолях
Паттерн Адаптер: Упрощаем Интеграцию со Сторонними Сервисами. Окончание
Начало

Пример из реальной жизни: интеграция с облачным хранилищем
Представьте себе систему, поддерживающую несколько облачных провайдеров:
- Amazon S3
- Azure Blob Storage
- Google Cloud Storage
У каждого провайдера свои SDK и API. Без адаптера код становится тесно связанным с конкретной реализацией.

1. Определение общего интерфейса

public interface ICloudStorage
{
  Task UploadAsync(string container, 
   string file, Stream stream);
  Task<Stream> DownloadAsync(
   string container, string file);
  Task DeleteAsync(string container, 
   string file);
}

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

2. Реализуем адаптер (пример для Google Cloud)

public class GoogleCloudStorageAdapter 
 : ICloudStorage
{
  private readonly StorageClient _client;
 
  public GoogleCloudStorageAdapter(
   StorageClient client)
  {
    _client = client;
  }
 
  public async Task UploadAsync(
   string container, string file, Stream stream)
  {
    await _client.UploadObjectAsync(
     container, file, null, stream);
  }
 
  public async Task<Stream> DownloadAsync(
   string container, string file)
  {
    MemoryStream stream = new();
 
    await _client.DownloadObjectAsync(
     container, file, stream);
    stream.Position = 0;
 
    return stream;
  }
 
  public async Task DeleteAsync(
   string container, string file)
  {
    await _client.DeleteObjectAsync(container, file);
  }
}

Адаптер:
- оборачивает SDK от Google,
- приводит вызовы к вашему интерфейсу,
- скрывает детали реализации.

3. Настройка внедрения зависимостей

builder.Services
 .AddTransient<Func<string, ICloudStorage>>(
  sp => provider =>
 {
   return provider switch
   {
     "Azure" => sp.GetRequiredService<AzureBlobStorageAdapter>(),
     "Google" => sp.GetRequiredService<GoogleCloudStorageAdapter>(),
     "AWS" => sp.GetRequiredService<S3StorageAdapter>(),
     _ => throw new ArgumentException("Неподдерживаемый провайдер")
  };
});

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

Когда использовать Адаптер
- интеграция сторонних API,
- работа с устаревшими системами,
- стандартизация нескольких провайдеров,
- переключение реализаций.

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

Источник: https://thecodeman.net/posts/simplifying-integration-with-adapter-pattern

День 2619. #ЗаметкиНаПолях
Паттерн Адаптер: Упрощаем Интеграцию со Сторонними Сервисами. Начало
Интеграция сторонних сервисов в ваше приложение может быстро стать сложной задачей. Разные API имеют разные форматы запросов, механизмы аутентификации и структуры ответов. Со временем это приводит к тесно связанному коду, который трудно поддерживать, тестировать и расширять. Именно здесь проявляется преимущество паттерна Адаптер.

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

Сценарий
Есть приложение, использующее следующий интерфейс:

public interface IPaymentProcessor
{
  void ProcessPayment(decimal amount);
}

Всё приложение использует эту абстракцию. Однако, есть существующий сервис, производящий оплату:

public class LegacyPaymentService
{
  public void MakePayment(string amount)
  {
    // обработка оплаты
  }
}

Проблемы:
- сигнатуры методов отличаются;
- типы параметров отличаются;
- изменить существующий сервис невозможно.

Решение
1. Создаём адаптер

public class PaymentAdapter(
 LegacyPaymentService legacyService) : 
 IPaymentProcessor
{
  public void ProcessPayment(decimal amount)
  {
    var amntStr = amount.ToString("F2");
    legacyService.MakePayment(amntStr);
  }
}

Адаптер:
- реализует интерфейс приложения (IPaymentProcessor);
- преобразует десятичное число в строку;
- делегирует вызов устаревшему сервису.
Приложение остаётся чистым и не знает об устаревшей реализации.

2. Используем адаптер

LegacyPaymentService legacySvc = new();
IPaymentProcessor processor = 
 new PaymentAdapter(legacySvc);
processor.ProcessPayment(123.4567868m);

Результат:
- Приложение использует только IPaymentProcessor;
- Адаптер обрабатывает все преобразования;
- Устаревшая система полностью изолирована.

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

Источник: https://thecodeman.net/posts/simplifying-integration-with-adapter-pattern

День 2618. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 5

5. EXPLAIN ANALYZE (для всех SQL баз данных)
Что даёт: точное понимание, как БД выполняет запрос.
Тип: встроенная команда (для всех основных БД)
Зачем: показывает план выполнения запроса — как БД фактически обрабатывает SQL-запрос. Без этого оптимизация — это гадание.

Использование в разных базах данных:

-- PostgreSQL
EXPLAIN (ANALYZE, BUFFERS, VERBOSE) 
SELECT … FROM orders WHERE …;

-- MySQL
EXPLAIN ANALYZE
SELECT … FROM orders WHERE …;

-- SQL Server
SET STATISTICS TIME ON;
SET STATISTICS IO ON;
SELECT … FROM orders WHERE …;

Вывод (пример Postgres):

EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM orders 
WHERE customer_id = 12345 
  AND order_date >= '2024-01-01';

Seq Scan on orders  (cost=0.00..185234.25 rows=1 width=120) 
                    (actual time=0.045..2341.234 rows=247 loops=1)
  Filter: ((customer_id = 12345) AND (order_date >= '2024-01-01'::date))
  Rows Removed by Filter: 9847234
  Buffers: shared hit=47234 read=138000
Planning Time: 0.234 ms
Execution Time: 2341.567 ms

Что это значит:
- "Seq Scan" – полное сканирование таблицы (ПЛОХО – не используется индекс)
- "Rows Removed by Filter: 9847234" - Просканировано 9.8млн строк, возвращено 247
- "Execution Time: 2341ms" - 2.3 секунды

Решение – добавить индекс на поля customer_id и order_date:

CREATE INDEX idx_orders_customer_date ON orders(customer_id, order_date);

После:

Index Scan using idx_orders_customer_date on orders  
  (cost=0.43..8.45 rows=1 width=120) 
  (actual time=0.023..0.087 rows=247 loops=1)
  Index Cond: ((customer_id = 12345) AND (order_date >= '2024-01-01'::date))
  Buffers: shared hit=5
Planning Time: 0.123 ms
Execution Time: 0.112 ms

Что это значит:
- "Index Scan" – Используется индекс (ХОРОШО)
- "Buffers: shared hit=5" – только 5 блоков прочитано (против 185234 в предыдущем случае)
- "Execution Time: 0.112ms" – в 20000 раз быстрее

Основные шаги оптимизации запросов
1. Выполнить EXPLAIN ANALYZE
2. Обнаружить узкое место (seq scan, дорогой join или сортировку и т.п.)
3. Исправить (добавить индекс, переписать запрос, изменить порядок объединения)
4. Ещё раз выполнить EXPLAIN ANALYZE для проверки

Когда использовать
- Анализ любого медленного запроса;
- Перед написанием сложных запросов (прогноз производительности);
- После изменений схемы (проверка влияния);
- При добавлении индексов (обоснование использования).

Когда отказаться
Особых причин не использовать нет.

Скрытая функция
Сравнение планов запросов
1. Сохранить в файл

psql -c "EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT …" > plan_before.json

2. Сделать изменения
3. Сохранить новый план

psql -c "EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) SELECT …" > plan_after.json

4. Использовать утилиту визуализации плана:
- https://explain.dalibo.com/
- https://explain.depesz.com/
5. Использовать утилиту визуального сравнения (например, https://winmerge.org/)

С осторожностью
EXPLAIN с параметром ANALYZE на самом деле выполняет запрос.

-- Удалит данные!!!
EXPLAIN ANALYZE DELETE FROM orders WHERE …;

-- Безопасное тестирование
BEGIN;
 EXPLAIN ANALYZE DELETE FROM orders WHERE …;
 ROLLBACK;
END;

-- Либо без ANALYZE (только оценка)
EXPLAIN DELETE FROM orders WHERE …;

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

День 2617. #Шпаргалка
Виды Классов в C#
Сегодня рассмотрим различные виды классов в C# и как они работают.

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

public abstract class Vehicle
{
  public abstract int Wheels { get; }
  public abstract void TurnOn();
  public bool Started { get; protected set; }
}

Создать экземпляр класса Vehicle нельзя, поэтому унаследуем от него. При этом класс-наследник обязан переопределить абстрактные члены:

public class Car : Vehicle
{
  public override int Wheels => 4;
  public override void TurnOn()
   =>  Started = true;
}

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

public sealed class Vehicle
{
}

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

public static class SpeedConverter
{
  public static decimal ToMph(decimal kph)
   => return kph / 1.6093m;
}

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

public partial class Team
{
  public Team() { }
  public string Name { get; set; }
}

public partial class Team
{
  public int Players { get; set; }
}

Небезопасный
Небезопасный класс позволяет использовать код с указателями:

public unsafe class MemoryReader
{
  public void Read(int* value)
  {
    Console.WriteLine(*value);
  }
}

Если вам необходимо работать с указателями, нужно включить небезопасный код в файле .csproj, установив параметр AllowUnsafeBlocks в значение true.

Запись
Запись — ссылочный тип, предназначенный для данных, а не для поведения, и по умолчанию является неизменяемой:

public record class Team(string Name, int Players);

См. подробнее про записи.

Модификаторы доступа
- public – доступен отовсюду;
- internal – доступен внутри сборки;
- private – доступен только внутри включающего его типа;
- protected – доступен внутри включающего его типа и всех его наследников;
- file – доступен только внутри содержащего его файла исходного кода.

Источник: https://www.roundthecode.com/dotnet-tutorials/c-sharp-class-types-explained-examples

День 2616. #SQLServer
SQL Server Незаметно Переименовывает Пользователя
Автор оригинала: Bart Wullems

Учитывая кучу существующих ИИ-помощников, можно было бы ожидать, что мы больше не будем тратить время на глупые проблемы. К сожалению, до этого ещё далеко. Сегодня я потерял немало времени из-за поведения SQL Server, которое кажется очевидным, если вы об этом знаете, а если не знаете —ужасно раздражает.

У меня был скрипт, который должен был быть идемпотентным: создать пользователя БД, если его не существует, или обновить его, если существует. Стандартная процедура. Вот упрощённая версия:

USE [ONT_SampleDB];
GO
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'usr_DB_reader')
BEGIN
    ALTER USER [usr_DB_reader] WITH LOGIN = [lg_DB_dev_reader];
END
ELSE
BEGIN
    CREATE USER [usr_DB_reader] FOR LOGIN [lg_DB_dev_reader];
END
GO
ALTER ROLE [db_datareader] ADD MEMBER [usr_DB_reader];
GO

Выглядит нормально. Запустил один раз — работает. Запустил второй раз, и SQL Server выдаёт ошибку, что не может найти пользователя usr_DB_reader. Пользователя, которого мы только что создали. В той же базе данных. Этим же скриптом.

Что происходит на самом деле?
Когда вы запускаете ALTER USER […] WITH LOGIN = […], SQL Server переименовывает пользователя в соответствии с логином — по умолчанию, без предупреждений.

Таким образом, после первого запуска пользователя usr_DB_reader больше не существует. Он переименован в lg_DB_dev_reader, чтобы соответствовать логину. При втором запуске проверка IF EXISTS ищет usr_DB_reader, ничего не находит и переходит в ELSE — где CREATE USER завершается с ошибкой, потому что такой логин уже сопоставлен с пользователем c другим именем.

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

Решение
Явно укажите SQL Server сохранить имя пользователя как есть, добавив NAME = к оператору ALTER USER:

ALTER USER [usr_DB_reader]
    WITH NAME = [usr_DB_reader],
         LOGIN = [VLM\lg_DB_dev_reader];

Добавление WITH NAME = [usr_DB_reader] говорит SQL Server: да, измени логин, но не трогай имя пользователя. Теперь скрипт действительно идемпотентный.

Почему SQL Server так делает?
SQL Server различает логины (субъекты уровня сервера) и пользователей (субъекты уровня БД). Когда вы связываете пользователя с логином с помощью команды ALTER USER … WITH LOGIN, не указывая имя, SQL Server предполагает, что вы хотите синхронизировать их — поэтому он переименовывает пользователя в соответствии с логином. Это следует соглашениям, но это не то, чего вы ожидаете, если привыкли рассматривать имена пользователей как стабильные идентификаторы.

Источник: https://bartwullems.blogspot.com/2026/03/sql-server-silently-renames-your-user.html

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

28. Методы оценки
«Можете ли вы описать методы оценки, которые вы использовали в своих проектах, и объяснить, как они помогли вам обеспечить выполнение проектов в установленные сроки?»

Хороший ответ
В моём опыте управления проектами .NET я использовал комбинацию методов оценки для обеспечения точного прогнозирования и эффективного управления проектом. Среди них экспертная оценка (Expert Judgment), покер планирования (Planning Poker) и анализ точек использования (Case Point Analysis).

1. Экспертная оценка предполагает консультации с опытными членами команды для получения оценок на основе их прошлого опыта. Например, при работе над веб-сервисом, включающим ASP.NET Core и Entity Framework Core, я обсуждал задачи со старшими разработчиками, имеющими аналогичный опыт работы над проектами, чтобы получить реалистичное представление о трудозатратах и сроках.

2. Покер планирования - метод оценки в Agile, использующий консенсус для оценки задач. Каждый член команды предоставляет оценку, используя пронумерованные карточки, и затем следуют обсуждения, пока команда не достигнет консенсуса. Этот метод особенно полезен для вовлечения всей команды в процесс оценки, что повышает вовлечённость и точность оценок. Суть метода:
- Каждый разработчик получает карточки с номерами, представляющими собой стори-пойнты.
- Владелец продукта описывает функцию.
- Разработчики выбирают карточку, представляющую их оценку, не раскрывая её.
- Все карточки раскрываются одновременно, и разногласия обсуждаются до достижения консенсуса.

3. Анализ вариантов использования - адаптирован для оценки трудозатрат, необходимых для пользовательских историй, включающих взаимодействие с пользователями. Он учитывает сложность вариантов использования и корректирует её с учётом технических и организационных факторов.
Суть метода в том, что каждый вариант использования классифицируется как простой, средний или сложный, а затем присваивается вес на основе этих категорий. Это особенно эффективно для проектов с чёткими функциональными требованиями, таких как веб-сервис с несколькими конечными точками.

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

Часто встречающийся плохой ответ
«Я примерно по опыту оцениваю время, которое потребуется на написание кода и добавляю к нему некоторый процент на непредвиденные проблемы. Обычно этого достаточно.»

Почему это неправильно
- Чрезмерное упрощение: Этот подход чрезмерно упрощён и не учитывает детальные аспекты выполняемых задач. Оценка — это не просто завышение необходимого времени, а понимание сложности и связанных с этим рисков.

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

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

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

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

День 2514. #Карьера #Оффтоп
Миф о «Хорошем Программисте»
Новичкам кажется, что быть хорошим программистом означает быть быстрым. Быстро печатать. Быстро решать задачи. Быстро отвечать. Но по мере накопления опыта оказывается, что все громко кричат о скорости, но молчат о глубине понимания. А глубина понимания — редкость.

Где-то в ИТ мы перепутали производительность с пониманием. Если кто-то решает 300 задач на структуры данных и алгоритмы, мы называем его сильным программистом. Если кто-то знает пять языков, мы называем его талантливым. Если кто-то может мгновенно объяснить временную сложность, мы называем его умным.

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

Программирование перестаёт быть просто написанием строк кода. Оно становится проблемой ясности мышления. А ясность мышления — это сложно.

В интернете программирование выглядит как соревнование. Аккаунты на GitHub полные зелёных квадратиков. Люди хвастаются сериями успехов: «Решил 500 задач», «Освоил 8 языков». Но никто не пишет: «Я переделывал свою логику 6 раз, потому что она не масштабировалась». Никто не хвастается отладкой в течение четырёх часов подряд. Никто не радуется удалению 200 строк ненужного кода.

И всё же именно здесь происходит рост. Быть «хорошим программистом» — это не значит решать задачи быстрее всех. Это значит сохранять спокойствие, когда ничего не работает. Это значит разбивать большую, некрасивую проблему на более мелкие, понятные части. Это значит проектировать, прежде чем писать. Это значит понимать «почему» настолько глубоко, что даже если язык меняется, ваше мышление остаётся неизменным. Языки развиваются. Фреймворки меняются. Синтаксис обновляется. Ясное мышление остаётся.

То, чем по-настоящему стоит гордиться
Создание чего-то с нуля, что действительно работает. Не идеально. Не красиво. Но логично. А затем улучшение этого. Снова. И снова. И снова. Возможно, вопрос был задан неправильно. Не: «Хорошо ли я разбираюсь в программировании?», а: «Могу ли я создавать? Могу ли я мыслить? Могу ли я упорствовать, когда всё идёт наперекосяк?»

Потому что программирование — это не представление. Это архитектура мышления. А для этого требуется не только скорость. Требуется терпение.

Источник: https://medium.com/@shriya73spark2008/the-myth-of-being-good-at-coding-a9d15cbd689c

День 2613. #Testing
TUnit – Новый Фреймворк Тестирования в .NET. Окончание
Начало
Особенности 1-3
Особенности 4-5

6. Нативный Fluent API
TUnit поддерживает цепочку fluent утверждений «из коробки», без необходимости установки каких-либо дополнительных пакетов или настройки.

[Test]
public async Task FluentAssertions()
{
  var user = new { Name = "Alice", 
   Age = 30, Email = "alice@example.com" };
    
  // Цепочка утверждений 
  await Assert.That(user.Name)
    .IsNotNull()
    .IsNotEmpty()
    .StartsWith("Al");
    
  // 'And' для логической группировки 
  await Assert.That(user.Age)
    .IsGreaterThan(18)
    .And.IsLessThan(65);
    
  // Несколько утверждений в области
  // (сообщение сразу о всех неудачах, а не о первой)
  using var scope = Assert.Multiple();
  await Assert.That(user.Name).IsEqualTo("Alice");
  await Assert.That(user.Age).IsEqualTo(30);
  await Assert.That(user.Email).IsNotNull();
}

7. Нативная поддержка внедрения зависимостей
Для использования внедрения зависимостей не требуется сложная настройка, TUnit поддерживает его «из коробки».

[Test]
public async Task WithDependencyInjection(
 IUserService userService, ILogger logger)
{
  var user = await userService.GetUserAsync(1);
  logger.LogInformation($"Loaded user: {user.Name}");
    
  await Assert.That(user).IsNotNull();
}

// Конфигурация через ServiceCollection
public void ConfigureServices(
 IServiceCollection services)
{
  services.AddScoped<IUserService, UserService>();
  services.AddLogging();
}

Итого
Использовать ли TUnit?
TUnit - шаг вперёд в тестировании .NET. Существующие фреймворки остаются надёжными, стабильными и зрелыми, но они отражают проектные решения, принятые задолго до AOT, генераторов кода или современных ожиданий производительности.

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

Источник: https://trailheadtechnology.com/tunit-the-new-sheriff-in-town-for-net-testing/

День 2612. #Testing
TUnit – Новый Фреймворк Тестирования в .NET. Продолжение
Начало
Особенности 1-3

4. Передача данных в тесты
1) Аргументы уровня компиляции

[Test]
[Arguments(1, 2, 3)]
[Arguments(4, 5, 9)]
public async Task Addition(
 int a, int b, int expected)
{
  await Assert.That(a + b).IsEqualTo(expected);
}

2) Метод-источник (динамические данные)

[Test]
[MethodDataSource(nameof(TestCases))]
public async Task WithDynamicData(
 int value, string expected)
{
  var result = ProcessValue(value);
  await Assert.That(result).IsEqualTo(expected);
}

public static 
 IEnumerable<(int, string)> TestCases()
{
  yield return (1, "one");
  yield return (2, "two");
  yield return (3, "three");
}

3) Матричные тесты (комбинаторные)

[Test]
public async Task MatrixCombinations(
 [Matrix(1, 2, 3)] int x,
 [Matrix("a", "b")] string y,
 [Matrix(true, false)] bool z)
{
  // 3 × 2 × 2 = 12 комбинаций
  await Assert.That(Validate(x, y, z)).IsTrue();
}

4) Класс-источник

[ClassDataSource<UserFixture>(Shared = SharedType.PerClass)]
public class UserServiceTests
{
  [Test]
  public async Task CreateUser(UserFixture fixture)
  {
    var user = await 
     fixture.Service.CreateAsync("John");
    await Assert.That(user.Name).IsEqualTo("John");
  }
}

public class UserFixture
{
  public IUserService Service { get; } 
   = new UserService();
}

Как видите, TUnit поддерживает практически все функции, предлагаемые существующими фреймворками, часто усовершенствованные и модернизированные.

5. Жизненный цикл тестов и фикстур

public class TestLifecycleExample
{
  private DatabaseConnection _conn;
    
  // Перед каждым тестом
  [Before(Test)]
  public async Task SetupTest()
  {
    _conn = new DatabaseConnection();
    await _conn.OpenAsync();
  }
    
  [Test]
  public async Task DatabaseQuery()
  {
    var result = 
     await _conn.QueryAsync("SELECT * FROM Users");
    await Assert.That(result).IsNotNull();
  }
    
  // После каждого теста
  [After(Test)]
  public async Task CleanupTest()
  {
    await _conn.CloseAsync();
    _conn?.Dispose();
  }
    
  // Однажды на тестовый класс
  [Before(Class)]
  public static async Task SetupClass()
  {
    // Инициализация общих ресурсов 
  }
    
  [After(Class)]
  public static async Task CleanupClass()
  {
    // Очистка общих ресурсов 
  }
    
  // Однажды на сборку 
  [Before(Assembly)]
  public static async Task SetupAssembly()
  {
    // Инициализация данных уровня приложения 
  }
}

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

Источник: https://trailheadtechnology.com/tunit-the-new-sheriff-in-town-for-net-testing/

День 2611. #Testing
TUnit – Новый Фреймворк Тестирования в .NET. Продолжение
Начало

Ключевые особенности TUnit

1. Нативная поддержка асинхронности
Утверждения ожидаются, обработчики инициализации асинхронны, и весь жизненный цикл теста учитывает, что современная .NET является асинхронной платформой.
xUnit:

[Fact]
public async Task TestAsync()
{
  var result = await GetDataAsync();
  Assert.Equal(5, result.Items.Count); 
}

TUnit:

[Test]
public async Task TestAsync()
{
  var result = await GetDataAsync();
  await Assert.That(result.Items)
   .Count()
   .IsEqualTo(5);
}

Каждое утверждение ожидается. Это позволяет TUnit:
- Точно захватывать асинхронный контекст,
- Связывать утверждения с fluent-синтаксисом,
- Обрабатывать асинхронные утверждения без специального или пользовательского синтаксиса,
- Предоставлять более понятные и информативные сообщения об ошибках с полным контекстом выполнения.

2. Генерация кода и проверка во время компиляции
TUnit использует генераторы кода C# для обнаружения и компиляции тестов во время сборки, полностью исключая необходимость рефлексии во время выполнения. Такой подход позволяет выявлять многие ошибки во время компиляции, а не во время выполнения, и значительно сокращает время запуска тестов. Это также улучшает общее качество отладки, поскольку сгенерированный код обеспечивает более понятные пути выполнения и более предсказуемое поведение по сравнению с традиционными фреймворками, основанными на рефлексии.

[Test]
[Arguments(1, 2, 3)]
[Arguments(4, 5, 9)]
public async Task Add_WithVariousInputs(
 int a, int b, int expected)
{
  var result = Add(a, b);
  await Assert.That(result).IsEqualTo(expected);
}

// Упрощённый сгенерированный код:
// [CompilerGenerated]
// public async Task Add_WithVariousInputs_1()
// {
//   var result = Add(1, 2);
//   await Assert.That(result).IsEqualTo(3);
// }
// [CompilerGenerated]
// public async Task Add_WithVariousInputs_2() { … }

3. Модель параллелизации

// Тесты по умолчанию распараллеливаются 
[Test]
[Parallel] // Явно распараллелить 
public async Task Test1() { }

// Последовательное выполнение при необходимости
[Test]
[Sequential]
public async Task Test2() { }

// Общие ресурсы для параллельных тестов [ClassDataSource<DatabaseFixture>(Shared = SharedType.PerClass)]
public class DatabaseTests
{
  [Test]
  public async Task Test1(DatabaseFixture db) { }
    
  [Test]
  public async Task Test2(DatabaseFixture db) { }
}

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

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

Источник: https://trailheadtechnology.com/tunit-the-new-sheriff-in-town-for-net-testing/

День 2610. #Testing
TUnit – Новый Фреймворк Тестирования в .NET. Начало
xUnit, NUnit и MSTest многие годы хорошо служили командам для модульного, интеграционного и даже приёмочного тестирования. Однако по мере развития .NET с появлением новых версий среды выполнения, AOT-компиляции, требований кроссплатформенности, всё более крупных наборов тестов и более быстрых конвейеров CI/CD ограничения устаревших фреймворков стали более очевидными. TUnit стремится решить многие из этих проблем, или, по крайней мере, заявляет об этом. В этой серии рассмотрим, что может предложить TUnit.

Проблема существующих фреймворков
1. Накладные расходы на рефлексию
xUnit, NUnit и MSTest в значительной степени полагаются на рефлексию для обнаружения тестов, создания экземпляров фикстур и вызова методов тестирования. В больших наборах тестов накладные расходы на рефлексию могут значительно влиять на время выполнения.
Обнаружение тестов на основе рефлексии происходит во время выполнения, заставляя разработчиков ждать, прежде чем тесты начнут выполняться. Это особенно раздражает в конвейерах CI/CD.

2. Асинхронный подход был второстепенным
async/await был добавлен в существующие фреймворки тестирования. В результате иногда получаются неуклюжие утверждения, непоследовательная обработка асинхронных операций и не всегда понятный код.

3. Отсутствие поддержки AOT
Поддержка AOT становится необходимой для облачных приложений и контейнеризированных рабочих нагрузок. Интенсивное использование рефлексии в устаревших фреймворках затрудняет или делает невозможной поддержку AOT.

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

Заявления TUnit
Философия проектирования TUnit основана на скорости, современности, гибкости, простоте и лёгкости внедрения.

Ключевые концепции:
1. Производительность прежде всего — использование генерации кода во время компиляции вместо рефлексии, с параллельным выполнением тестов, включённым по умолчанию.
2. Совместимость с современным .NET — полная поддержка .NET 8 и более поздних версий, нативный AOT, тримминг и новые возможности среды выполнения.
3. Управление и гибкость — рабочие процессы на основе атрибутов и конфигурации, пользовательские источники данных, расширяемое поведение, цепочки зависимостей и тонкое управление планированием.
4. Широкая применимость — подходит не только для модульных тестов, но и для интеграционных, приёмочных и даже сквозных сценариев (включая поддержку таких библиотек, как Playwright).
5. Прочие отличительные особенности — асинхронные утверждения, Fluent API, различные источники данных (аргументы, методы, классы, матрицы), диагностика во время компиляции, скорость выполнения на 30% выше xUnit.

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

Далее подробнее рассмотрим функции, которые предлагает TUnit.

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

Источник: https://trailheadtechnology.com/tunit-the-new-sheriff-in-town-for-net-testing/