В логах с прода всегда бесило, что нет никакой возможности посмотреть номер строки, в котором произошла ошибка.

Но кажется в С# 10 есть инструмент, который поможет хотя бы частично решить эту проблему

Новый атрибут времени компиляции [CallerArgumentExpression]

Кратко про суть:

Есть у вас есть такой код:
var array = Array.Empty<int>();

вы хотите проверить его на пустоту:

public static void ItIsNotEmpty<T>(
IEnumerable<T> value,
[CallerArgumentExpression("value")] string message = "")
{
if (!value.Any())
{
throw new ArgumentException("Sequence is empty", message);
}
}

И вызываете вашу функцию вот так:

EnsureThat.ItIsNotEmpty(array);

Вот как будет выглядеть ошибка, которую выкинет этот код:

System.ArgumentException: Sequence is empty (Parameter 'array')

Обратите внимание на то что находится в скобочках. Мы видим там не название параметра,а имя той переменной, что мы передали в скобочки. ТО ЕСТЬ если мы вызовем метод вот так:

EnsureThat.ItIsNotEmpty(Array.Empty<int>());

То ошибка станет вот такой:
System.ArgumentException: Sequence is empty (Parameter 'Array.Empty<int>()')

То есть залогирует строку с проблемой, а не просто название параметра!

Недавно узнал о полезной фиче в библиотеке Moq. Называется MockRepository. Да, я знаю, что наверное уже почти все о ней слышали, но я вот узнал недавно и делюсь для таких же как я.

В чем суть фичи. Положим у вас есть сервис вот с такими зависимостями:
public NotificationService(
IUsersRepository usersRepository,
ISubnoscriptionsService subnoscriptionsService,
IDataBaseService dataBaseService,
IBusSystem busSystem)

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

Mock<IUsersRepository> usersRepositoryMock = new Mock<IUsersRepository>();
Mock<ISubnoscriptionsService> subnoscriptionsServiceMock = new Mock<ISubnoscriptionsService>();
Mock<IDataBaseService> dataBaseServiceMock = new Mock<IDataBaseService>();
Mock<IBusSystem> busSystemMock = new Mock<IBusSystem>();

NotificationService sut = new NotificationService(
usersRepositoryMock.Object,
subnoscriptionsServiceMock.Object,
dataBaseServiceMock.Object,
busSystemMock.Object);

Я жесть как не люблю вот эту часть с объявлением моков, особенно, если учесть, что все из них нужно настраивать. А мне не всегда нужно настраивать их все.

Так вот MockRepository решает эту проблему так:
MockRepository mockRepository = new MockRepository(MockBehavior.Loose);
NotificationService sut = new NotificationService(
mockRepository.Create<IUsersRepository>().Object,
mockRepository.Create<ISubnoscriptionsService>().Object,
mockRepository.Create<IDataBaseService>().Object,
mockRepository.Create<IBusSystem>().Object);

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

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

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

MockRepository mockRepository = new MockRepository(MockBehavior.Loose);
NotificationService sut = new NotificationService(
mockRepository.Create<IUsersRepository>(MockBehavior.Strict).Object,
mockRepository.Create<ISubnoscriptionsService>().Object,
mockRepository.Create<IDataBaseService>().Object,
mockRepository.Create<IBusSystem>().Object);

sut.Notify();

mockRepository.VerifyAll();
mockRepository.VerifyNoOtherCalls();

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

Вот такая вот топовая фича для тестирования!

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

Напишу короткую преамбулу и сразу к делу. В общем, я в последнее время заметил, что у меня в голове сформировался список крутых технологий, которые говорят о том, что компания по уровню технического развития находится в пантеоне богов. Ну то есть, работать в такой компании, это все равно что лететь в бескрайний косомос на корабле Энтерпрайз – все время открываешь новые фронтиры. Решил его озвучить тут, чтобы вам было понятно, работаете ли вы на Энтерпрайзе или на Эвергивене)

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

Load Testing. Тут все просто, если в компании есть нагрузочное тестирование, значит у комапнии есть хайлоад. Где есть хайлоад, там есть новые вызовы. Раньше нагрузочное тестирование было уделом спецаильно обученных людей. Сегодня с помощью k6 к нему сожет приобщиться в рамках самообучения любой разработчик

Feature Toggles. Это также скорее подход, но за нима порой стоят вполне конкретные технологии. Самый топовый уровень здесь, это когда вы можете протестировать фичу прямо на своей дебажной сборке. Ну или раскатить фичу на 10% пользователей, чтобы провести A/B тест. Наверное вас триггернуло про дебаг на проде. Наверное вы подумали, что это же "Хуяк хуяк и в продакшен!" ОЙ как плохо и все такое. Но следующая технология позволяет так делать

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

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

Почему вам следует перестать ругать чужой код?
Когда я только начал свой путь в разработке, практически сразу заметил, что тут принято ругать решения своих коллег. Мой тимлид открыл солюшен и практически сразу наткнулся на какой-то лютый дженерик, после чего сказал "Пиздец, что это?!" Эту фразу в различных вариациях я слышу практически каждый раз, когда сажусь с кем-то писать код. Да ее уже можно сделать звуком по умолчанию при открытии файла в любой IDE, чтобы людям уже не приходилось переутруждать себя!

Часто в программистских чатах так или иначе всплывают мемы типа такого: "Когда увидел код, который ты написал год назад." Эти мемасы из года в год собирают кучу лайков.

И это плохо, потому что именно поэтому вы перестаете развиваться.

Год назад я заметил, что мне стало тяжело писать код. Каждая строчка, каждое название переменной и метода дается с огромным трудом. Заношу руку над клавиатурой, а в голове слышу: "пиздец, что это? Ты вообще знал, что это может привести к дедлоку? Ты знаешь как выглядит дедлок?"

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

Почему вам следует перестать ругать чужой код? Часть 2
В итоге "голос качества" стал усиливаться и в конечном итоге дошло до того, что я даже в тестовых проектах начал думать над каждой строчкой.

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

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

И есть только один способ разорвать этот порочный круг – перестать ругать чужой код.

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

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

Теперь после собеса вы сможете достоверно проверить ответ на вопрос "Во что разворачивается foreach"

Воу воу воу! Я очень давно хотел найти программу, которая показала бы результат AOT компиляции. Так как на собесах часто спрашивают тупые вопросы типа "Во что разворачивается (введите название любой херни)"

И наконец я узнал о такой охренительной штуке, как sharplab.io Это онлайн-компилятор, который... позволяет сделать то что я и хотел – посмотреть результат AOT компиляции!

Теперь после собеса вы сможете достоверно проверить ответ на вопрос "Во что разворачивается foreach".

Надеялся, что есть еще какой-нибудь плагин для райдера или для VS Code, но такого нет. Но самое главное, что приложуха опенсорсная, так что любой может написать плагин если захочет. https://github.com/ashmind/SharpLab
#инструменты

Понемногу старамеся подступиться к хаос тестингу в компании и в прошедшую пятницу попробовали Simmy: https://github.com/Polly-Contrib/Simmy

Это библиотечка от создателей Polly, которая создает рандомные падения в вашем приложении. Стратегии падения разные и совместимы со стратегиями из Polly. То есть если вы хотите, чтобы ваше приложение выкидывало сообщение об ошибке каждые 5 секунд со все возрастающей частотой, то вы можете сделать это с помощью Simmy.

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

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

Возможно создатели Simmy тоже это поняли, потому что библиотека не развивается уже больше года. А может Simmy уже идеален?🙂

Своя консольная тулза за 5 шагов

Открыл одну крутую тему! Вы знали как делать консольные тулзы на C#? Я вот не знал, а это оказывается охрененно просто:

1) Создаем консолькую приложуху (в моем случае она просто выводит мне мое имя и текущую дату)
2) В .csproj добавляем
<PackAsTool>true</PackAsTool>
<ToolCommandName>myname</ToolCommandName>
<PackageOutputPath>./nupkg</PackageOutputPath>
3) Делаем dotnet pack
4) Переходим в папку с собранным пакетом cd MyName.Cli
5) Запускаем установку dotnet tool install --global --add-source ./nupkg myname.cli

Все готово!

Можно вызывать myname в консоли!

Для macOS нужно будет еще выполнить пару действий, которые появятся в консоли после 4-го шага.

Для продвинутых: это знание полезно не только, чтобы делать консольные приколюхи для себя, но и для кастомных шагов в Github Actions.

Экономия до 40% на сериализации. Не кликбейт

Когда в .net 5 вышли Source Generators я честно был восхищен, но был нюанс 🙂 Типа, круто, что мы теперь в компилятор что-то подпихнуть можем, но нахера?))) Так вот, .net 6 так сказать прояснил ситуацию для тупых, добавив фичу JsonSerializerContext.

Поговаривают, с ее использованием можно поднять производительность json-сериализации до 40%. Сильно ли нужно заморочиться, чтобы вкрутить у себя? Я и сам в шоке, но оказывается – нет!

Есть у вас класс Person, который вы хотите передать по Интернетам:

public class Person
{
   public string FirstName { get; set; } = default!;
   public string SecondName { get; set; } = default! ;
}

И раньше вы делали так:

var person = new Person
{
    FirstName = "Mr",
    SecondName = "Anderson"
};

var personText = JsonSerializer.Serialize(person);

А потом передавали уже в виде байтиков сериализованную персону.

Что нужно сделать, чтобы ускорить эту строку на 40%? Создать вот такой partial класс:

[JsonSerializable(typeof(Person))]
public partial class PersonJsonContext: JsonSerializerContext
{
}

И в строчке прописать один параметр PersonJsonContext.Default.Person:

var personText = JsonSerializer.Serialize(person, PersonJsonContext.Default.Person);

Один параметр, Карл! Ради сорока процентов производительности! Мне кажется, что это стоит того напряжения, учитывая, сколько сериализаций содержит твое web-приложение!

Начни бенчмаркать уже сегодня!
У вас есть уникальная возможность обвинить меня в пиздобольстве!

Постом выше я писал, что вы можете сэкономить до 40% на сериализации. И кажется, что под таким постом нужны пруфы, Билли! Нам нужны пруфы!

Так вот, получите пруфы сами! Для этого вам просто нужно поставить темплейт проекта с Benchmark .NET

dotnet new -i BenchmarkDotNet.Templates

Создать проект по темплейту и в классе Benchmark.cs в методе Scenario1 вызовите старый метод, а в Scenario2 новый.

Никогда еще бенчмаркать не было так легко, как с темплейтами для бенчмарка! С этими темплейтами бенчмаркать может даже моя бабуля!

Забудьте о классах, у нас есть records! :⚒
Главное, что подкупает в рекордах это возможность сделать так:

var neoPerson = person with { FullName = "Neo" };

✅ Чем это круто? Тем, что neoPerson будет совершенно новым объектом, со своей ссылкой, но с одним измененным свойством. Но самое главное – это вообще единственный способ поменять что-то в рекорде. Это дает простой способ сделать класс (а рекорды под капотом это обычные классы) иммутабельным.

🕔 Раньше, если вы хотели добиться от класса подобной иммутабельности, то вы бы поели говна из копипасты. Типа:

var personClass = new PersonClass("Laurence Fishburne", new DateOnly(0,1,1));

var morpheusPersonClass = new PersonClass("Morpheus", personClass.DateOfBirth);

И, чем больше полей, тем больше копипасты. Либо пришлось бы придумывать какие-то методы, которые бы по-умному клонировали объект. В общем дело было швах, а теперь иммутабельность можно нести в массы!

🛡Как это применить в проде?
Если у вас есть вот такой класс, к примеру

public class PersonClass
{
   public PersonClass(string fullName, DateOnly dateOfBirth)
   {
       FullName = fullName;
       DateOfBirth = dateOfBirth;
   }

   public string FullName { get; }
   public DateOnly DateOfBirth { get; }
}

Можете смело заменить его на

public record Person(string FullName, DateOnly DateOfBirth);

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

Попробуй сейчас и используй вечно!
💻 Попробуйте скопировать себе в Program.cs вот эти три строки (разумеется с включенным С# 10):

var neo = new Person("Mr Anderson", new DateOnly(1980, 2, 1));
Console.WriteLine(neo);
public record Person(string FullName, DateOnly DateOfBirth);

🧐 Сейчас будет вопрос, как на собесах: что же выведется в консоли?

Если бы это был просто поганый класс, то вывелось бы тупое и бесполезное:
Person

Но что вышло у нас? Правильно!
Person { FullName = Mr Anderson, DateOfBirth = 02/01/1980 }

✅ Супер-полезное описание со значением всех полей! Почему так? Потому что рекорды за вас грамотно определяют метод ToString() так чтобы он выводил полезную информацию, а не просто тупое имя типа.


🤩Пользуйся рЕкордами! Пользуйся рЕкордами мазафака!🤩