Рефлексия

Деревья выражений System.Linq.Expressions дают возможность выразить намерения не только самим кодом, но и его структурой, синтаксисом.

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

Run-time компиляция порождает производительные делегаты, которые часто быстрее тех, что компилируются во время сборки (за счет меньшего оверхеда). Однако сама компиляция происходит до десятков тысяч раз дольше, чем вызов результата компиляции.

Это особенно обидно, когда выражение простое, например содержит только доступ к свойству (в библиотеках для маппинга, сериализации, дата-байндинга), вызову конструктора или метода (для IoC/DI решений).

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

Для уменьшения времени получения делегатов из деревьев выражений используют:

• Встроенную интерпретацию.
  Необходимость использования интерпретатора вместо компилятора указывается соответствующим флагом:

  Expression.Compile(preferInterpretation: true)
  

  Происходит через рефлексию, но с накладными расходами на формирование стека инструкций.

  Для платформ Xamarin.iOS, Xamarin.watchOS, Xamarin.tvOS, Mono.PS4 и Mono.XBox стандартная компиляция через генерацию IL (System.Reflection.Emit) долгое время была недоступна и на данный момент под капотом всегда откатывается к этому варианту.

• FastExpressionCompile от @dadhi.
  Ускоряет компиляцию за счет оптимизиpованной генерации IL и с меньшим количеством проверок совместимости.

  На платформах без поддержки JIT компиляции может использоваться только с включенным Mono Interpreter.

• Ручную интерпретацию.
  Используется для оптимизации вызовов рефлексии под специальные сценарии использования, например для добавления кэширования отдельных вызовов.

  Интерпретируя вручную, уже можно воспользоваться способами ускорения рефлексии. Самые эффективные из них, например Fasterflect, используют System.Reflection.Emit и на некоторых платформах так же могут требовать включения Mono Interpreter.

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

Компилировать выражения или какие-то их части во время написания кода (design-time) или сборки (compile-time).

Для compile-time компиляции делегатов к фрагментам деревьев выражений требуется сгенерировать соответствующий код.

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

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

Например, для класса со свойством

namespace Namespace{  public class TestClass  {    public int Property { get; set; }  }}

используемым внутри System.Linq.Expressions.Expression<T> лямбды

Expression<Func<TestClass, int>> expression = o => o.Property;

делегатами чтения и записи в общем виде являются

Func<object, object> _ = obj => ((Namespace.TestClass)obj).Property;Action<object, object> _ => (t, m) => ((Namespace.TestClass)t).Property  = (System.Int32)m;

и генерируемый код для их регистрации будет примерно таким:

namespace ExpressionDelegates.AccessorRegistration{  public static class ModuleInitializer  {    public static void Initialize()    {      ExpressionDelegates.Accessors.Add("Namespace.TestClass.Property",        getter: obj => ((Namespace.TestClass)obj).Property,        setter: (t, m) => ((Namespace.TestClass)t).Property = (System.Int32)m);    }  }}

Генерация

Наиболее известные решения для кодогенерации, на мой взгляд, это:

• Microsoft.CodeDom,

• T4,

• PostSharp,

• Fody,

• Roslyn Source Generators.

Отдельная область применения есть у каждого решения, и только Roslyn Source Generators умеет анализировать исходный C# код даже в процессе его набора.

Кроме того, именно Roslyn Source Generators видятся более или менее стандартом для кодогенерации, т. к. были представлены как фича основного компилятора языка и используют Roslyn API, используемый в анализаторах и code-fix.

Принцип работы Roslyn Source Generators описан в дизайн-документе (местами не актуален!) и гайде.

Вкратце: для создания генератора требуется создать реализацию интерфейса

namespace Microsoft.CodeAnalysis{  public interface ISourceGenerator  {    void Initialize(GeneratorInitializationContext context);    void Execute(GeneratorExecutionContext context);  }}

и подключить ее к проекту как анализатор.

Метод Initialize пригодится для выполнения какой-либо единоразовой логики. GeneratorInitializationContext на данный момент может быть полезен только для подключения посетителя узлов синтаксиса кода.

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

Для каждого файла исходного кода Roslyn предоставляет синтаксическое дерево в виде объекта SyntaxTree:

GeneratorExecutionContext.Compilation.SyntaxTrees

а так же семантическую модель:

semanticModel =  GeneratorExecutionContext.Compilation.GetSemanticModel(SyntaxTree)

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

Среди всех узлов синтаксических деревьев сборки нам нужно найти только интересующие нас лямбда-выражения типа System.Linq.Expressions.Expression<T> и отобрать из их узлов-потомков выражения, описывающие доступ к членам классов, создание объектов и вызов методов:

По семантике узла, так называемому символу (Symbol), можно определять:

• типы, используемые выражением;

• область видимости;

• IsStatic, IsConst, IsReadOnly и другие характеристики.

На основе такой информации и будем генерировать подходящий код.

В Roslyn API (Microsoft.CodeAnalysis) построить сигнатуру намного проще, чем c API рефлексии (System.Reflection). Достаточно сконвертировать символ в строку при помощи методаISymbol.ToDisplayString(SymbolDisplayFormat) c подходящим форматом:

Зная сигнатуры свойства/поля, его типа и обладателя формируем строки для добавления делегатов:

Оформляем код добавления делегатов в класс и отдаем компилятору:

var sourceBuilder = new StringBuilder(@"namespace ExpressionDelegates.AccessorRegistration{  public static class ModuleInitializer  {    public static void Initialize()    {");      foreach (var line in registrationLines)      {        sourceBuilder.AppendLine();        sourceBuilder.Append(' ', 6).Append(line);      }      sourceBuilder.Append(@"    }  }}");GeneratorExecutionContext.AddSource(  "AccessorRegistration",  SourceText.From(sourceBuilder.ToString(), Encoding.UTF8));

Этот код обязательно будет добавлен в сборку ...если генератор сможет отработать :)

Дело в том, что хоть Source Generators технически и не фича языка, поддерживаются они только в проектах с C# 9+. Позволить такую роскошь без костылей и ограничений на данный момент могут только проекты на .NET 5.

Совместимость

Поддержку Roslyn Source Generators API для .NET Standard, платформ .NET Core, .NET Framework и даже Xamarin поможет организовать Uno.SourceGeneration.

Uno.SourceGeneration предоставляет собственные копии интерфейса ISourceGenerator и атрибута [Generator], которые при миграции на С# 9 меняются на оригинальные из пространства имен Microsoft.CodeAnalysis простым удалением импортов Uno:

using Uno.SourceGeneration;using GeneratorAttribute = Uno.SourceGeneration.GeneratorAttribute;using ISourceGenerator = Uno.SourceGeneration.ISourceGenerator;

<ItemGroup>  <SourceGenerator Include="PATH\TO\GENERATOR.dll" /></ItemGroup>

Инициализация

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

Для этих целей отлично подходит Module Initializer. Это конструктор сборки (а точнее ее модуля), который запускается сразу после ее загрузки и до вызовов к остальному коду. Он давно есть в CLR, но к сожалению, в C# его поддержка c атрибутом [ModuleInitializer] добавлена только в 9 версии.

Решение по добавлению конструктора в сборку с более широкой поддержкой платформ есть у Fody плагин Fody.ModuleInit. После компиляции добавляет классы с именами ModuleInitializer в конструктор сборки. В такой класс и будем оборачивать инициализацию сгенерированных делегатов.

Подключение Fody.ModuleInit через MSBuild свойства вместо FodyWeavers.xml исключит конфликты с другими Weaver-ами Fody в проекте клиента.

Использование

Таким образом, при сборке проекта:

1. Source Generator добавит в сборку код, регистрирующий делегаты для деревьев выражений, в обертке класса ModuleInitializer.

2. Fody.ModuleInit добавит ModuleInitializer в конструктор сборки.

3. Во время работы приложения при подгрузке сборки выполнится ModuleInitializer, и сгенерированные делегаты будут добавлены к использованию.

Проверяем:

Expression<Func<string, int>> expression = s => s.Length;MemberInfo accessorInfo = ((MemberExpression)expression.Body).Member;Accessor lengthAccessor = ExpressionDelegates.Accessors.Find(accessorInfo);var length = lengthAccessor.Get("17 letters string");// length == 17

При декомпиляции сборки видно, что сгенерированный код и инициализатор модуля на месте:

Бенчмарки

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

Полный вариант таблицы, с бенчмарками интерпретации.

А судя по результату профилирования поиска сгенерированного делегата, самое долгое построение сигнатуры, ключа для поиска.

Идеи насчёт оптимизации построения сигнатур по System.Reflection.MemberInfo приветствуются. Реализация на момент написания.

Заключение

По итогу получилось современное решение для кодогенерации с актуальной совместимостью и автоматической инициализацией.

Полный код можно посмотреть на: github/ExpressionDelegates, а подключить через nuget.

Для тех, кто будет пробовать Source Generators хотелось бы отметить несколько полезностей:

• Source Generator Playground (github).
  Позволяет экспериментировать с Roslyn Source Generators в браузере, онлайн.

• Окно визуализации синтаксиса для Visual Studio.
  Удобный инструмент для знакомства с Roslyn Syntax API на собственном коде.

• Отлаживается Source Generator вызовом отладчика из его кода. Пример.
  Для этого нужен компонент Visual Studio Just-In-Time debugger и включенная настройка Tools -> Options -> Debugging -> Just-In-Time Debugging -> Managed.

• В сгенерированных *.cs файлах срабатывают брейкпоинты, проверено в Visual Studio16.8.
  При генерации через Uno.SourceGeneration файлы размещаются по пути: \obj\{configuration}\{platform}\g\.
  С Roslyn Source Generators их появление включается через MSBuild свойство EmitCompilerGeneratedFiles.
  Стандартный путь: \obj\{configuration}\{platform}\generated\, переопределяется в свойстве CompilerGeneratedFilesOutputPath.

• Source Generators можно конфигурировать свойствами MSBuild.
  При использовании Uno.SourceGeneration значение получают вызовом

  GeneratorExecutionContext.GetMSBuildPropertyValue(string)
  

  Для Roslyn Source Generators требуемые свойства необходимо сперва отдельно обозначить в MSBuild группе CompilerVisibleProperty и только после вызывать:

  GeneratorExecutionContext.AnalyzerConfigOptions.GlobalOptions  .TryGetValue("build_property.<PROPERTY_NAME>", out var propertyValue)
  

• Из генератора можно кидать предупреждения и ошибки сборки.

  //Roslyn Source GeneratorsGeneratorExecutionContext.ReportDiagnostic(Diagnostic)//Uno.SourceGeneration:GeneratorExecutionContext.GetLogger().Warn/Error().
  

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

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

Стресс

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

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

Селье, автор теории стресса, различал дистресс и эустресс.

Дистресс негативен, он забирает все ресурсы, истощает нас; мы не можем справиться с ним. Эустресс положителен, он помогает нам, за счет адаптации к новым условиям, развиваться и находить новые точки роста.

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

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

В деятельности разработчика быть стрессорами и вызывать стресс могут:

конфликтные и непрозрачные отношения в команде

неясные задачи и регулярная неизвестность завтрашнего дня

чрезмерно быстрая смена задач

стихийные изменения состава команды

критика, обесценивание, ревью, направленное на подавление

Стресс возникает в ответ на новые обстоятельства чаще всего на те, которые нам некомфортны.

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

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

Тревога

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

Тревогу мы тоже чувствуем физически. Наше тело, в силу того, что мозг посылает сигналы опасности, мобилизуется и дает реакцию.

Давайте снова возьмем в пример собеседование. Разработчик отменяет собеседование из-за тревоги, что, придя в команду, не справится с задачами. Ситуация не случилась, она находится в точке неизвестности, возникает на уровне фантазий. Но тревога присутствует.

Тревога нуждается в исследовании, в поиске того, что именно вызывает опасения.

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

Если резюмировать, то тревога ответная реакция на стресс, при которой не осознаются факторы, вызывающие беспокойство.

Тревожность

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

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

Что со всем этим делать

В проработке стресса, тревоги и тревожности важен индивидуальный, субъективный подход. Но есть общие рекомендации, которые вы можете применить с заботой о себе.

Классическая триада, которая рекомендована при высокой тревоге, такова:

1. хотя бы по минимуму заниматься спортом

2. вести дневник эмоций

3. медитировать

А вот ещё несколько подходящих в такой ситуации практик.

Рационализируйте то, что вызывает тревогу, и ищите противопоставления этому. Я боюсь провалить собеседование Я достаточно подготовлен, чтобы пройти собеседование.

Ищите и пробуйте способы самоподдержки от слов одобрения до прогулки и приятных действий в свой адрес.

Установите отношения со своим телом. Совсем скоро Марина Могилевцева расскажет о том, как можно обращаться с тревогой и помогать себе с опорой на тело. Следите тут или в канале psyvit; мы сообщим в канале, когда выложим статью.

Дыхание. В момент тревоги обратите внимание на свое дыхание, сделайте глубокий и спокойный вдох и сосчитайте до 4-х. Выдох также сделайте на 4 счета.

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

Увольтесь. Если ситуация на работе не меняется и вы регулярно ощущаете себя в стрессе, а в ответ слышите: Терпи!, это сигнал позаботиться о себе самостоятельно.

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

Самое главное и важное на все времена - Берегите себя!