День 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/

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

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

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

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

Значит ключ к тому, чтобы добиться своего, в том, чтобы не пытаться обмануть человека. Чтобы заставить партнёра задуматься над тем, что вы хотите сказать вам нужно ответить на три его вопроса:
- Ну и что?
- Какая разница?
- Что в этом для меня?

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

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

1. Задавайте стратегические вопросы.
Чем больше вы узнаете о партнёре по переговорам и его точке зрения, тем лучше вы сможете адаптировать свои аргументы. В то же время ваши вопросы помогут им задуматься над своей точкой зрения, чего они, возможно, никогда не делали:
Какая ваша самая большая проблема прямо сейчас? Почему вы так говорите?
Что мешает вам преодолеть эту трудность? Вы всегда так чувствовали? Если нет, когда это началось?

2. Предоставьте доказательства.
Разных людей убеждают разные виды доказательств. Что касается вашего партнёра, спросите себя:
К кому он обращается за вдохновением? Что читает или смотрит? Чье мнение уважает?
Используйте ответы на эти вопросы, чтобы найти поддержку своей точки зрения. Ищите данные, мнения или даже отзывы из источников, которые они, скорее всего, будут уважать. Будьте осторожны, чтобы не ошибиться в цитатах и не вырывать информацию из контекста, что подорвёт доверие к вам.
Всё это позволит вам представить доказательства таким образом, который будет более привлекательным для вашего партнёра, вместо того, чтобы тратить время на аргументы, которые он вряд ли примет во внимание.

3. Знайте, когда уступить.
В ходе обсуждения вы можете увидеть ключевые недостатки в позиции другого человека. По мере того, как вы укрепляете доверие, вы можете тактично помочь человеку рассмотреть альтернативу его нынешнему образу мыслей.
Но помните: люди эмоционально привязаны к своим убеждениям. Если вы будете безжалостно разрушать каждый аргумент партнёра, он почувствует себя атакованным. Эмоции возьмут верх, и его внимание больше не будет сосредоточено на разумном обсуждении; он будет защищаться или атаковать в ответ.
Вместо того, чтобы пытаться доминировать, сосредоточьтесь на понимании другого человека. Затем на нахождении точек соприкосновения с целью заложить основу, на которую вы сможете опираться позже. Прежде всего, постарайтесь закончить разговор на позитивной ноте.
В конце концов, иногда убеждение — это игра в долгую.
Помните, единственный, кто может изменить мнение человека, — это сам человек. Ваша задача — просто помочь ему понять, почему он должен задуматься об этом. Потому что цель всех великих мастеров убеждения — не манипулирование, не обман и даже победа в спора, а партнёрство.

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

День 1475. #ЗаметкиНаПолях
Стратегии Кэширования на Стороне Сервера. Начало
Кэширование — это технология, позволяющая хранить данные таким образом, чтобы доступ к ним был невероятно эффективным. Более быстрое чтение приводит к увеличению скорости работы приложений, поэтому почти каждое приложение, которое должно обеспечивать высокую производительность, использует какой-либо тип кэша.

Кэширование существует на разных уровнях
- Уровень клиента (например, в браузере), чтобы избежать лишних обращений к серверу: так кэшируются изображения, файлы CSS и JavaScript.
- Уровень инфраструктуры (например, CDN). CDN — эффективный способ хранения статических ресурсов: браузерам по-прежнему приходится обращаться к серверу для их загрузки, но вместо вызова «основного» приложения они вызывают CDN для получения статических ресурсов, позволяя основному приложению обрабатывать запросы, требующие динамических данных.
- Уровень приложения. Если вам нужно обслуживать данные, которые не меняются очень часто, вы можете кэшировать их, чтобы избежать лишних обращений к источнику данных, которым обычно является БД или внешний API.

Рассмотрим самые распространённые стратегии кэширования в приложении.

1. Сторонний кэш (Cache-aside): кэш и БД не взаимодействуют
Cache-aside или ленивое кэширование используется наиболее часто. Читаем из кэша; если элемент не существует, извлекаем его из источника и добавляем в кэш, чтобы в следующий раз, когда приложение попытается извлечь тот же элемент, он уже присутствовал в кэше.

Преимущества
- Отлично подходит для рабочих нагрузок с большим объёмом чтения: каждый раз, когда происходит промах кэша, вы добавляете недостающие данные в кэш, поэтому при следующей попытке доступа к тем же данным они уже будут доступны.
- Если кэш недоступен, приложение всё равно работает: вместо того, чтобы запрашивать кэш, придётся каждый раз обращаться к БД; приложение станет медленнее, но будет работать.
- Не всё должно быть в кэше: используя Cache-aside, вы храните в кэше только те данные, которые кому-то нужны.

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

2. Сквозное чтение (Read-through): кеш знает, как запрашивать БД
В кэше есть компонент, который позволяет ему обращаться к БД и извлекать недостающие данные.

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

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

Недостатки
- Единая точка отказа. Каждый раз, когда нужно получить какие-то данные, они должны пройти через кэш. Если по какой-то причине кэш недоступен, приложение не сможет получить данные.
- Тесная связь между кэшем и БД: если модель в БД изменится, мы должны обновить код запроса к БД в кэше.

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

Источник: https://www.code4it.dev/architecture-notes/caching-strategies

День 1476. #ЗаметкиНаПолях
Стратегии Кэширования на Стороне Сервера. Окончание
Начало

3. Сквозная запись (Write-through): кэш может записывать в БД СИНХРОННО
Данные сначала записываются в кэш, а затем синхронно в источник.

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

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

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

4. Отложенная запись (Write-behind): кэш может писать в БД АСИНХРОННО
Отложенная запись аналогична сквозной записи, но все операции записи в источник выполняются асинхронно.

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

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

Источник: https://www.code4it.dev/architecture-notes/caching-strategies

День 1477. #ЧтоНовенького
Проверка Орфографии Доступна в Visual Studio в Превью Версии
Visual Studio 17.5 превью 3 представляет первую предварительную версию средства проверки орфографии для файлов C#, C++ и Markdown.

Функция будет включена автоматически при работе с любым файлом C#, C++ или Markdown. Теперь, когда вы работаете с документом, поддерживаемым средством проверки орфографии, VS будет помечать любые обнаруженные слова как слова с ошибками. VS также предложит альтернативные варианты написания и поможет в исправлении, выполнив контекстное переименование, если ошибки допущены в идентификаторах. Проверку орфографии можно отключить, сняв флажок Text spell checker (Проверка орфографии в тексте) в разделе Manage Preview Features (Управление функциями в превью). Проверка орфографии также может быть включена или отключена из меню с помощью команды Edit > Advanced > Toggle Text Spell Checker (Правка > Дополнительно > Переключить Проверку Орфографии) или с помощью кнопки на главной панели инструментов в Visual Studio.

Исправить ошибки можно в панели быстрых действий, нажав Ctrl+. или Alt+Enter. Будет предложено три варианта решения. Если какой-либо из словарей предлагает варианты, Visual Studio предоставит их. Если варианты есть в нескольких словарях, предложения будут сгруппированы по словарю.
Строки и комментарии будут заменены однократно в одном месте. Исправление идентификатора в C++ или C# приведёт к рефакторингу/переименованию всех экземпляров идентификатора. Если вы выберете вариант проигнорировать ошибку, VS создаст файл excclusion.dic в вашем каталоге AppData на локальном компьютере, и это слово будет игнорироваться во всех экземплярах VS.

Поскольку C#, C++ и Markdown используют английский язык для ключевых слов, будет использован словарь “English (United States)” (en-us). Также VS возьмёт язык, используемый в Windows, и, если он отличается от “en-us”, этот словарь будет добавлен.

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

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

spelling_languages = _language_[,_language_]
(Например: = en-us,fr-fr)

Здесь будут использованы только словари en-us и fr-fr. При этом языковой пакет fr-fr должен быть установлен на компьютере пользователя, иначе любые французские слова будут помечены как орфографические ошибки.

2. Типы для проверки

spelling_checkable_types = strings,identifiers,comments
(Например: = identifiers,comments)

Определяет, что VS должна проверять. Здесь будут проверяться идентификаторы и комментарии, а строки не будут.

3. Уровень предупреждений

spelling_error_severity = error|warning|information|hint
(Например: = error)

В этом примере орфографические ошибки будут отображаться как ошибки.

4. Путь к словарю исключений

spelling_exclusion_path = абсолютный или относительный путь.
(Example: = .\exclusion.dic)

В этом примере при первом запуске средства проверки орфографии для любого файла в решении Visual Studio проверит наличие файла exclusion.dic в том же каталоге, что и файл .sln (для проекта C#), или в корневом каталоге (для каталога C++). Если файла нет, программа проверки орфографии создаст его. Всякий раз, когда пользователь решит игнорировать слово, оно будет добавлено в файл excclusion.dic. Visual Studio будет рассматривать любое слово, которое появляется в excclusion.dic, как правильно написанное. Обратите внимание, что файл должен быть в кодировке UTF16 с BOM для правильной работы.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-spell-checker-preview-now-available/

День 1478. #ЗаметкиНаПолях #DesignPatterns
Паттерн Сервис/Репозиторий
Идея паттерна заключается в том, что код верхнего уровня должен полностью игнорировать бизнес-уровень и уровень данных приложения. То есть, если вы запрашиваете заказ, ваш код должен выглядеть примерно так:

var order = orderService.GetOrder(12);

Что делает GetOrder, не важно. Это ответственность сервиса. Хотя, там может быть что-то такое (здесь и далее псевдокод):

GetSalesOrder(id) {
  var order = repo.GetOrder(id);

  if (order.HasAlert())
    notifyService.SendAlert(order.Id);

  return order;
}

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

GetSalesOrder(id) {
  var order = DB.RunSql(
    "SELECT * FROM orders WHERE id = @id", 
    id);

  var customer = DB.RunSql(
    "SELECT * FROM customers WHERE id = @CustomerId",
    order.CustomerId);

  return new Order(order, customer);
}

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

Что даёт этот паттерн? Типичный ответ: вы «можете захотеть сменить СУБД». На самом деле, это крайне маловероятно. Гораздо более вероятно, что вы захотите повторно использовать репозиторий в другом месте (возможно, из другого сервиса).

Особенности использования
1. Двойной репозиторий
Чаще всего это случается при использовании Entity Framework, который сам по себе является репозиторием. Использовать EF внутри репозитория обычно бесполезно, но бывают случаи, когда это имеет смысл. Например, если вы решили переключиться с EF на Dapper, нужно взять контекст БД, который использует сервис, и заменить его репозиторием.

2. Сквозной сервис
Рассмотрим следующий код метода сервиса:

GetSalesOrder(id) {
  return repo.GetOrder(id);
}

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

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

GetSalesOrder(id) {
  var order = repo.GetOrder(id);
  if (order.Name.StartsWith("a"))
    order.Notes = repo.GetNotes(id);
  …
  return order;
}

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

Более очевидный пример:

CreateOrder(order, orderLines) {
  repo.StartTransaction();
  repo.CreateOrder(order);
  repo.CreateOrderLines(orderLines);
  repo.CommitTransaction();    
}

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

4. Внешний доступ
Представим, что мы вызываем внешний API. Конечно, этот вызов следует рассматривать так же, как вызов базы данных (в обоих случаях используются внешние для приложения зависимости). Почему бы не создать репозиторий, который бы вызывал API и обрабатывал его ответы так же, как если бы данные извлекались из базы? Таким образом, остальная часть системы остаётся полностью независимой от источника данных, и вы сможете поменять его в любое время.

Источник: https://pmichaels.net/service-repository-pattern/

День 1479. #ProjectManagement
Организация Разработки Безопасного ПО. Начало
Каждый год университеты, колледжи и курсы выпускают новых разработчиков, которые никогда не учились безопасному программированию или безопасности приложений. Это отсутствие понимания безопасности имеет последствия для разработки ПО на трёх уровнях: отдельный разработчик, пишущий небезопасный код, команда инженеров, слепо доверяющая зависимостям, и организация, считающая, что лучше всего внедрить собственные средства безопасности.

С самого начала нас учат программировать небезопасно. Мы спрашиваем у пользователя его имя, он его вводит, мы берем эти данные и отображаем их: «Привет, <имя>». Студента не учат проверке пользовательского ввода или кодированию информации на выходе, чтобы отключить любой потенциальный код, введённый пользователем и избежать межсайтового скриптинга (XSS).

Рекомендации по написанию безопасного кода
Начнём с жизненного цикла разработки системы. Некоторые общие действия по обеспечению безопасности, которые можно добавить в него, включают:
- Требования безопасности: меры, которые необходимо принять, чтобы приложение считалось безопасным. Создаём бессерверное приложение? Вот список требований безопасности, которые нужно добавить в ТЗ проекта, чтобы убедиться, что он достаточно безопасен для размещения в сети.
- Моделирование угроз: сеанс мозгового штурма, в котором участвуют как минимум один специалист по безопасности, владелец продукта и/или представитель бизнеса, а также член технической группы. Цель состоит в том, чтобы определить как можно больше потенциальных угроз для продукта, а затем работать над устранением тех из них, которые кажутся наиболее разрушительными или опасными. Это часто делается на этапе проектирования, но это можно сделать в любой момент позже.
- Сканирование кода: на этапе написания кода можно сканировать его с помощью статического инструмента тестирования безопасности приложений (SAST) или инструмента анализа состава программного обеспечения (SCA) или отправить приложение на сервер разработки и просканировать его с помощью инструмента DAST.
- Ранний взлом: на этапе тестирования можно нанять пентестера для тщательного автоматического и ручного тестирования всей системы.
- Защита кода в рабочей среде: на этапе выпуска можно настроить мониторинг, журналирование и оповещения.

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

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

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

Источник: https://stackoverflow.blog/2023/02/09/three-layers-to-secure-a-software-development-organization

День 1480. #ProjectManagement
Организация Разработки Безопасного ПО. Окончание
Начало

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

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

Примеры нулевого доверия:
- Проверка, очистка и экранирование всех входных данных (в указанном порядке)
- Каждый API, бессерверное приложение, контейнер или сервис рассматривается как отдельный остров. Они не должны доверять друг другу!
- Аутентификация и авторизация для всех! Каждая интеграция, даже с системами, созданными и поддерживаемыми вашей командой, требует аутентификации и авторизации для каждого подключения.
- Кодировка вывода. Не доверяйте вводу пользователя или вводу, который мог быть подделан!

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

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

1. Купить
Т.к. ПО доступно немедленно, его не нужно создавать и поддерживать самостоятельно, и, скорее всего, оно было тщательнее протестировано. Хотя цена может показаться высокой, если подсчитать риск, время ожидания и долгосрочную стоимость обслуживания, почти всегда дешевле купить, чем создавать.

2. Заимствовать
Под заимствованием понимается использование открытого кода или другого кода, который вы можете использовать бесплатно, но который писали не вы. Это ПО с открытым кодом, онлайн-примеры, код от других команд, функции фреймворка и т.п. Преимущества аналогичны покупке: код доступен сразу, он бесплатный, не нужно его поддерживать самостоятельно. Однако такой код, возможно, не тестировался на безопасность, т.е. вы должны убедиться, что он безопасен, прежде чем использовать его, если это вообще возможно.

3. Создать
Если ни один из вариантов не подходит, создаём.

Это экономит деньги и время компании и снижает риски, несмотря на то что создание ПО с нуля обычно намного веселее. По возможности используйте функции безопасности, имеющиеся в вашей среде, такие как шифрование, аутентификацию и управление сеансами. Они испытаны, проверены и работают правильно! Используйте сторонние компоненты (библиотеки, пакеты и т.д.), так как они (обычно) достаточно тщательно протестированы. Проверяйте сторонний код и компоненты с помощью инструментов анализа ПО. Не пишите собственные функции безопасности, если в этом нет крайней необходимости.

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

Источник: https://stackoverflow.blog/2023/02/09/three-layers-to-secure-a-software-development-organization

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

9. Правило отказа
«Извините, мы решили вам отказать».
Эти слова задевают и причиняют боль. Хочется бросить всё и убежать. Но представьте кого-нибудь из известных вам успешных людей. Они бросят попытки после простого отказа?

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

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

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

Правило отказа простое. Оно состоит из трех частей:
1. Вы ничего не получите, если не попросите об этом, поэтому не отказывайте сами себе.

2. Если вы получили ответ «нет», спросите «почему?». Это может привести к тому, что вы получите то, что хотели, или что-то близкое к этому.

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

Итак, если вы хотите преодолеть страх быть отвергнутым и получить больше желаемого, не бегите от отказов, а пользуйтесь правилом отказа. Так вы начнёте превращать «нет» в «да». Что ещё более важно, вы навсегда измените свое отношение к отказам.

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

День 1482. #Курсы
Сегодня посоветую вам несколько отдельных вебинаров, как недавно прошедших, так и предстоящих, и вообще несколько сообществ, проводящих регулярные вебинары по теме .NET. Все перечисленные вебинары бесплатные.

1. Boston .NET Architecture Group
Проводят ежемесячные вебинары на тему архитектуры .NET приложений. Последний прошёл 15 февраля, тогда всем известный Стив “Ardalis” Смит рассказывал о чистой архитектуре в .NET 7. Недостатки этих вебинаров в том, что они проходят в 6 вечера по восточному времени США, т.е. глубокой ночью по нашему времени. Однако, на ютубе есть запись вебинара, которую может посмотреть любой желающий (правда, в отличие от настоящего вебинара, нельзя задавать вопросы).
Я посмотрел доклад Смита и должен сказать, что, несмотря на то, что я был знаком с чистой архитектурой, мне доклад очень понравился. Стив рассказывает о базовых принципах чистой архитектуры, разбирает, её преимущества и недостатки, меняет некоторые укоренившиеся представления об этом шаблоне (например, что он подходит только для больших проектов), рассказывает, как преобразовать имеющийся проект в чистую архитектуру, а также о своём шаблоне проекта чистой архитектуры и его особенностях.

2. JetBrains Webinars
Вебинары компании JetBrains по теме .NET.
Ближайший вебинар пройдёт 23 февраля 2023г в 18:00 по Москве.
Аарон Станнард – глава и основатель Petabridge (производителя Akka.NET, NBench и т.п.) – расскажет про трудности разработки .NET систем.
Что такое квант потока и почему он отличается в Windows Desktop и Windows Server? В чём разница между блокирующим вызовом и блокирующим потоком? Когда надо попытаться написать код без блокировки? Что означает ключевое слово volatile? Этот доклад поможет .NET разработчикам понять, почему их код работает так, как он работает, и что делать в сценариях, требующих высокой производительности. Вебинар можно посмотреть на YouTube.

3. Joberty Webinars
Сообщество разработчиков, на вебинарах которого выступают известные люди в мире .NET.
Ближайший вебинар пройдёт практически сразу по окончании предыдущего, 23 февраля 2023г в 20:00 по Москве. Милан Джованович расскажет о модульных монолитах. Почему монолитные приложения могут быть гибкими и расширяемыми? Почему не обязательно сразу начинать с микросервисов? Какие возможности даёт модульный монолит? Как их создавать и какие уроки он лично извлёк на своей практике? Регистрация на сайте.

День 1483. #ЗаметкиНаПолях
Обнаружение Критических Изменений Между Версиями NuGet-пакета
NuGet-пакеты можно не только добавлять в свои проекты, но и создавать самим. Не обязательно при этом размещать их публично. Они могут использоваться, например, как общие библиотеки при обмене кодом между командами.

Начиная с .NET 6, пакет SDK для .NET предоставляет новую функцию под названием Package Validation (Проверка пакетов), которая позволяет авторам NuGet-пакетов проверять несколько аспектов своих пакетов. Эта функция не включена по умолчанию, поэтому вы должны включить её, добавив свойство EnablePackageValidation в файл проекта:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
  <TargetFramework>
    net6.0
  </TargetFramework>
  <PackageVersion>
    2.0.0
  </PackageVersion>
  <EnablePackageValidation>
    true
  </EnablePackageValidation>
  <PackageValidationBaselineVersion>
    1.0.0
   </PackageValidationBaselineVersion>
   <PackageValidationBaselinePath>
    path_to_nupkg\MyLibrary.1.0.0.nupkg
   </PackageValidationBaselinePath>
 </PropertyGroup>
</Project>

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

При сборке пакета с помощью dotnet pack SDK .NET сообщит об ошибках после сборки пакета. Например, если вы добавите к классу модификатор sealed, .SDK сообщит об ошибке: CP0009: Type 'MyLibrary.Class1' has the sealed modifier on lib/net7.0/MyLibrary.dll but not on [Baseline] lib/net7.0/MyLibrary.dll. (Тип 'MyLibrary.Class1' имеет модификатор sealed в lib/net7.0/MyLibrary.dll, но не в базовой версии lib/net7.0/MyLibrary.dll).

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

<PropertyGroup>
 <GenerateCompatibilitySuppressionFile>
  true
 </GenerateCompatibilitySuppressionFile>
 <CompatibilitySuppressionFilePath>
  ApiCompatSuppressions.xml
 </CompatibilitySuppressionFilePath>
</PropertyGroup>

Источник: https://www.meziantou.net/detecting-breaking-changes-between-two-versions-of-a-nuget-package-at-packaging.htm

День 1484. #ЧтоНовенького
Улучшенный ИИ и Новые Возможности GitHub Copilot
С момента запуска GitHub Copilot идёт работа над улучшением качества и скорости отклика его предложений. Также разработан новый фильтр уязвимостей безопасности, чтобы сделать код, предлагаемый Copilot, более безопасным и помочь разработчикам выявлять небезопасные шаблоны кода во время работы.

Более мощная модель ИИ и лучшие предложения кода
Чтобы улучшить качество предложений кода, обновлена базовая модель Codex, что привело к значительному улучшению качества предложений и сокращению времени их предоставления. С момента старта в июле 2022 года общая доля принятых предложений кода Copilot выросла с 27% до 35%.

Вот основные технические усовершенствования:
- Обновлённая модель OpenAI Codex, которая обеспечивает лучшие результаты для синтеза кода.

- Лучшее понимание контекста: новая парадигма под названием Fill-In-the-Middle (FIM) предлагает разработчикам более эффективные предложения кода. Вместо того, чтобы рассматривать только предшествующий код, она также использует последующий код и заполняет промежуток. Таким образом у Copilot появляется больше контекста о вашем предполагаемом коде и о том, как он должен согласовываться с остальной частью вашей программы.

- Облегчённая модель на стороне клиента: обновлено расширение Copilot для VS Code, добавлена упрощённая модель на стороне клиента, которая улучшила общий уровень принятия предложений по коду. Для этого Copilot теперь использует базовую информацию о контексте пользователя — например, было ли принято последнее предложение — чтобы уменьшить частоту нежелательных предложений. Это привело к сокращению нежелательных предложений на 4,5%. Во второй улучшенной итерации этой модели на стороне клиента, выпущенной в январе 2023 года, заметны ещё большие улучшения в показателе принятия предложений кода.

Фильтрация уязвимостей безопасности с помощью новой системы ИИ
Запущена система предотвращения уязвимостей на основе ИИ, которая блокирует небезопасные шаблоны кодирования в режиме реального времени, чтобы сделать предложения Copilot более безопасными. Модель нацелена на наиболее распространённые уязвимые шаблоны кода, включая жёстко закодированные учетные данные, SQL-инъекции и инъекции пути.

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

Этот механизм - это первый важный шаг, который поможет разработчикам создавать более безопасный код с помощью GitHub Copilot.

Итого
Усовершенствованная модель ИИ, улучшенные предложения кода, улучшенная скорость отклика и повышенная безопасность — все эти улучшения теперь доступны разработчикам, использующим Copilot как для индивидуального пользования, так и для бизнеса.

Источник: https://github.blog/2023-02-14-github-copilot-now-has-a-better-ai-model-and-new-capabilities/

День 1485. #ЗаметкиНаПолях
Особенность (Производительности) JsonSerializer
System.Text.Json.JsonSerializer имеет странную особенность в отношении производительности и управления памятью. Посмотрим, что «не так» с этим кодом:

JsonSerializer.Serialize(myObject, 
 new JsonSerializerOptions(...));.

JsonSerializerOptions используется для настройки сериализации и десериализации объектов. Он имеет несколько свойств, которые описывают, например, хотите ли вы иметь отступы в JSON. Теперь небольшой бенчмарк:

public record Test(string FirstName, string LastName);

[MemoryDiagnoser]
public class JsonBenchmark
{
  private static readonly 
   JsonSerializerOptions _options = new();

  public void Default()
  {
    for (var i = 0; i < 100; i++)
      JsonSerializer.Serialize(
       new Test("Steven", "Giesel"));
  }

  [Benchmark]
  public void OptionsField()
  {
    for (var i = 0; i < 100; i++)
      JsonSerializer.Serialize(
       new Test("Steven", "Giesel"), _options);
  }

  [Benchmark]
  public void OptionsNew()
  {
    for (var i = 0; i < 100; i++)
      JsonSerializer.Serialize(
       new Test("Steven", "Giesel"), 
       new JsonSerializerOptions());
  }
}

Итак, у нас 3 метода. Один без опций, второй использует статическое поле, а третий – каждый раз вызывает new(). Результаты:

| Method       |  Mean    | Allocated | 
|--------------|----------|-----------|
| Default      | 13.89 us | 14.06 KB  |
| OptionsField | 13.89 us | 14.06 KB  |
| OptionsNew   | 53.36 us | 42.79 KB  |

Мы видим, что создание нового экземпляра в цикле - это дорого. Очевидно, что new() требует времени и памяти. Да, но не настолько. На самом деле, если параметры не установлены, используется экземпляр по умолчанию. При передаче параметров сериализатор вызывает функцию InitializeForReflectionSerializer. Она довольно дорогая, поскольку собирает необходимую информацию о том, как выглядит ваш объект с помощью рефлексии. Если мы используем статическое поле, экземпляр инициализируется один раз, а дальше будет кэширован. При использовании new() InitializeForReflectionSerializer вызывается каждый раз.

И что?
Если вы вызываете сериализацию/десериализацию нечасто, ничего страшного. Но вы можете использовать её в Entity Framework в сочетании с ValueConverter:

protected override void OnModelCreating(ModelBuilder mb)
{
  mb
   .Entity<MyModel>()
   .Property(e => e.MyList)
   .HasConversion(
    v => JsonSerializer
     .Serialize(v, new JsonSerializerOptions(…)),
    v => JsonSerializer
     .Deserialize<List<MyType>>(
      v, new JsonSerializerOptions(…)));
}

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

Источник: https://steven-giesel.com/blogPost/0e7512b0-c854-4cce-8606-765fcaf1e69c

День 1486. #Testing
Ода Юнит-Тестам: в Защиту Пирамиды Тестирования. Начало
В 2014 году Дэвид Хайнемайер Ханссон взорвал мир разработки, когда на RailsConf заявил, что «TDD — это смерть». Многие последовали за ним, разделив разработчиков на два лагеря. Сегодня модульные тесты теряют своё значение в пользу интеграционных тестов, и пирамида тестирования превратилась в ромб, где главную роль теперь играют интеграционные тесты.

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

Следующие вопросы могут помочь избежать ощущения необходимости в Тестовом Ромбе вместо Пирамиды:
- Эта проблема вызвана юнит-тестами или тем, как я их пишу?
- Применяю ли я интеграционные тесты к компонентам, которые в нём нуждаются?
- Я что-то неправильно понял, что привело меня к одним и тем же утверждениям в нескольких местах?
- Улучшаю ли я свой дизайн с помощью тестов или просто тестирую существующий дизайн?

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

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

Поведенческое тестирование
Что означает модуль в модульных тестах? Это единица поведения. Т.е. тест не должен быть сосредоточен на одном файле, объекте или функции. Почему сложно писать модульные тесты, ориентированные на поведение?

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

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

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

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

Источник: https://www.infoq.com/articles/unit-tests-testing-pyramid/

День 1487. #Testing
Ода Юнит-Тестам: в Защиту Пирамиды Тестирования. Окончание
Начало

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

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

Уменьшите публичность вашего кода
Ещё один побочный эффект тестирования методом белого ящика в том, что оно приводит к раскрытию большего количества кода, чем необходимо. Валидаторы, мапперв и другие фрагменты кода, которые могут быть деталями внутренней реализации, теперь являются частью публичного контракта только потому, что мы предоставили их для тестирования. Кроме того, любой, кто работает в мире Java и C#, знает, насколько распространены интерфейсы в их кодовых базах. Опять же, ради тестов. Разработчик может ввести интерфейс, только чтобы имитировать зависимость в тестах.

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

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

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

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

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

Источник: https://www.infoq.com/articles/unit-tests-testing-pyramid/

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

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

Капитан Чесли Салленбергер («Салли») 15 января 2009 г. Выполнял обычный рейс из Нью-Йорка в Шарлотт. Но всего через несколько минут полёта стая гусей столкнулась с самолетом, выведя из строя оба двигателя. Большинство людей запаниковало бы. А Салли нет. Через 208 секунд после столкновения с птицами Салленбергер благополучно посадил самолет в реку Гудзон. Все выжили, а это событие теперь известно как «Чудо на Гудзоне». Несомненно, Салленбергер и команда чувствовали страх, но не паниковали.

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

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

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

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

Всё сводится к подготовке. Так же, как пилоты хорошо подготовлены к потенциальной катастрофе, вы можете практиковать методы, необходимые для того, чтобы держать свои эмоции под контролем:
- Правило концентрации: если вы заметили признаки паники или аврала в рабочих задачах, остановитесь.
- Правило приоритета: сосредоточьтесь на главном. Выберите два или три первоочередных дела, которые нужно сделать срочно. Затем выберите из них самое срочное, а остальные отложите.
- Правило критического мышления: не спешите. Критическое мышление требует терпения, а также способности понимать свои эмоции и удерживать их в равновесии. Не позволяйте временным эмоциям склонить вас к принятию постоянных решений, о которых вы потом пожалеете.
- Правило неловкого молчания: столкнувшись со сложным вопросом, вместо немедленного ответа сделаете паузу и глубоко подумаете о том, как вы хотите ответить. Вы можете подождать 5, 10 или даже 15 секунд, прежде чем дать ответ. Если вы не привыкли так делать, поначалу будет неловко.

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

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

День 1489. #ЗаметкиНаПолях
Какой Интерфейс Коллекции Использовать? Начало
В этой серии постов о том, когда использовать какой тип коллекции и почему.

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

Использование типов коллекций (и их интерфейсов) также должно соответствовать этому правилу. Вы также должны возвращать наиболее конкретный и принимать наиболее общий тип коллекции.
Вот упрощённая иерархия интерфейсов коллекций в .NET:

IEnumerable<T>
└- IQueryable<T>
└- IReadOnlyCollection<T>
|  └- IReadonlyList<T>
└- ICollection<T>
   └- Array
   └- IList<T>

По рекомендации нужно возвращать самый конкретный тип. В этом иерархическом дереве есть несколько листьев:
- IQueryable
- IList
- Array
- IReadOnlyList

1. IQueryable — дырявая абстракция
Этот интерфейс позволяет запрашивать базу данных с помощью выражений LINQ так же, как коллекцию в памяти. Разница в том, что выражения LINQ, которые работают с IQueryable, выполняются в БД, а не в памяти. ORM, такие как EF Core и NHibernate, реализуют провайдера IQueryable, который преобразует выражения LINQ в запросы SQL. IQueryable можно рассматривать как абстракцию, позволяющую одинаково работать с разными источниками данных.

IQueryable особенно популярен в репозиториях, где вы можете ввести метод GetAll, например:

// Student repository
public IQueryable<Student> GetAll() =>
  _context.Set<Student>();

А затем добавлять фильтры в клиентском коде.

Такой подход на первый взгляд кажется логичным. Клиентский код может строить фильтры поверх IQueryable в зависимости от сценария. Но IQueryable является дырявой абстракцией, которая требует от вас знания деталей реализации, которые она должна абстрагировать. Вы должны знать, какие выражения LINQ могут быть преобразованы в SQL, а какие нет. Таким образом, использование IQueryable как части общедоступного API вводит в заблуждение. Создаётся ложное впечатление, что вы можете применить любое выражение поверх этого возвращаемого значения.

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

public IQueryable<Student> GetAll(
 Expression<Func<Student, bool>> predicate) =>
  _context.Set<Student>().Where(predicate);

Решение состоит в том, чтобы не использовать IQueryable (или выражения) как часть общедоступного API репозитория. Вы можете использовать его внутри, потому что репозиторий знает, с каким ORM он работает и его ограничения. Но эти знания не должны пересекать границы репозитория, т.е. не должны утекать к клиентам репозитория.

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

Источник: https://enterprisecraftsmanship.com/posts/which-collection-interface-to-use/