День 1454. #TipsAndTricks
Короткие Советы и Трюки в C#
1. Регистронезависимый Словарь
Указав StringComparer в конструкторе словаря, вы можете использовать регистронезависимые ключи для доступа к значениям:

var dict = new Dictionary<string, object>
 (StringComparer.CurrentCultureIgnoreCase)
{
  ["home"] = "casa",
  ["BRIDGE"] = "ponte"
};

Console.WriteLine(dict["Home"]);
Console.WriteLine(dict["bridge"]);

2. Sort() или OrderBy()
Оба метода сортируют элементы списка. Но есть различия.
Sort()
- сортировка «на месте» (пока, иммутабельность);
- сортировка по умолчанию.

OrderBy()
- создаёт новый список;
- можно использовать правило сортировки.

List<int> list = new() { 3, 1, 6, 2, 8};
list.Sort();
var sortedList = 
 list.OrderByDescending(_ => _);

3. String.IsNullOrEmpty или String.IsNullOrWhiteSpace
Если вам нужно проверить строку, введённую пользователем, имейте в виду, что пользователь может ввести символы, которые не будут «пойманы» методом String.IsNullOrEmpty():

        NOE NOWS
"hi"    ❌  ❌
null    ✅  ✅
""      ✅  ✅
"    "  ❌  ✅
"\n"    ❌  ✅
"\t"    ❌  ✅
"\t \n" ❌  ✅

4. Интерполяция строк с помощью FormattableString
Если вы используете интерполяцию для обработки случаев, когда значение изменяется в зависимости от культуры:
- храните строку как FormattableString;
- форматируйте её, используя IFormatterProvider (или CultureInfo).

var dt = DateTime.Now;
FormattableString fs = $"{dt:dddd}";
fs.ToString();
//Monday
fs.ToString(new CultureInfo("es-ES");
// lunes
fs.ToString(new CultureInfo("ru-RU");
// понедельник

Источник: https://twitter.com/BelloneDavide/

День 1455. #ЧтоНовенького
EF8: Необработанные SQL-Запросы на Несвязанные Типы
На прошлой неделе мы подробно рассматривали новые функции C#11, появившиеся прошедшей осенью. Пора уже заглянуть в будущее. Сегодня посмотрим, что нас ждёт в следующей версии Entity Framework.

Следующая, восьмая, версия Entity Framework должна получить новую интересную функцию: поддержку необработанных SQL-запросов без предварительного определения типа объекта результата в DbContext.

Это означает меньше шаблонного кода!

До сих пор приходилось создавать сопоставление для типов, возвращаемых из SqlQueryRaw. В Entity Framework 8 это будет выглядеть немного иначе, с чем нам поможет новая функция:

context.Database.SqlQueryRaw<MyUnmappedType>
 (@"SELECT * FROM SomeTableOrView");

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

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

Обсуждение этой функции на GitHub началось ровно 5 лет назад. Наконец, она добралась до кандидата.

Источник: https://steven-giesel.com/blogPost/d1f069fb-7f6d-4f80-a98f-734755474ae1

День 1456. #ЗаметкиНаПолях
Используем Асинхронные Потоки в .NET Framework
Хотя IAsyncEnumerable доступен только в C#8 и поддерживается в .NET Core 3.x и .NET Standard 2.1, это вовсе не означает, что вы не можете использовать эту функцию в .NET Core 2.x или .NET Framework.

Рассмотрим следующий (не компилирующийся) код в проекте .NET 4.7 и попробуем заставить его работать:

async IAsyncEnumerable<string> GetAsync()
{
  for (var i = 0; i < 20; i++)
  {
    var item = await ReadAsync(i);
    yield return item;
  }
}

async Task<string> ReadAsync(int i)
{
  await Task.Delay(100);
  return $"Count {i}";
}

Проект .NET Standard 2.0 не знает об интерфейсе IAsyncEnumerable. Поэтому первое, что нам нужно сделать, это установить NuGet-пакет Microsoft.Bcl.AsyncInterfaces.

Теперь компилятор находит интерфейс IAsyncEnumerable, но Visual Studio по-прежнему жалуется, потому что выбранная версия языка C#7.3, а асинхронные потоки — это функция C#8.

Мы можем это исправить, обновив файл .csproj проекта и указав компилятору использовать C#8 в качестве версии языка:

<PropertyGroup>
  <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
  <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
  …
  <LangVersion>8</LangVersion>
</PropertyGroup>

Подробнее об использовании новых функций языка C# на старых платформах в этом посте.

Источник: https://bartwullems.blogspot.com/2020/01/asynchronous-streams-using.html

День 1457. #МоиИнструменты
Мониторинг Сайтов в UptimeRobot
Полезно знать, когда сайты, которые вы поддерживаете, не работают. Несмотря на то, что в ASP.NET Core есть встроенные способы проверки работоспособности, иногда нужно простое решение, которое требовало бы меньше кода, работало для произвольного количества сайтов, и просто уведомляло бы, когда сайт недоступен, и когда он снова онлайн.

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

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

Начать довольно просто. Вы создаёте учетную запись, а затем настраиваете свой первый монитор. Помимо обычной проверки статуса ответа HTTP можно использовать пинг, проверку определённого порта или ключевого слова - любого слова, которое должно (или не должно) присутствовать на странице сайта. Последний вариант полезен, если вы не просто хотите знать, что сервер ответил каким-то кодом успеха, а что вернулось фактическое содержимое страницы (или хотя бы какая-то важная его часть).

Каждый монитор может уведомлять одного или нескольких членов команды по электронной почте о недоступности сайта или когда он снова становится доступен.

У сервиса также есть приложения под Android и iOS, так что следить можно и с телефона. А если вы хотите отображать статус сайтов вашей команды на экране ТВ, даже в бесплатном варианте есть опция "TV Mode" (на картинке ниже).

Источник: https://ardalis.com/monitor-sites-with-uptime-robot-or-your-own-process/

День 1458. #Книги
Сегодня порекомендую ещё одну книгу по PostgreSQL.

«PostgreSQL изнутри» (Рогов Е.В. — М.: ДМК Пресс, 2022).

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

Пока я её ещё не дочитал (всё-таки, 660 страниц), но уже могу порекомендовать тем, кто хочет во всех деталях познакомиться с принципами работы и тонкой настройкой СУБД PostgreSQL. Сразу оговорюсь, книга не для новичков. Необходимы знания принципов работы реляционных баз данных на хорошем уровне.

По структуре книга напомнила «CLR via C#» Рихтера. Первые 300 (!!!) страниц – внутреннее устройство. И они мне дались очень тяжело. По нескольку раз приходилось возвращаться к предыдущим главам, потому что понятия и принципы забывались. Дальше уже идёт рассказ о практическом использовании: выполнении запросов, планы выполнения, разные типы индексов и т.п.

День 1459. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 6
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

6. Дар времени
Уделять время другим — это простой способ получить больше от ваших отношений, что является ключевым преимуществом эмоционального интеллекта, способности понимать эмоции и управлять ими.

«Самый ценный ресурс, который у нас есть, — это время», — сказал Стив Джобс. Он был прав: всегда можно заработать больше денег. Но время конечно; как только оно ушло, его не вернуть.

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

Исследовательская фирма Gallup обнаружила, что сотрудники, менеджеры которых проводили с ними регулярные встречи, были почти в три раза более заинтересованы в работе, чем их коллеги, у которых регулярных встреч не было. Сотрудники, которые ежедневно общались со своими менеджерами, были наиболее вовлечены. Извините, но придётся терпеть митинги.
Отвечать на письма — это одно; проявление личного интереса - другое. Исследование также показало, что сотрудники ценят общение не только в отношении своих ролей и обязанностей, но и о жизни вне работы.

А как же наша личная жизнь?
В исследовании, проведенном психологами из Цюрихского университета, участникам было предложено встретиться с тремя людьми, которые им небезразличны, в течение недели, чтобы «подарить им своё время» (в смысле, больше, чем они обычно с ними проводили). По сравнению с другой группой, которая писала о своих воспоминаниях в ежедневном журнале, «дарившие время» сообщали о большем уровне счастья. Чем дольше они продолжали практику, тем более счастливыми себя чувствовали.

Вы можете сделать то же самое.
Почему бы не подарить кому-нибудь своё время? Выберите человека, которому вы хотели бы уделить часть своего времени, а затем запланируйте сделать с ним что-то, чего вы обычно не делаете:
- пригласите в гости или на ужин или даже просто на кофе;
- прогуляйтесь в парке;
- позвоните по видео-связи старому другу, которого вы не видели целую вечность;
- возьмите отгул после обеда, чтобы провести время с другом, ребёнком или другим членом семьи.

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

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

Поэтому, планируя предстоящую неделю, помните:
Время — самый ценный ресурс, который у вас есть. Тратьте его с умом. Потому что, как только оно уйдет, вы никогда не вернёте его обратно.

Источник: https://www.inc.com/justin-bariso/how-to-increase-emotional-intelligence.html

День 1460. #ЗаметкиНаПолях
Ref-поля в C#11
Ключевое слово ref указывает, что переменная передаётся по ссылке. Это позволяет вызываемой функции изменить значение переменной в вызывающем её коде. C# поддерживает ref для аргумента метода или возврата метода, а также для локальной переменной:

int i = 10;

Foo(ref i);

ref int Foo(ref int j)
{
 ref int k = ref i;
 return ref j;
}

В этом примере параметр j и локальная переменная k являются псевдонимами для переменной i. Когда вы получаете их значения, читается i, а когда устанавливаете - устанавливается значение i. Ref-переменные могут указывать как на память на стеке, что подразумевает строгие правила области видимости, так и на память в куче, которой управляет сборщик мусора.

Компилятор сохраняет область видимости, т.е. разрешено возвращать ref j, потому что компилятор знает, что переменная, на которую ссылается параметр, всё ещё будет в области видимости. Компилятор не позволит вам вернуть ссылку на k, потому что локальная ссылка может указывать на стековую память, которая выйдет за пределы области видимости при возврате из метода.

C#8 представил ref-структуры и использовал их для реализации Span. Тип Span — это абстракция в стеке для области памяти стека или кучи. Для представления памяти Span нужны два поля: ref-поле, указывающее на первый элемент памяти, и поле для хранения длины блока памяти. До C#11 ref-поле было внутренней реализацией среды выполнения.

В C#11 ref-поля открыты для общего использования. Они позволяют вам определить ваши собственные ref-структуры имеющие ref-поля. Например, вы можете создать тип, читающий информацию из большой структуры, которая может находиться в стеке, в куче или даже в неуправляемой памяти:

struct MyStruct { 
 /* большая структура */
}

ref struct StructReader
{
  ref MyStruct _value;
  public StructReader(ref MyStruct value) 
    => _value = ref value;

  public void ReadValue(Span<byte> value)
  { … }
  …
}

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

void Process(ref StructReader reader)
{
  Span<byte> buffer = stackalloc byte[10];

  reader.ReadSomeValue(buffer);
}

Здесь будет выдана ошибка CS8352: Cannot use variable 'buffer' in this context because it may expose referenced variables outside of their declaration scope (Невозможно использовать переменную 'buffer' в этом контексте, потому что она может раскрыть переменные, на которые она ссылается, за пределы области их объявления).

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

public void ReadSomeValue(
 scoped Span<byte> value
)
{ … }

Т.е. ключевое слово scoped указывает компилятору обращаться с аргументом value так же, как если бы он был локальной переменной в методе.

Источник: https://developers.redhat.com/articles/2023/01/11/5-new-advanced-features-improving-c-11#ref_fields

День 1461. #МоиИнструменты
Полезные NuGet-Пакеты для Юнит-Тестирования
Помимо всем известных пакетов для юнит-тестирования, вроде Moq, NSubstitute или FluentAssertions, есть менее популярные, но оттого не менее полезные. Ниже приведу некоторые из них.

1. JustMock Lite
Это бесплатный пакет с открытым исходным кодом, который упрощает юнит-тестирование, простой в использовании, многофункциональный, мощный и гибкий. Он похож на Moq, но, как мне показалось, имеет более понятный fluent-API настройки и более богатую функциональность. JustMock Lite — бесплатная версия коммерческого продукта JustMock.

2. System.IO.Abstractions
В основе библиотеки лежат IFileSystem и FileSystem. Вместо прямого вызова таких методов, как File.ReadAllText, используйте IFileSystem.File.ReadAllText. Они имеют точно такой же API, который можно внедрять и тестировать. Библиотека также поставляется с набором тестовых помощников, чтобы избавить вас от необходимости имитировать каждый вызов для базовых сценариев. Они не являются полной копией реальной файловой системы, но помогут вам в тестах.

3. DeepEqual
Это расширяемая библиотека для глубокого сравнения. Чтобы проверить экземпляры объектов на равенство, просто вызовите метод расширения IsDeepEqual:

bool result = obj1.IsDeepEqual(obj2);

При использовании внутри теста вы можете вместо этого вызвать ShouldDeepEqual. Этот метод выдает исключение с подробным описанием различий между двумя объектами:

obj1.ShouldDeepEqual(obj2);

Также библиотека имеет fluent-API для кастомизации сравнения (например, можно игнорировать отдельные свойства).

4. ObjectDumper.Net
Это утилита, предназначенная для сериализации объектов C# в строку для целей отладки и ведения журнала. Вы можете использовать её в любом проекте .NET, совместимом с PCL. ObjectDumper предоставляет два отличных способа визуализации объектов .NET в памяти:
- DumpStyle.Console: сериализует объекты в удобочитаемые строки, часто используется для записи сложных объектов C# в файлы журналов.
- DumpStyle.CSharp: сериализует объекты в код инициализатора C#, который можно использовать для повторного создания объекта C#.

5. MockHttp
Это тестовый слой для библиотеки Microsoft HttpClient. Он позволяет настраивать заглушки для HTTP-ответов и может использоваться для тестирования сервисного уровня приложения.
MockHttp определяет замену HttpMessageHandler, механизма, управляющего HttpClient, который предоставляет гибкий API конфигурации и предоставляет готовый ответ. Вызывающий объект (например, сервисный уровень вашего приложения) остается в неведении о его наличии.

Источник: https://blog.markoliver.website/Testing-In-Dotnet

День 1462. #Здоровье
Слишком Много Сидеть Вредно, но Снизить Вред Легко
Конечно, вы слышали об опасностях сидения весь день, но что поделать, такая работа, верно? Нет. Согласно исследованию, опубликованному в Американского колледжа спортивной медицины, пять минут легкой ходьбы каждые полчаса могут помочь снизить риск, связанный с длительным сидением в течение дня.

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

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

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

Регулярные «активности» могут казаться недостижимыми, если офисная культура не способствует этому. Существуют социальные нормы, согласно которым, если вы встаете из-за стола, люди думают, что вы не работаете.

Авторы исследования работали над тем, чтобы убедить работодателей в важности движения в течение рабочего дня — не только для личного здоровья, но и для повышения продуктивности. Упражнения в течение 150 минут в неделю могут снизить кровяное давление и уровень холестерина у некоторых взрослых. Повышение уровня активности — первый шаг к этому. Сидение — это профессиональный риск, а здоровый работник — более продуктивный работник. Команда обнаружила, что участники, прерывавшие сидение, принесли больше, чем просто пользу для собственного физического здоровья. Это также снижало их усталость и улучшало настроение.

Просто сидеть за столом и работать в течение 8 часов на самом деле может быть не так уж и здорово, если вы беспокоитесь об общей производительности своей работы. И хотя стоячие столы набирают популярность, они не всегда применимы. Также нет веских научных доказательств того, что стоять действительно лучше, чем сидеть. У людей может возникнуть ложное ощущение, что они здоровы, потому что они используют стоячий стол, хотя, возможно, на самом деле им не лучше.

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

Вы можете просто поприседать, мягко вставая и снова садясь. Если у вас много места, можно делать танцевальную паузу под любимую песню (большинство песен как раз длятся 3-5 минут). Если места мало, можно потягиваться или двигать руками во всех направлениях, выполнять боковые наклоны и скручивания на стуле. Даже когда вы не можете пошевелить нижней частью тела и на самом деле встать с сидения, активное глубокое дыхание, задействующее диафрагму и двигающее ребра, полезно для вашей осанки и общего состояния здоровья. Общая идея состоит в том, чтобы двигаться всеми возможными способами в зависимости от ваших возможностей.
Любой активный перерыв в сидении всё равно принесёт некоторую пользу.

Источник: https://edition.cnn.com/2023/01/12/health/sitting-prolonged-study-wellness/index.html

День 1463. #ЗаметкиНаПолях
Разбираем Ключевое Слово Unchecked в C#
Ключевое слово unchecked в C# используется для отключения проверки переполнения для целочисленных операций в блоке кода. Т.е. программа не выбросит исключение и продолжит работу с результирующим значением, если операция может вызвать переполнение или потерю значимости. Это поведение по умолчанию для целочисленных операций в C#:

int x = int.MaxValue; 
x = x + 1;

Здесь x будет равно -2147483648, исключения не будет.

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

Чтобы такого не происходило, в C# есть ключевое слово checked, которое может быть использовано, чтобы указать, что операция или блок кода должен выбрасывать исключение при переполнении:

int x = int.MaxValue; 
checked 
{ 
  x = x + 1; 
}

Этот код выбросит System.OverflowException.

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

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

Рассмотрим несколько примеров:

Console.WriteLine(
 unchecked(long.MaxValue + long.MaxValue)
);
Console.WriteLine(
 unchecked((ulong)(long.MaxValue + long.MaxValue))
);
Console.WriteLine(ulong.MaxValue);

В коде выше long.MaxValue + long.MaxValue превышает максимальное значение, которое может представлять long, но из-за ключевого слова unchecked программа не выдаст исключения. Вместо этого переполнение выдаст результат, в данном случае -2.
Во втором случае результат будет преобразован в ulong, т.е. 18446744073709551614.
В третьем случае мы просто выводим максимальное значение для ulong -
18446744073709551615.

Итого
Когда арифметическая операция возвращает число, которое слишком велико или слишком мало для представления используемым типом данных, такое состояние называется переполнением (overflow).
Подобно переполнению, недополнение (underflow) происходит, когда результат операции слишком мал, чтобы быть представленным типом данных.

В языке C# есть техника, называемая переносом (wrap-around), для управления переполнением и недополнением в обеих ситуациях. Т.е. в случае переполнения, всё, что выше максимального значения, будет добавлено к минимальному значению типа, например:
int.MaxValue + 1 = int.MinValue;
аналогично для недополнения:
int.MinValue – 2 = int.MaxValue - 1;

Заметьте, что несмотря на то, что арифметические операции над переменными по умолчанию исполняются в unchecked контексте, константные выражения вычисляются по умолчанию в проверяемом (checked) контексте, а в случае переполнения возникает ошибка времени компиляции. Т.е. нельзя использовать

x = int.MaxValue + 1;

При использовании констант нужно явно указать unchecked контекст:

x = unchecked(int.MaxValue + 1);

Источник: https://dev.to/simsekahmett/understanding-and-using-the-unchecked-keyword-in-c-hfg

День 1464. #Курсы
Функциональный Февраль
Когда я только начинал вести этот канал (а недавно ему исполнилось 4 года), в одном из первых постов я упомянул ресурс для прохождения упражнений на программирование Exercism. Он не такой популярный, как Codewars или LeetCode, но я тогда о них не знал, а этот попался первым.

В общем, сейчас не собственно о сайте, а о челлендже, который они запустили в этом году #12in23. Суть в том, что вы изучаете 12 разных языков в течение 2023 года, а Exercism помогает вам в этом, выпуская интересные видео с рассказами о каждом из языков, а также упражнения на этих языках. Январь мы, очевидно, пропустили, но можно начать с февраля, тем более что на февраль запланирован челлендж по функциональным языкам.

И первое видео из этой серии – об F#. Если честно, я давно хотел его попробовать, но всё не доходили руки, да и не было мотивации. И вот подвернулся случай. Итак, видео с объяснением основных концепций функционального программирования вообще и F# в частности тут - https://youtu.be/uIFGx1SDnWI

А сам челлендж #12in23 – здесь. Сайт требует регистрации, но можно зайти через аккаунт на GitHub. Изучайте язык по видео, выполните 5 заданий на любом из функциональных языков до конка февраля и получите бейдж «Functional February».

День 1465. #CodeReview
Как Оптимизировать Обзоры Кода
Обзоры кода требуют значительных временных затрат, и важно понять, как инженеры могут извлечь из них максимальную пользу. Процесс проверки кода (с помощью некоторой автоматизации) может быть идеальной возможностью для членов команд развить навыки асинхронного общения и внести вклад в обмен знаниями в команде.

Доверьтесь асинхронной связи
Пандемия положила начало периоду самоизоляции, и многие из нас теперь работают из дома. Благодаря этому эффективная асинхронная связь стала первостепенной задачей. В дополнение к email и мессенджерам, проверка пулл-реквестов является вариантом асинхронного общения. У асинхронного общения есть свои преимущества:
- Люди из разных часовых поясов могут чувствовать себя вовлеченными.
- Удобно для людей с разным знанием языка (человеческого, а не языка программирования).
- Обеспечивает гибкость для людей с разными графиками.

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

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

Ещё есть документация. Очень сложно подготовить хорошую документацию для проектов, особенно если нет специального технического писателя. Обратите внимание на пассивную документацию: способы обмена информацией без активного участия, т.е. все виды артефактов, которые команды создают, когда они исследуют, проектируют и создают продукт публично. Пассивная документация включает письменный диалог для исследования ошибки или описания пулл-реквестов. Да, «пассивные документы» сложнее искать, если у них нет специального оглавления или маркировки, но они обеспечивают удобный формат для обмена знаниями.

Позвольте автоматизации оптимизировать процессы
Иногда требуется машина, чтобы помочь людям не мешать друг другу, когда дело касается совместной работы. Создание GitHub Actions и подобных ему сервисов позволило легко внедрять автоматические проверки в процесс обзора кода. Но здесь возникает и большая ответственность. Какие проверки целесообразно автоматизировать? Стратегия может быть примерно такая:

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

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

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

Итого
Хотя проверка кода часто считается утомительной, она может стать благодатной почвой для роста эмпатии, более активного общения и лучшего обмена знаниями внутри команд. А даже небольшая автоматизация может иметь большое значение.

Источник: https://github.com/readme/guides/code-review-optimization

День 1467. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 7
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

7. Защитное одеяло
«Я страдаю от синдрома самозванца. Я беспокоюсь, когда пишу отзывы и конструктивную критику своим сотрудникам».

Знакомо? Вы не одиноки. Но есть эмоционально-интеллектуальный трюк, который вы можете использовать, чтобы избавиться от этих чувств, обрести уверенность в себе и быть на высоте. Мне нравится называть это защитным одеялом.

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

Ты (и я) такие же. Нам нужно чувствовать себя в безопасности, прежде чем мы сможем быть самим собой и полностью раскрыть свой потенциал.

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

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

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

Вам нужно защитное одеяло. Что может им быть?

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

- Уединение: если вы интроверт, некоторое время в одиночестве может зарядить вас физически, умственно и эмоционально.
- Что-то ещё, что успокаивает лично вас.

- «Голубой дельфин»: позитивная мысль, которую вы можете использовать, чтобы заменить негативные мысли. Например, если перед важной встречей вам забивает голову мысль «главное не нервничать», и от неё вы начинаете нервничать ещё больше, говорите себе: «Я так взволнован. Все должно пройти отлично». Используете потенциальный негатив — свою нервозность — и трансформируете его в позитив. Вы не сможете предотвратить появление негативных мыслей. Но ваш голубой дельфин позаботится о том, чтобы они не задерживались надолго. Это поможет вам заставить мысли и эмоции работать на вас, а не против вас.

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

Источник: https://www.inc.com/justin-bariso/emotional-intelligence-self-confidence-how-to-be-your-best-self.html

День 1468. #ВредныеСоветы
11 Способов Усложнить Себе Жизнь в C#. Начало
Программировать тяжело. Большинство из нас работает в командах, создавая ПО, с которым будут работать другие люди. Поэтому важно, чтобы мы старались облегчить жизнь нашей команды. Вот 11 примеров, как НЕ надо делать в C#.

1. Злоупотребление циклами
Цикл for существует во многих языках. Вы видели его миллион раз:

for(int i = 0; i < 10; i++) { }

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

for (выражение «до»;
 условие;
 выражение «после» каждой итерации)
{}

3 выражения в круглых скобках задают условия выполнения цикла. Но это просто операторы, как и любые другие. А значит вы можете написать там всё, что захотите.

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

// вместо:
while (true) {}
// можно написать:
for (; ;) {}

Хотя это не слишком полезно.

Можно опустить третье выражение и добавить приращение в условное выражение:

for(int i = 0; ++i < 100;) {}

Можно использовать строки. Удалим буквы из строки по одной:

for (string name = "Brendan"; 
  name.Length > 0;
  name = name.Substring(1))
{
  Console.WriteLine(name);
}

Чтобы совсем оторваться, создадим несколько переменных и будем использовать их в цикле! Можно использовать кортежи:

for (
 var (number, name) = (1, "Brendan");
 number < 7; 
 name += number.ToString(), number += 1)
{
    Console.WriteLine(name);
}

2. Построение и деконструкция кортежа в конструкторе
Кстати, о кортежах. Вы можете конструировать и деконструировать кортежи в одной и той же строке. Удивим команду, поместив весь конструктор в одну строку:

public Person(string prefix, string first, string middle, string last, string suffix, string nickname, DateTime birthday, string favoriteColor)
{
  (Prefix, First, Middle, Last, Suffix, Nickname, Birthday, FavoriteColor) = (prefix, first, middle, last, nickname, suffix, birthday, favoriteColor);
}

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

Заметили? Тут есть ошибка.
Да, nickname и suffix перепутаны местами. И тут не будет ошибки компилятора, так как они одного типа.

Продолжение следует…

Источник: https://brendoneus.com/post/Ways-Of-Making-CSharp-Harder/

День 1469. #ВредныеСоветы
11 Способов Усложнить Себе Жизнь в C#. Продолжение
Начало

3. Чрезмерное или недостаточное использование var
Var, на самом деле, замечательное дополнение к языку, позволяющее не указывать тип переменной, поскольку компилятор уже знает этот тип. Но просто нигде не указывать тип, а использовать var, - это перебор. Var полезен, когда тип сложный:

// ясно, но длинно
IEnumerable<IGrouping<DateOnly, Person>> peopleGroupedByBirthdate = 
  people.GroupBy(
   p => p.Birthdate,
   p => p);

// менее ясно, но короче
var peopleGroupedByBirthdate = 
  people.GroupBy(
   p => p.Birthdate,
   p => p);

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

Тогда почему бы просто не использовать его везде? Потому, что var скрывает информацию:

var author1 = GetAuthor1();
var author2 = GetAuthor2();
var authorName = GetAuthorName();
var authorFullName = GetAuthorFullName();

Мы не можем определить тип этих переменных, не наведя на них курсор. Скорее всего, GetAuthorName и GetAuthorFullName одного типа, но вовсе не факт. Мне знакомы люди, которые бросались из крайности в крайность: от полного неприятия var до использования его повсеместно. Как везде, важен баланс. Если вы заметили, что наводите курсор на переменную, чтобы узнать её тип, задумайтесь, может стоит указать его явно?

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

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

<NoWarn>12345,23456,34567,45678,56789</NoWarn>

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

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

Продолжение следует…

Источник: https://brendoneus.com/post/Ways-Of-Making-CSharp-Harder/

День 1470. #ВредныеСоветы
11 Способов Усложнить Себе Жизнь в C#. Продолжение
1-2
3-4

5. Работа с disposable-типами без using
Говоря о disposable-типах, мы обычно имеем в виду, что тип реализует интерфейс IDisposable. Когда вы создаёте экземпляр такого типа, он должен очищаться после использования. В помощь вам выражение using:

using (var sw = new StreamWriter(path, true))
{
  sw.WriteLine("Test");
}

Если вы хотите расстроить команду, перестаньте использовать using. Что может пойти не так? Многое. Тип реализует IDisposable, чтобы его можно было правильно очистить, т.е. освободить ресурсы (сетевые подключения, дескрипторы файлов и т.д.), которые использовал тип, перед его удалением. Если их правильно не освободить, они останутся открытыми:

SqlConnection conn = new (connString)
SqlCommand command = new (query, conn);
connection.Open();
SqlDataReader reader = command.ExecuteReader();
while (reader.Read())
{
 …
}

Здесь объекты SqlConnection и SqlDataReader необходимо очищать. Если вы волнуетесь за вложенность, начиная с C#8 можно использовать декларации using, т.е. не заключать код в фигурные скобки.

using SqlConnection conn = new (connString);
…
using SqlDataReader reader = command.ExecuteReader();
…

Здесь переменные conn и reader будут освобождены в конце текущего блока кода (например, при выходе из метода).

См. также «Мои любимые ошибки с IDisposable»

6. Генерация исключений вместо возврата
Вы можете привлечь внимание обзорщика (меня точно) к вашему коду, если в ожидаемой или вероятной ситуации выбросите исключение вместо того, чтобы просто обработать этот вариант и вернуть значение.
Пользователь забыл ввести значение? Это ошибка валидации, а не исключительный случай. Мы можем (и должны) возвращать результат ошибки валидации, чтобы проинформировать пользователя о проблеме. Если же значение отсутствовало во внутренних расчетах, это проблема целостности данных после валидации - исключительный случай, который может потребовать остановки кода, чтобы предотвратить дальнейшие проблемы.

Как удивить команду? Ну, в теории можно построить всю логику приложения на исключениях:

private void UpdateProfile(Profile data)
{
  if (data is null)
    throw new ArgumentNullException(nameof(data));
  if (string.IsNullOrWhiteSpace(data.FullName))
    throw new ArgumentException("Missing Name", nameof(data));

  // сохраняем изменения

  throw new UpdatedSuccessfullyException(data);
}

Это примерно как события, если не обработать которые, приложение упадёт.

Продолжение следует…

Источник: https://brendoneus.com/post/Ways-Of-Making-CSharp-Harder/

День 1471. #ВредныеСоветы
11 Способов Усложнить Себе Жизнь в C#. Продолжение
1-2
3-4
5-6

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

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

var st = new SimpleTransfer();
var st = new ServiceTime();
var st = new SecretTunnel();

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

Вот некоторые аббревиатуры, которые мне встречались в коде, и являлись не тем, чем казалось на первый взгляд:
"E2E" – не End-to-End,
"IRS" – не имело отношения к налогам,
"IBM" – не про компьютерную компанию,
"S3" – не про хранилище AWS,
"DDL" – не DataDefinitionLanguage и не DropDownList,
"DLL" – не DynamicLinkLibrary.

8. Использование однобуквенных переменных
Есть только два места, где однобуквенная переменная – это нормально. Но даже в этом случае может быть лучше использовать полное имя.

1) Классическая i в стандартном цикле for. Если вы не используете саму переменную, а просто считаете, сколько раз должен выполниться цикл, это нормально:

for (int i = 0; i < сount; i++)
{ … }

2) В лямбда-выражениях, где имя коллекции делает переменную x очевидной:

// Это хорошая альтернатива
int max = forecasts.Max(x => x.Temperature);
// этому
int max = forecasts.Max(
 forecast => forecast.Temperature);

Практически во всех других случаях, кроме перечисленных выше, использование однобуквенных переменных вызовет недовольство ваших коллег. Если у вас цепочка выражений LINQ, данные часто изменяются по сравнению с первоначальным типом, с которого началась цепочка. В отличие от Fluent- API, где возвращаемое значение часто имеет тот же тип, что и все методы в цепочке, в LINQ возвращаются разные объекты. И типы этих объектов имеют значение. Вот не слишком сложный пример, который показывает, что даже в простых случаях было бы лучше яснее именовать переменные:

var maxTemperatures =
  allTemperatures
   .GroupBy(x => x.DayOfWeek)
   .Select(y =>
    new { 
     DayOfWeek = y.Key, 
     HighTemp = y.Max(z => z.Temperature) 
    })
   .OrderBy(o => o.HighTemp)
   .ToList();

x, y, z и o все разных типов. Даже если использовать g для группировки, есть риск, что она будет интерпретирована неверно.

Окончание следует…

Источник: https://brendoneus.com/post/Ways-Of-Making-CSharp-Harder/

День 1472. #ВредныеСоветы
11 Способов Усложнить Себе Жизнь в C#. Окончание
1-2, 3-4, 5-6, 7-8

9. Сильно вложенный код
Хотите быстрый и простой способ сделать код труднее для чтения? Вложите условные операторы друг в друга несколько раз, проверяя каждое условие отдельно вместо использования return, && или ?. и ?? для null:

if (building != null)
{
  if (building.Office != null)
  {
    if (building.Office.IsAvailable)
    {
      if (user.CanReserve)
      {
        …
      }
    }
  }
}

Вы могли бы просто написать следующее:

if (building?.Office?.IsAvailable == true 
 && user.CanReserve)
{
  …
}

Заметьте явное сравнение с true, т.к. оператор ?. возвращает bool? (Nullable<bool>), а не bool.

10. Использование интерфейса «один к одному» для класса модели
Когда люди узнают об инверсии зависимостей и моках, они бросаются в крайности, добавляя интерфейс к каждому классу независимо от того, будет ли несколько реализаций интерфейса или необходимо ли будет его мокать.

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

Проблема, если вы создаёте IStudent для ученика, ITeacher для учителя и ILesson для урока. Ни один из этих объектов, скорее всего, не нуждается в моке для тестирования, поскольку в тестах вы можете просто создать экземпляры этих моделей. Полезным может быть интерфейс вроде ISchoolMember для учащихся, учителей и администраторов, когда для всех требуется свойство SchoolID.

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

public ProcessResult Update(ChangeLog changes)
{
  #region Validate
  if (changes == null)
    throw ArgumentException(changes);

  if (…)
    throw …;
  #end region

  #region Log
  logger.Debug(changes);
  …
  #endregion

  …
}

Вместо регионов просто создайте отдельные методы для этих блоков:

public ProcessResult Update(ChangeLog changes)
{
  Validate(changes);
  Log(changes);
  …
}

Источник: https://brendoneus.com/post/Ways-Of-Making-CSharp-Harder/