Маленький отдел в рабочем ящике с инструментами

Когда-то давненько я писал про используемое мною программное обеспечение для работы. Сейчас хочется немного развить тему, но в другом направлении. Хочется упомянуть используемые в работе библиотеки и в двух словах объяснить - почему они мне нравятся, и для чего я продвигаю их использование в текущих проектах. Сразу хочется оговориться – данное мнение актуально здесь и сейчас. Это не значит, что я переобуваюсь в прыжке – просто некоторые библиотеки крайне сильно отличаются от версии к версии.

Начну с любимого – automapper. Про него уже писал как-то и сейчас только повторюсь. Кажется, что он выполняет предельно тупую задачу, которую можно быстро реализовать самому. Да, это так. Преобразовать один объект в другой – задача предельно простая. Конечно, можно его реализовать самому. Писать те же самые профили маппинга и получить на выходе туже самую логику. Т.е. реализовать то, что УЖЕ РЕАЛИЗОВАНО. И покрыто тестами. Следовательно, используя эту библиотеку – вам необходимо будет тестировать не сам маппинг, а только профили маппинга. Из недостатков – для сложного проекта с большим количеством моделей и маппингов, крайне быстро увеличится количество профилей и возникнет желание зарефакторить эти портянки в более лаконичные конструкции. Но эта проблема уже решена на хабре.

Из свежевнедрённого хочется упомянуть - Serilog . Я писал - как по тупому можно забить дисковое пространство логами и в итоге для новых проектов мы перешли на связку Serilog + Seq. В своих проектах мы используем концепцию лога, который имеет краткое описание, полное описание, категорию ну и классику вроде идентификатора пользователя и время события и т.д.. Serilog на эту концепцию не ложится вообще никак – так как проповедует концепцию структурных логов. На практике – наша концепция оборачивается частичным задвоением сути события в кратком и полном описании, или, наоборот - в излишней подробности. Т.е. если такие события логировать синхронно в БД – это с гарантией займет время и место. Serilog + Seq дает возможность использовать NoSql БД, но быстрого перехода и моментальной оптимизации для старых проектов мы не получим точно.

Последнее что хочется упомянуть – больная тема. Библиотека для unit-тестирования xUnit. Разумеется, если вы не пишете тесты – то всем спасибо за внимание и приходите еще. Ну а если все же тратите свое драгоценное на время на сей бесполезный процесс – поделюсь своей болью. Ранее для тестов я применял NUnit. Претензий к ней у меня по большому счету нет – с радостью продолжу использование на старых проектах. А уж предположения «Assert.That» это на мой взгляд одна из самых лаконичных и легко читаемых инструкций. Так почему же xUnit? Меня достало писать атрибуты NUnit. Да, можно завести базовые классы, в которых описать что все наследники будут unit-тестами. Но это не работает для атрибутов SetUp и TearDown. Да, я знаю что можно их объявить виртуальными и постоянно переопределять, но в xUnit для этих целей используются базовые конструкции языка и платформы – конструктор класса и интерфейс IDisposable. Плюс надо еще постоянно помнить что в базовом классе есть метод SetUp или как вы его назовете и что его вообще можно переопределить. В противном случае человек просто заведет еще один метод SetUp. Плюс – метод Assert.Equal реализован как Generic и выполняет глубокое сравнение объектов что экономит тонну строк кода. Может быть свежие версии NUnit так же умеют, но я их не знаю когда испытаю на себе. Кстати, вот еще статейка, описывающая как тестировать свой код сравнивания что-то кроме как 1,2,4,42 и TestName.

Хватит наверное. Если внезапно под этим постом появится вопрос по этим библиотекам – постараюсь ответить. Хотя по факту – это просто попытка оформить свои мысли и боль в словесной форме. Лично я сторонник мнения, что если я в двух словах не могу объяснить почему я использую тот или иной программный продукт – значит я не имею понятия зачем я его применяю.