Создатель Node.js Ryan Dahl впервые в Украине на конференции JS Fest. Программа уже на сайте
×Закрыть

.NET дайджест #25: .NET Standard 2.1, подход к распределенным системам, как выбирать границы микросервисов

В выпуске: о внутренностях разработки Rider, как писать Unit-тесты так, чтобы они не ломались при рефакторинге, обзорное видео о сагах.

.NET

ASP.NET Core 2.2.0-preview1: HTTP/2 in Kestrel
Server Push, к сожалению, пока не поддерживается, и команда все еще решает, включать ли его в эту версию.

.NET Standard 2.1
Документ объясняет, почему были принято такое решение версионирования и какие API будут включены. Основная идея — включить Span<T> в стандарт.

Announcing .NET Standard 2.1


Diagnosing .NET Core ThreadPool Starvation with PerfView

Architecture

Event Store scavenging and the hidden cost of link events

Modeling Uncertainty with Reactive DDD
Хорошая статья о подходе к распределенным системам. Я как-то давал ссылку на запись доклада, тут это оформлено в виде статьи. Стоит ознакомиться тем, кто работает с распределенными системами.

Distributed Data Management
Amazon Kinesis Streams как вариант Single Source of Truth системы (подобие Event Sourcing).

Microservices & Distributed Monoliths

Managing data consistency in a microservice architecture using Sagas
Хорошее обзорное видео о сагах и о том, как они помогают решать проблему распределенных транзакций.

Not Just Events: Developing Asynchronous Microservices
Отличный Keynote c конференции, которая проходила вот только в этот понедельник.

Microservices, Bounded Contexts, and Everything in Between
Отличный доклад оттуда же о том, как выбирать границы микросервисов. Там еще были интересные выступления, так что рекомендую посмотреть, может что-то еще будет актуально.

Practices

TDD, Where Did It All Go Wrong
Отличное видео о том, что на самом деле такое Unit-тесты и как писать тесты так, чтобы они не ломались при рефакторинге.

Tools

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

Building a .NET IDE with JetBrains Rider
Интересная статья о внутренностях разработки Rider.

A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)

The software engineer’s guide to asserting dominance in the workplace
Детальное расписание на неделю с инструкциями, как занять доминантное положение в новой компании на уровне с «On your first day at the new job, squash every commit from the repo into a single commit with message „Legacy code“ and force-push to master».

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

P. P. S. Кстати, 7-го декабря буду выступать с докладом на XP Days, приходите послушать про Event-Driven Systems Backed By MongoDB. Если хотите пойти, но нет возможности купить билет за полную стоимость — напишите мне, у меня, как у докладчика, есть возможность получить два промокода на хорошую скидку.


← Предыдущий выпуск: .NET Дайджест #24
Следующий выпуск: .NET Дайджест #26

LinkedIn

2 комментария

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

У него скорее всего речь о тестах в целом. С трудом представляю что бы он рассказывал о юнит тестах аппелируя к bdd и сценариям из user stories. Есть здравые мысли, местами не очень — подача у докладчика сильно неконкретна и через призму своего восприятия вещей, что бы применить это правильно на практике. Unit test нужны что бы тестировать не юниты, requirements — а что бы проверять алгоритмику и логику, моки как правильно там вообще не создают проблему — их там просто не должно быть, поскольку в таком коде не должно быть сайд эффектов. Как правило, процент кода для покрытия юнит тестами на проекте среднестатистического дотнетчика колеблится от 10-40%, чаще цифра 10-20% все остальное надо проверять интеграционными и End-to-End тестами. Тесты дорогие совсем по другим причинам — плохо написанные тесты с множеством test smells, о которых на моем опыте большинстве девелоперов даже не знают и знать не хотят.
Что бы получать реальную пользу от тестирования и минимизировать расходы на maintenance лучше все-таки читать оригинальную литературу,где все это разложено по полочкам было уже и 10-15 лет назад того же — Кента, Месзароса, Фаулера.

Я тоже для себя отметил, что с некоторыми вещами не согласен, поэтому стоит критично подходить к мнению, конечно. Тем не менее для меня там было несколько ключевых моментов, которые заставили посмотреть по-другому на некоторые вещи и заполнили некоторые пробелы. Ведь, многие сегодня пишут юнит-тесты сервисов (например, CommandHandler), которые, в свою очередь, вызывают другие сервисы (например, Repository). И эти вызовы мокаются. Получается, что тест знает много о внутренностях этого CommandHandler и при малейшем изменении логики тесты будут падать. Для меня Key Takeaway было именно это. Что юнитом как раз является логика такого публичного интерфейса (команда, как раз, часть публичного интерфейса и логика ее обработки — юнит). И BDD тоже хорошо ложится на это. А вот executable specifications, по факту, бизнесу не интересны, хотя мне идея очень нравится.

Очень сложно было согласиться с тем, что некоторые детальные низкоуровневые тесты стоит просто удалять после написания логики. Но Booking.com так делает и, похоже, для них это работает.

Подписаться на комментарии