Исследуем new() ограничение в C#

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

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

Ну а теперь, к теме сегодняшней публикации.

Я уже несколько раз затрагивал вопрос реализации одной довольно простой возможности языка C# - ограничения обобщений new(), что она, дескать, реализована через Activator.CreateInstance (да и то, не всегда;), подробности – в оригинале!).

Проблем у этого аспекта аж две (что и делает new() ограничение выдающейся дырявой абстракцией): низкая производительность и хитрость с обработкой исключений.

Так вот, у нас на проекте, активное использование new T() весьма быстро вылезло в профилировщике, было починено с весьма заметным приростом end-to-end времени исполнения. Там мы прикрутили простое решение на основе деревьев выражения и про это забыли.

А не так давно на ru.stackoverflow.com был задан вопрос по поводу кодогенерации и примеров ее применения, что дало дополнительную почву для размышлений на эту же тему. В результате были перекопаны следующие вещи, чтобы добиться эффективности кастомного активатора равных вызову делегата вида () => new CustomNode():

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

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

Понятное дело, что подробности – по ссылке: Dissecting the new() constraint in C#: a perfect example of a leaky abstraction.

З.Ы. Я надеюсь, что читать такое введение интереснее, чем просто увидеть ссылку.

З.Ы.Ы. Пожелания, предложения и все такое, всячески приветствуется.

Ретроспектива 2016

Ёлки выброшены (нет, моя – в гараже!), и трудовые выходные перешли в не менее трудовые будни нового года, а значит пришло время подвести итоги года прошедшего. Пусть и с опозданием.

Как известно, 2016-й был непростым годом (четный год таковым быть не может) и по блогу это заметно. За прошлый год можно было заметить следующие тренды: я начал заниматься ErrorProne.NET (правда потом забил), в начале года я допилил Code Contracts и с тех пор только принимал пул рекветы (все еще не знаю, что делать с поддержкой VS 2017), начал блог на английском, ну и написал полтора-два десятка статей на разные темы.

Теперь об этом и другом, более подробно (с)J

Реализация синглтонов в .NET: Field-like vs. Lazy

Недавно один из читателей задал вопрос по поводу разницы между двумя реализациями синглтонов: через обычное статическое поле или же через статическое поле, содержащее Lazy<T>:

public class FieldLikeSingleton
{
    // Вариант C# 6
    public static FieldLikeSingleton Instance { get; } = new FieldLikeSingleton();
 
    private FieldLikeSingleton() {}
}
 
public class FieldLikeLazySingleton
{
    private static readonly Lazy<FieldLikeLazySingleton> _instance = 
        new Lazy<FieldLikeLazySingleton>(() => new FieldLikeLazySingleton());
 
    public static FieldLikeLazySingleton Instance => _instance.Value;
 
    private FieldLikeLazySingleton() {}
}

Для простоты, первую реализацию я буду называть field-like реализацией (*), а вторую – ленивой.

 

Горизонтальные и вертикальные слои приложения

«У лука есть слои, и у людоедов есть слои! Ты понял?» - Шрек

Эта заметка навеяна выступлением Jimmy Bogard на 0redev под названием “Solid Architecture in Slices not Layers”, которую я всячески рекомендую.

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

Conway’s Law

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

Такой разделение еще сильнее выстраивает барьеры между слоями приложения, поскольку тут начинает во всей красе проявляться Conway’s Law, когда архитектура приложения начинает повторять структуру организации.

Памятка ынтырпрайз кодера

После прочтения “Release It!” захотелось сохранить ряд мыслей по поводу разработки распределенного ынтырпрайз софта. То, о чем нужно думать, что нужно подпилить, о чем нужно не забыть и т.п.

1. Все что может отвалиться, обязательно отвалится

База ляжет, удаленный веб-сервис начнет тупить, перестанет проходить автортизация, ажура начнет отбивать запросы (throttling). Это значит, что любое взаимодействие с внешними системами должно это учитывать. К сожалению, это легче сказать, чем сделать, поскольку современные библиотеки для распределенного взаимодействия слоены до нельзя и с точки зрения API не вполне очевидно, что именно может пойти не так, какие исключения могут вылететь, и что с ними нужно будет делать.

Менторинг и парное программирование

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

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

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

Теперь давайте об этом более подробно.

О парном программировании

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

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

Итак, начнем с проблем.