День 1174. #ЗаметкиНаПолях #AsyncTips
Неизменяемые множества
Задача: нужна структура данных, не рассчитанная на хранение дубликатов, которая не слишком часто изменяется и допускает безопасные обращения из нескольких потоков. Например, индекс слов из файла может быть хорошим кандидатом для применения множества.
Решение
Существует два типа неизменяемых множеств:
Рекомендую использовать несортированное множество, если только вы не уверены в том, что оно должно быть отсортированным. Это позволит использовать неизменяемое множество в большем количестве ситуаций.
Неизменяемые множества полезны, но заполнение большого неизменяемого множества может быть медленной операцией. У многих неизменяемых коллекций имеются специальные построители, которые могут использоваться для быстрого их построения в изменяемом виде с последующим преобразованием в неизменяемую коллекцию. Это относится ко многим неизменяемым коллекциям, но, на мой взгляд, они особенно полезны для неизменяемых множеств.
См. также:
- Неизменяемые стеки и очереди
- Неизменяемые списки
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
Неизменяемые множества
Задача: нужна структура данных, не рассчитанная на хранение дубликатов, которая не слишком часто изменяется и допускает безопасные обращения из нескольких потоков. Например, индекс слов из файла может быть хорошим кандидатом для применения множества.
Решение
Существует два типа неизменяемых множеств:
ImmutableHashSet<T>
— коллекция уникальных элементов и ImmutableSortedSet<T>
— отсортированная коллекция уникальных элементов. Эти типы из пространства имён System.Collections.Immutable
обладают похожим интерфейсом:var hs = ImmutableHashSet<int>.Empty;Отсортированное множество допускает индексирование по аналогии со списком:
hs = hs.Add(13);
hs = hs.Add(7);
// Выводит "7" и "13" в непредсказуемом порядке
foreach (int item in hs)
Console.WriteLine(item);
hs = hs.Remove(7);
var shs = ImmutableSortedSet<int>.Empty;Несортированные и отсортированные множества обладают схожим быстродействием: O(log N) для добавления, удаления. Важное примечание: обращение по индексу в сортированном множестве также выполняется за время O(log N), а не O(1), как и у
shs = shs.Add(13);
shs = shs.Add(7);
// Выводит "7", затем "13"
foreach (int item in shs)
Console.WriteLine(item);
int smallest = shs[0]; // 7
shs = shs.Remove(7);
ImmutableList<T>
. Это означает, что в данной ситуации действует та же рекомендация: используйте foreach
вместо for
там, где это возможно.Рекомендую использовать несортированное множество, если только вы не уверены в том, что оно должно быть отсортированным. Это позволит использовать неизменяемое множество в большем количестве ситуаций.
Неизменяемые множества полезны, но заполнение большого неизменяемого множества может быть медленной операцией. У многих неизменяемых коллекций имеются специальные построители, которые могут использоваться для быстрого их построения в изменяемом виде с последующим преобразованием в неизменяемую коллекцию. Это относится ко многим неизменяемым коллекциям, но, на мой взгляд, они особенно полезны для неизменяемых множеств.
См. также:
- Неизменяемые стеки и очереди
- Неизменяемые списки
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
👍2
День 1175. #Юмор
Сегодня порекомендую вам юморное видео «HR x IT» от makelove agency. Это пилотное видео из серии «Мы вас перезвоним», в котором ребята сталкивают лбами разных представителей айтишечки. И они сразу решили зайти с козырей. HR против разработчика. Их претензии друг другу и разбор самых распространённых мифов об их профессиях. Некоторые требования айтишников даже меня удивили)))
В комментариях на девушку HRа накинулись за грубость 18+, но лично мне показалось, она вполне соответствовала образу.
В общем, веселый дружеский срачик. Мне понравилось.
https://youtu.be/Yyp4VVPylLg
Сегодня порекомендую вам юморное видео «HR x IT» от makelove agency. Это пилотное видео из серии «Мы вас перезвоним», в котором ребята сталкивают лбами разных представителей айтишечки. И они сразу решили зайти с козырей. HR против разработчика. Их претензии друг другу и разбор самых распространённых мифов об их профессиях. Некоторые требования айтишников даже меня удивили)))
В комментариях на девушку HRа накинулись за грубость 18+, но лично мне показалось, она вполне соответствовала образу.
В общем, веселый дружеский срачик. Мне понравилось.
https://youtu.be/Yyp4VVPylLg
👍6
День 1176. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Начало
REST и GraphQL — это стандартные способы разработки серверных API. В последнее десятилетие REST API доминировали, и многие компании и разработчики активно используют его в своих проектах.
Но у REST есть некоторые ограничения, и есть другая доступная альтернатива — GraphQL.
GraphQL был разработан Facebook в 2012 году для внутреннего использования и обнародован в 2015 году. Это язык запросов для API и среда исполнения для выполнения этих запросов к вашим существующим данным. Цитата с официального сайта:
«GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, и ничего больше, упрощает развитие API с течением времени и предоставляет мощные инструменты разработчика.»
Проблемы с REST API
1. Запрос нескольких конечных точек
2. Получение лишних данных
3. Неполная выборка и проблема n+1 запроса
4. Медленный отклик на меняющиеся требованиями клиента
5. Высокая связанность между внутренними контроллерами и внешними представлениями
Предположим, что нам нужно показать краткую информацию о пользователе: имя, должность и текст «о себе». С REST запрос будет GET по адресу /users/1. Проблема в том, что сервер возвращает фиксированную структуру данных с множеством ненужной информации. Например:
GraphQL позволяет отправить запрос только нужных данных, который будет выглядеть примерно так:
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
GraphQL или REST API. Что Использовать? Начало
REST и GraphQL — это стандартные способы разработки серверных API. В последнее десятилетие REST API доминировали, и многие компании и разработчики активно используют его в своих проектах.
Но у REST есть некоторые ограничения, и есть другая доступная альтернатива — GraphQL.
GraphQL был разработан Facebook в 2012 году для внутреннего использования и обнародован в 2015 году. Это язык запросов для API и среда исполнения для выполнения этих запросов к вашим существующим данным. Цитата с официального сайта:
«GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, и ничего больше, упрощает развитие API с течением времени и предоставляет мощные инструменты разработчика.»
Проблемы с REST API
1. Запрос нескольких конечных точек
2. Получение лишних данных
3. Неполная выборка и проблема n+1 запроса
4. Медленный отклик на меняющиеся требованиями клиента
5. Высокая связанность между внутренними контроллерами и внешними представлениями
Предположим, что нам нужно показать краткую информацию о пользователе: имя, должность и текст «о себе». С REST запрос будет GET по адресу /users/1. Проблема в том, что сервер возвращает фиксированную структуру данных с множеством ненужной информации. Например:
{Это добавляет в каждый запрос дополнительные данные, которые не требуются клиенту, что увеличивает размер полезной нагрузки и влияет на общее время ответа на запрос. Ещё хуже, если данные выбираются из нескольких таблиц, даже если клиенту этого не нужно.
"id": 1,
"name": "John Smith",
"username": "jsmith",
"email": "[email protected]",
"title": "Software Engineer",
"phone": "9876543210",
"about": "As a software engineer my daily routine revolves around writing cleancode, maintaining infrastructure, and building scalable software systems.",
"website": "https://www.jsmith.tech",
"gender": "MALE",
"city": "Denver",
"state": "Colorado",
"country": "US",
…
}
GraphQL позволяет отправить запрос только нужных данных, который будет выглядеть примерно так:
{Окончание следует…
user(id: 1){
name
title
about
}
}
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
👍11
День 1177. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Окончание
Начало
Теперь предположим, что нам нужно отобразить в списке имена пользователей и их «опыт» на текущем месте работы. В REST, учитывая, что «опыт» - это таблица с внешним ключом
1) Создать структуру со всеми внешними связями таблицы
2) Делать несколько запросов на сервер:
С другой стороны, простой запрос GraphQL будет без проблем работать без каких-либо дополнительных изменений на стороне сервера. Запрос будет выглядеть примерно так:
Например, по прошествии времени в списке потребовалось выводить не опыт, а последнюю транзакцию пользователя. С REST нужно будет внести соответствующие изменения в представление, но также придётся изменить и контроллер (добавить метод), и путь. То есть изменение требований клиента сильно влияет на то, что должно быть возвращено сервером.
С GraphQL нам не нужно будет вносить какие-либо изменения на стороне сервера. Изменение внешнего запроса будет минимальным:
Итого
GraphQL имеет ряд преимуществ перед REST во многих областях. Первоначальная настройка GraphQL может занять больше времени, но существует множество скаффолдеров, которые облегчают эту работу. И даже если поначалу это займет больше времени, это даст вам преимущество в долгосрочной перспективе.
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
GraphQL или REST API. Что Использовать? Окончание
Начало
Теперь предположим, что нам нужно отобразить в списке имена пользователей и их «опыт» на текущем месте работы. В REST, учитывая, что «опыт» - это таблица с внешним ключом
user_id
, есть три возможных варианта:1) Создать структуру со всеми внешними связями таблицы
users
и получать все данные в неё. Но это приведёт к очень дорогостоящим запросам и возвращает много данных из всех внешних таблиц, которые в большинстве случаев не требуются.2) Делать несколько запросов на сервер:
GET /usersЭто пример неполной выборки, так как у одной конечной точки недостаточно данных. Но множественные сетевые вызовы замедляют процесс и влияют на работу пользователя. Кроме того, в случае списка неполная выборка усугубляется тем, что нам нужно сделать запрос опыта для каждого пользователя в списке, и мы сталкиваемся с проблемой n+1 запроса.
GET users/1/experience
GET /users3) Создать специальный контроллер, который возвращает структуру данных, соответствующую требованиям клиента на данный момент времени.
GET users/1/experience
GET users/2/experience
…
GET users/n/experience
GET /user-experienceЭто и делается в большинстве реальных случаев в REST API.
С другой стороны, простой запрос GraphQL будет без проблем работать без каких-либо дополнительных изменений на стороне сервера. Запрос будет выглядеть примерно так:
{Да, можно использовать REST, создавать контроллеры (методы) под требования клиента. Но есть большой недостаток. Мы сформировали тесную связь клиентского представления с внутренними контроллерами API, поэтому потребуется больше усилий, чтобы обрабатывать запросы клиентов. Пользовательский контроллер возвращает данные в зависимости от того, что хочет отобразить представление, поэтому, когда требования изменятся, придётся менять как представление, так и контроллер.
users{
name
experience{
organization
title
duration
}
}
}
Например, по прошествии времени в списке потребовалось выводить не опыт, а последнюю транзакцию пользователя. С REST нужно будет внести соответствующие изменения в представление, но также придётся изменить и контроллер (добавить метод), и путь. То есть изменение требований клиента сильно влияет на то, что должно быть возвращено сервером.
С GraphQL нам не нужно будет вносить какие-либо изменения на стороне сервера. Изменение внешнего запроса будет минимальным:
{Никакого рефакторинга серверного API, развертывания и тестирования — это означает экономию времени и усилий!
users{
name
transactions{
amount
type
}
}
}
Итого
GraphQL имеет ряд преимуществ перед REST во многих областях. Первоначальная настройка GraphQL может занять больше времени, но существует множество скаффолдеров, которые облегчают эту работу. И даже если поначалу это займет больше времени, это даст вам преимущество в долгосрочной перспективе.
Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/
👍13
День 1178. #Юмор
Вытащу на пятничную болталку очередной твит. Kim Maida предложила следующее задание:
«Расскажите, сколько вам лет в «годах разработчика» одним предложением, не называя фактической цифры.»
Вот некоторые ответы:
«Разработчики на jQuery не *настоящие* JavaScript разработчики»
«Поддержка IE6»
«Использовал картинки с четвертью круга для скругления углов таблиц»
«Моих нынешней и предыдущей профессий не существовало»
«Начинал в классическом ASP, когда он ещё был просто ASP»
«autoexec.bat»
«Javascript поддерживается только в Netscape Navigator»
«Пожалуйста, не используй телефон, у меня загружается огромный файл в 50Мб»
«Знаешь, через пару лет эти двузначные года станут реальной проблемой для наших систем.»
«Не используй mov, просто сделай XOR регистра с самим собой, это сэкономит память»
«Через несколько лет после того, как я начал программировать, я перешёл с кассет на флоппи-диски. Они намного быстрее!»
«Писал программы с помощью карандаша и бумаги, а затем создавал перфокарты и отправлял их в университет. Если программа компилировалась и запускалась, я получал результат примерно через неделю.»
Добавлю от себя:
«Самые современные компьютеры на корпусе, помимо кнопки включения, имели кнопки Reset и Turbo»
Оставляйте ваши варианты в комментариях.
Источник: https://twitter.com/KimMaida/status/1514652490683367438
Вытащу на пятничную болталку очередной твит. Kim Maida предложила следующее задание:
«Расскажите, сколько вам лет в «годах разработчика» одним предложением, не называя фактической цифры.»
Вот некоторые ответы:
«Разработчики на jQuery не *настоящие* JavaScript разработчики»
«Поддержка IE6»
«Использовал картинки с четвертью круга для скругления углов таблиц»
«Моих нынешней и предыдущей профессий не существовало»
«Начинал в классическом ASP, когда он ещё был просто ASP»
«autoexec.bat»
«Javascript поддерживается только в Netscape Navigator»
«Пожалуйста, не используй телефон, у меня загружается огромный файл в 50Мб»
«Знаешь, через пару лет эти двузначные года станут реальной проблемой для наших систем.»
«Не используй mov, просто сделай XOR регистра с самим собой, это сэкономит память»
«Через несколько лет после того, как я начал программировать, я перешёл с кассет на флоппи-диски. Они намного быстрее!»
«Писал программы с помощью карандаша и бумаги, а затем создавал перфокарты и отправлял их в университет. Если программа компилировалась и запускалась, я получал результат примерно через неделю.»
Добавлю от себя:
«Самые современные компьютеры на корпусе, помимо кнопки включения, имели кнопки Reset и Turbo»
Оставляйте ваши варианты в комментариях.
Источник: https://twitter.com/KimMaida/status/1514652490683367438
👍13
День 1179. #ЗаметкиНаПолях
Выделяем Подмассивы. Начало
Сегодня рассмотрим, различные способы выделения подмассива в C#.
Подмассив обычно определяется начальным индексом и количеством элементов, включаемых в него. В общем случае существует два логических способа это сделать:
- Создать новый массив и добавить к нему необходимые элементы.
- Создать оболочку вокруг массива, которая может содержать указатели на определенные элементы внутри массива без создания нового.
Допустим, у нас есть массив строк:
В LINQ есть методы
2. Использование метода Copy()
Тот же сценарий, но помощью метода массива
3. Оператор диапазона (x..y) в C# 8.0+
Начиная с C#8 появился новый оператор диапазона, который сделал выделение подмассива синтаксически очень простым. Он позволяет выделить элементы между индексом «x» и индексом «y», не включая элемент с индексом «y»:
Окончание следует…
Источник: https://code-maze.com/csharp-array-slicing/
Выделяем Подмассивы. Начало
Сегодня рассмотрим, различные способы выделения подмассива в C#.
Подмассив обычно определяется начальным индексом и количеством элементов, включаемых в него. В общем случае существует два логических способа это сделать:
- Создать новый массив и добавить к нему необходимые элементы.
- Создать оболочку вокруг массива, которая может содержать указатели на определенные элементы внутри массива без создания нового.
Допустим, у нас есть массив строк:
var posts = new string[] { "post1", "post2", "post3", "post4", "post5", "post6", "post7", "post8", "post9", "post10" };1. Использование LINQ
В LINQ есть методы
Skip()
и Take()
:var sliced = posts.Skip(0).Take(5);Мы передаем количество элементов, которые хотим пропустить, методу
// Элементы с post1 до post5
Skip()
- начальный индекс, и количество элементов, которые хотим включить, в метод Take()
. Операция возвращает новый IEnumerable
, который мы можем перечислить.2. Использование метода Copy()
Тот же сценарий, но помощью метода массива
Copy()
:var sliced = new string[5];Здесь мы инициализируем целевой массив, затем мы вызываем метод
Array.Copy(posts, 0, sliced, 0, 5);
Copy()
, который принимает исходный массив, начальный индекс, целевой массив, начальный целевой индекс (ноль, потому что мы копируем в новый массив) и количество элементов, которые мы хотим скопировать. Метод возвращает новый массив, содержащий скопированные элементы.3. Оператор диапазона (x..y) в C# 8.0+
Начиная с C#8 появился новый оператор диапазона, который сделал выделение подмассива синтаксически очень простым. Он позволяет выделить элементы между индексом «x» и индексом «y», не включая элемент с индексом «y»:
var s1 = posts[2..]; // co 2го до концаОператор диапазона также выделяет новый массив.
var s2 = posts[..2]; // с начала до 1го
var s3 = posts[1..3]; // с 1го до 2го
var s4 = posts[..]; // весь массив
var s5 = posts[3..^0]; // с 3го до предпоследнего
Окончание следует…
Источник: https://code-maze.com/csharp-array-slicing/
👍21
День 1180. #ЗаметкиНаПолях
Выделяем Подмассивы. Окончание
Начало
Теперь рассмотрим второй способ.
Для него рассмотрим новый сценарий. Допустим, мы создаем модель машинного обучения для благотворительной организации, которая будет предсказывать, сделает ли человек донат, в зависимости от его возраста. У нас есть куча данных, которые мы хотим разбить на две секции: обучающие данные, на которых будет обучаться модель, и тестовые данные, по которым мы будем тестировать модель.
4. Использование ArraySegment<T>
То же самое можно сделать с помощью метода
Замечание: мы должны быть осторожны, потому что это не новый массив, это на самом деле переменная типа-значения, содержащая указатели на позиции элементов в массиве, поэтому любое изменение значений в сегменте массива будет отражаться в исходном массиве.
5. Использование ReadOnlySpan<T> и Span<T>
Код, использующий
Сравнение быстродействия
На массиве из 10 строк быстродействие выделения подмассива из 5 элементов и их перечисления. Общий вид методов:
Источник: https://code-maze.com/csharp-array-slicing/
Выделяем Подмассивы. Окончание
Начало
Теперь рассмотрим второй способ.
Для него рассмотрим новый сценарий. Допустим, мы создаем модель машинного обучения для благотворительной организации, которая будет предсказывать, сделает ли человек донат, в зависимости от его возраста. У нас есть куча данных, которые мы хотим разбить на две секции: обучающие данные, на которых будет обучаться модель, и тестовые данные, по которым мы будем тестировать модель.
var data = new (int, bool)[] {Заметьте, что в примере у нас всего 5 элементов. В реальной же модели обучения их могут быть миллионы, поэтому выделять новый массив будет очень затратно.
(20, true),
(50, true),
(35, false),
(55, true),
(16, false)
};
4. Использование ArraySegment<T>
var train = new ArraySegment<(int, bool)>(data, 0, 3);Мы инициализируем новый экземпляр
var test = new ArraySegment<(int, bool)>(data, 3, 2);
ArraySegment
, передавая массив, который мы хотим разделить, начальный индекс и количество элементов. Это создает оболочку вокруг массива, которая ограничивает элементы между указанными позициями. Теперь мы можем выполнить итерацию по этому сегменту и прочитать его значения.То же самое можно сделать с помощью метода
ArraySegment<T>.Slice()
:var all = new ArraySegment<(int, bool)>(data);Мы создаем
var train = all.Slice(0, 3);
var test = all.Slice(3, 2);
ArraySegment
, который охватывает весь массив, затем вызываем метод Slice()
, который создает ещё один ArraySegment с указанными границами.Замечание: мы должны быть осторожны, потому что это не новый массив, это на самом деле переменная типа-значения, содержащая указатели на позиции элементов в массиве, поэтому любое изменение значений в сегменте массива будет отражаться в исходном массиве.
5. Использование ReadOnlySpan<T> и Span<T>
ReadOnlySpan<T>
предоставляет оболочку, которая позволяет только чтение из массива:var train = new ReadOnlySpan<(int, bool)>(data, 0, 3);
var test = new ReadOnlySpan<(int, bool)>(data, 3, 2);
ReadOnlySpan
очень похож на ArraySegment
. Он принимает массив, начальный индекс и количество элементов. Мы можем перечислить его, но, если мы попытаемся изменить какой-либо элемент через экземпляр ReadOnlySpan
, мы получим ошибку компиляции.Код, использующий
Span<T>
и его поведение аналогичны коду с ArraySegment<T>
. Их отличие в том, что Span<T>
можно использовать не только для массивов. Кроме того, ArraySegment<T>
реализует IEnumerable<T>
таким образом позволяет вернуть результат как IEnumerable<T>
, тогда как ReadOnlySpan<T>
и Span<T>
возвращают соответствующие типы, хотя оба имеют метод GetEnumerator()
, поэтому их также можно перечислить через foreach
.Сравнение быстродействия
На массиве из 10 строк быстродействие выделения подмассива из 5 элементов и их перечисления. Общий вид методов:
public int <Метод>()Результаты на картинке ниже.
{
// получение подмассива указанным методом
var slice = <подмассив>;
var cnt = 0;
foreach (var item in slice)
cnt++;
return cnt;
}
Источник: https://code-maze.com/csharp-array-slicing/
👍10
День 1181. #МоиИнструменты
Visual Studio 2022 Tweaks
Сегодня порекомендую вам расширение для Visual Studio 2022 от Мэдса Кристенсена Tweaks 2022. Оно содержит в себе множество мелких, но полезных улучшений (на основании предложений пользователей). Они упростят для вас те мелкие ненужные действия, которые нам приходится делать постоянно в повседневной работе. Подробное их описание ищите на странице расширения).
Стоит оговориться, что большинство из этого уже существует и это можно найти, покопавшись в настройках. Расширение позволяет сделать это быстро.
1. Общие
- Автоматическое сохранение документа, когда он теряет фокус. Также проект автоматически сохраняется при добавлении, удалении или переименовании файлов.
- Закрытие документа по
- Автоматический фокус на обозревателе решений после загрузки проекта (даже если он был скрыт).
- Пункт меню для очистки недавно открытых документов.
- Пункт всплывающего меню «Открыть сбоку» для файлов в обозревателе решений (открывает файл справа от текущего документа).
- Пункт всплывающего меню «Найти в обозревателе решений» для вкладок.
2. IDE
- Перезапуск VS в меню Файл (также возможно по
- Варианты запуска VS в безопасном режиме и в режиме презентации (доступны в выпадающем меню при правом клике на ярлыке VS).
- Отключение кнопок отладки
3. Сборка
- Выпадающий список уровня подробности сообщений сборки в окне Output.
- Сохранение решения при сборке.
- Удаление папок
- Отображение времени запуска и длительности сборки.
- Отображение актуальности файлов проекта (полезно знать, чтобы выяснить, почему проект пересобирается). Отображается даже на минимальном уровне подробностей в окне Output.
- Отображение порядка сборки проектов
4. Редактор
- Очистка кода при форматировании документа (
- Отмена копирования пустых строк. По умолчанию при нажатии
- Копирование без отступов (удаляет отступы у последующих строк, если первая скопирована без отступа).
- Форматирование при перемещении строк.
- Отмена зума по
- Возврат к стандартному зуму по
- Пункт «Настройки» во всплывающем меню документа, вызывающий настройки для языка документа.
- Пункт «Специальная вставка» во всплывающем меню документа.
- Возможность свернуть и скрыть несколько атрибутов.
- Выделение всей строки по
- Предупреждение при вставке больших объёмов текста.
Изменить все упомянутые настройки после установки расширения можно в меню Tools > Options > Environment > Tweaks 2022.
Visual Studio 2022 Tweaks
Сегодня порекомендую вам расширение для Visual Studio 2022 от Мэдса Кристенсена Tweaks 2022. Оно содержит в себе множество мелких, но полезных улучшений (на основании предложений пользователей). Они упростят для вас те мелкие ненужные действия, которые нам приходится делать постоянно в повседневной работе. Подробное их описание ищите на странице расширения).
Стоит оговориться, что большинство из этого уже существует и это можно найти, покопавшись в настройках. Расширение позволяет сделать это быстро.
1. Общие
- Автоматическое сохранение документа, когда он теряет фокус. Также проект автоматически сохраняется при добавлении, удалении или переименовании файлов.
- Закрытие документа по
Ctrl+W
.- Автоматический фокус на обозревателе решений после загрузки проекта (даже если он был скрыт).
- Пункт меню для очистки недавно открытых документов.
- Пункт всплывающего меню «Открыть сбоку» для файлов в обозревателе решений (открывает файл справа от текущего документа).
- Пункт всплывающего меню «Найти в обозревателе решений» для вкладок.
2. IDE
- Перезапуск VS в меню Файл (также возможно по
Shift+Alt+F4
).- Варианты запуска VS в безопасном режиме и в режиме презентации (доступны в выпадающем меню при правом клике на ярлыке VS).
- Отключение кнопок отладки
F10
/F11
(ох, сколько раз я промахивался мимо F12
).3. Сборка
- Выпадающий список уровня подробности сообщений сборки в окне Output.
- Сохранение решения при сборке.
- Удаление папок
bin
и obj
при очистке решения.- Отображение времени запуска и длительности сборки.
- Отображение актуальности файлов проекта (полезно знать, чтобы выяснить, почему проект пересобирается). Отображается даже на минимальном уровне подробностей в окне Output.
- Отображение порядка сборки проектов
4. Редактор
- Очистка кода при форматировании документа (
Ctrl+K,D
).- Отмена копирования пустых строк. По умолчанию при нажатии
Ctrl+C
, если ничего не выделено, копируется текущая строка. Теперь, если строка пустая, она не будет скопирована.- Копирование без отступов (удаляет отступы у последующих строк, если первая скопирована без отступа).
- Форматирование при перемещении строк.
Alt+стрелки
помогают переместить строку вверх/вниз. Теперь будет добавляться нужный отступ.- Отмена зума по
Ctrl+колёсико мыши
(из-за случайных срабатываний). Работает через Ctrl+Shift+колёсико мыши
.- Возврат к стандартному зуму по
Ctrl+0
(стандартный зум устанавливается в настройках).- Пункт «Настройки» во всплывающем меню документа, вызывающий настройки для языка документа.
- Пункт «Специальная вставка» во всплывающем меню документа.
- Возможность свернуть и скрыть несколько атрибутов.
- Выделение всей строки по
Shift+Alt+E
.- Предупреждение при вставке больших объёмов текста.
Изменить все упомянутые настройки после установки расширения можно в меню Tools > Options > Environment > Tweaks 2022.
👍8
День 1182. #Карьера
Как Разработчики Проваливаются
«Разработчики терпят неудачу по двум причинам: либо делают не так, либо делают не то».
Поразительно, что большинство разработчиков уделяют больше внимания первой части проблемы и забывают про вторую. Младшие программисты больше озабочены тем, как создать продукт. Есть техническая задача, и многим из нас нравится решать её, как головоломку. Но по мере накопления опыта вы обнаружите, что часто то, что вы создали, на самом деле не то, что хотел заказчик. А такой дефект труднее обнаружить, и часто дороже устранить.
Сделать не так
Определение намеренно расплывчато. Под неправильным в данном случае понимается любой технический дефект, в результате которого система не удовлетворяет потребностям пользователей. Критическая ошибка, архитектура не масштабируется, есть серьезные проблемы с производительностью, утечки памяти, может быть даже брешь в системе безопасности. Это все те вещи, о которых мы склонны думать, когда думаем о недостатках, дефектах или ошибках в приложениях.
Зачастую эти ошибки незначительны. Они могут быть обнаружены во время тестирования ещё до того, как их увидят конечные пользователи. В других случаях они могут быть довольно дорогими, и их нелегко исправить. Некоторые ошибки неизбежны, поэтому мы разрабатываем программные процессы таким образом, чтобы их можно было ожидать, обнаруживать и исправлять. Наша практика очень часто направлена на максимально быстрое обнаружение дефектов, поскольку мы знаем, что исправление дефекта сразу после его появления обходится на порядки дешевле, чем после его отправки в производственную среду. Предотвращение попадания дефектов в продукт — очень полезная деятельность для разработчиков ПО.
Ещё один способ создавать что-то неправильно связан с архитектурой или качеством. Некоторые решения, принятые на ранней стадии в отношении системной архитектуры, могут оказаться неправильными позже, когда они не позволят нам реагировать на запросы клиентов. Технический долг в виде костылей может иметь аналогичные последствия в перспективе. Хотя это и более коварно, чем выпуск видимых пользователями дефектов, это тоже примеры неправильного построения.
Сделать не то
Зачем мы делаем не то? Оказывается, общение – это трудно. Клиенты и пользователи не всегда чётко сообщают, чего они хотят. Мы не всегда хорошо слушаем или забываем. Или делаем то, что, как мы думаем, они хотят, или то, что хотели бы мы, вместо того, что требуется. Иногда это даже работает, но в большинстве случаев это пример того, как мы забываем, что мы не пользователи.
Часто пользователь хочет решить проблему, но, когда видит часть решения, это порождает новые идеи о том, как лучше её решить. Дело не в том, что они не знали, чего хотят, а в том, что итеративный процесс разработки решения выявил лучший подход. Худшее, что мы можем сделать как разработчики — это продавить посредственное решение, потому что мы не открыты для отличного, которое мы же нашли в процессе разработки. Поэтому важно часто обмениваться информацией, подтверждать наши предположения и позволять клиентам и заинтересованным сторонам реагировать на нашу работу по мере её продвижения. Будьте готовы изменить направление и быть открытыми для новых идей, чтобы максимизировать ценность предлагаемого вами решения.
Способность построить что-то правильно — это, как правило, вопрос технической компетентности. Как только вы достигнете определенного порога мастерства, вы будете уверены в своей способности сделать это. Создание правильной вещи требует дополнительных навыков и может зависеть от этой технической компетенции. Помимо правильного создания ПО, теперь вы должны иметь возможность быстро и эффективно общаться и изменять направление вашего решения по мере необходимости на основе актуальной информации. Только тогда вы можете быть уверены, что создаёте правильные вещи правильно.
Источник: https://weeklydevtips.com/episodes/how-developers-fail-ipx3u5cw?utm_sq=gg631te050
Автор оригинала: Steve "Ardalis" Smith
Как Разработчики Проваливаются
«Разработчики терпят неудачу по двум причинам: либо делают не так, либо делают не то».
Поразительно, что большинство разработчиков уделяют больше внимания первой части проблемы и забывают про вторую. Младшие программисты больше озабочены тем, как создать продукт. Есть техническая задача, и многим из нас нравится решать её, как головоломку. Но по мере накопления опыта вы обнаружите, что часто то, что вы создали, на самом деле не то, что хотел заказчик. А такой дефект труднее обнаружить, и часто дороже устранить.
Сделать не так
Определение намеренно расплывчато. Под неправильным в данном случае понимается любой технический дефект, в результате которого система не удовлетворяет потребностям пользователей. Критическая ошибка, архитектура не масштабируется, есть серьезные проблемы с производительностью, утечки памяти, может быть даже брешь в системе безопасности. Это все те вещи, о которых мы склонны думать, когда думаем о недостатках, дефектах или ошибках в приложениях.
Зачастую эти ошибки незначительны. Они могут быть обнаружены во время тестирования ещё до того, как их увидят конечные пользователи. В других случаях они могут быть довольно дорогими, и их нелегко исправить. Некоторые ошибки неизбежны, поэтому мы разрабатываем программные процессы таким образом, чтобы их можно было ожидать, обнаруживать и исправлять. Наша практика очень часто направлена на максимально быстрое обнаружение дефектов, поскольку мы знаем, что исправление дефекта сразу после его появления обходится на порядки дешевле, чем после его отправки в производственную среду. Предотвращение попадания дефектов в продукт — очень полезная деятельность для разработчиков ПО.
Ещё один способ создавать что-то неправильно связан с архитектурой или качеством. Некоторые решения, принятые на ранней стадии в отношении системной архитектуры, могут оказаться неправильными позже, когда они не позволят нам реагировать на запросы клиентов. Технический долг в виде костылей может иметь аналогичные последствия в перспективе. Хотя это и более коварно, чем выпуск видимых пользователями дефектов, это тоже примеры неправильного построения.
Сделать не то
Зачем мы делаем не то? Оказывается, общение – это трудно. Клиенты и пользователи не всегда чётко сообщают, чего они хотят. Мы не всегда хорошо слушаем или забываем. Или делаем то, что, как мы думаем, они хотят, или то, что хотели бы мы, вместо того, что требуется. Иногда это даже работает, но в большинстве случаев это пример того, как мы забываем, что мы не пользователи.
Часто пользователь хочет решить проблему, но, когда видит часть решения, это порождает новые идеи о том, как лучше её решить. Дело не в том, что они не знали, чего хотят, а в том, что итеративный процесс разработки решения выявил лучший подход. Худшее, что мы можем сделать как разработчики — это продавить посредственное решение, потому что мы не открыты для отличного, которое мы же нашли в процессе разработки. Поэтому важно часто обмениваться информацией, подтверждать наши предположения и позволять клиентам и заинтересованным сторонам реагировать на нашу работу по мере её продвижения. Будьте готовы изменить направление и быть открытыми для новых идей, чтобы максимизировать ценность предлагаемого вами решения.
Способность построить что-то правильно — это, как правило, вопрос технической компетентности. Как только вы достигнете определенного порога мастерства, вы будете уверены в своей способности сделать это. Создание правильной вещи требует дополнительных навыков и может зависеть от этой технической компетенции. Помимо правильного создания ПО, теперь вы должны иметь возможность быстро и эффективно общаться и изменять направление вашего решения по мере необходимости на основе актуальной информации. Только тогда вы можете быть уверены, что создаёте правильные вещи правильно.
Источник: https://weeklydevtips.com/episodes/how-developers-fail-ipx3u5cw?utm_sq=gg631te050
Автор оригинала: Steve "Ardalis" Smith
👍6
День 1183. #ЗаметкиНаПолях
Преимущества в Производительности Запечатанных Классов в .NET
По умолчанию классы не запечатаны. Это означает, что вы можете наследовать от них. Это неправильное поведение по умолчанию. Если класс не предназначен для наследования, он должен быть запечатан. Вы можете изменить это позже, при необходимости. Кроме того, это влияет на производительность. Когда класс запечатан, JIT может применить оптимизацию и немного повысить производительность приложения.
Вызов виртуальных методов
При вызове виртуальных методов фактический метод находится во время выполнения на основе фактического типа объекта. Каждый тип имеет таблицу виртуальных методов (vtable), которая содержит адреса всех виртуальных методов. Эти указатели используются во время выполнения для вызова соответствующих реализаций (динамическая диспетчеризация). Если JIT знает фактический тип объекта, он может пропустить виртуальную таблицу и напрямую вызвать правильный метод. Использование запечатанных типов помогает JIT в этом.
Приведение типов (is / as)
При приведении типов среда выполнения должна проверять тип объекта во время выполнения. При приведении к незапечатанному типу среда выполнения должна проверять наличие всех типов в иерархии. Однако при приведении к запечатанному типу среда выполнения должна проверять только тип объекта, поэтому оно выполняется быстрее.
Массивы
Массивы в .NET ковариантны. Это означает, что допустимо
Преобразование массивов в Span<T>
Вы можете преобразовать массивы в Span<T> или ReadOnlySpan<T>. По тем же причинам, что и в предыдущем разделе, JIT должен проверить тип объекта перед преобразованием массива в
Результаты теста быстродействия на картинке ниже.
Обнаружение недостижимого кода
При использовании запечатанного типа компилятор знает, что некоторые преобразования недействительны. Таким образом, он может сообщать о предупреждениях и ошибках. Это поможет уменьшить количество ошибок в вашем приложении, а также удалить недостижимый код.
Преимущества в Производительности Запечатанных Классов в .NET
По умолчанию классы не запечатаны. Это означает, что вы можете наследовать от них. Это неправильное поведение по умолчанию. Если класс не предназначен для наследования, он должен быть запечатан. Вы можете изменить это позже, при необходимости. Кроме того, это влияет на производительность. Когда класс запечатан, JIT может применить оптимизацию и немного повысить производительность приложения.
Вызов виртуальных методов
При вызове виртуальных методов фактический метод находится во время выполнения на основе фактического типа объекта. Каждый тип имеет таблицу виртуальных методов (vtable), которая содержит адреса всех виртуальных методов. Эти указатели используются во время выполнения для вызова соответствующих реализаций (динамическая диспетчеризация). Если JIT знает фактический тип объекта, он может пропустить виртуальную таблицу и напрямую вызвать правильный метод. Использование запечатанных типов помогает JIT в этом.
public class SealedBenchmarkЗдесь JIT не может знать тип
{
NonSealedType nonSealedType = new();
SealedType sealedType = new();
public void CallMethod_NonSealed()
=> nonSealedType.Method();
public void CallMethod_Sealed()
=> sealedType.Method();
}
nonSealedType
. Он мог быть установлен в производный тип другим методом. Поэтому должен быть виртуальный вызов. В отличие от следующего кода:var instance = new NonSealedType();Здесь JIT точно знает тип, поэтому делает прямой вызов.
instance.Method();
Приведение типов (is / as)
При приведении типов среда выполнения должна проверять тип объекта во время выполнения. При приведении к незапечатанному типу среда выполнения должна проверять наличие всех типов в иерархии. Однако при приведении к запечатанному типу среда выполнения должна проверять только тип объекта, поэтому оно выполняется быстрее.
Массивы
Массивы в .NET ковариантны. Это означает, что допустимо
BaseType[] value = new DerivedType[1];Ковариантность приводит к снижению производительности. JIT должен проверять тип объекта перед назначением элемента в массив. При использовании запечатанных типов JIT может удалить проверку.
Преобразование массивов в Span<T>
Вы можете преобразовать массивы в Span<T> или ReadOnlySpan<T>. По тем же причинам, что и в предыдущем разделе, JIT должен проверить тип объекта перед преобразованием массива в
Span<T>
. При использовании запечатанного типа можно избежать проверки.Результаты теста быстродействия на картинке ниже.
Обнаружение недостижимого кода
При использовании запечатанного типа компилятор знает, что некоторые преобразования недействительны. Таким образом, он может сообщать о предупреждениях и ошибках. Это поможет уменьшить количество ошибок в вашем приложении, а также удалить недостижимый код.
class SampleИсточник: https://www.meziantou.net/performance-benefits-of-sealed-class.htm
{
public void Foo(NonSealedType obj)
{
_ = obj as IMyInterface;
// ОК, т.к. производные класса
// могут реализовывать интерфейс
}
public void Foo(SealedType obj)
{
_ = obj is IMyInterface;
// ⚠️ Предупреждение CS0184
_ = obj as IMyInterface;
// ❌ Ошибка CS0039
}
}
👍19
День 1184. #Карьера
Сегодня порекомендую вам великолепный доклад Скотта Хансельмана «Building Teams Through Systems Thinking and Stories» на конференции NDC Porto.
«У вас есть конечное число нажатий на клавиши в течение вашей жизни.»
Цитата, характеризующая доклад. Скотт даёт множество разнообразных советов о том, как нам строить свою карьеру. С какими трудностями нам приходится сталкиваться и как он их решал для себя. Выгорание, удалёнка, «удача» в карьере, менторство, истории из карьеры и многое другое.
Всё это приправлено огромным количеством искромётных шуток!
«Знаете, как называет себя Тим Бернерс-Ли, создатель интернета? Web Developer. Так вот, вы, сеньоры, старшие веб-разработчики. Вы можете называть себя сеньорами, только тогда, когда Тим Бернерс-Ли назовёт себя Senior Web Developer. Не раньше!
Хотя, впрочем, ему скорей подойдёт другое слово: The Web Developer (Разработчик Веба).»
Наслаждайтесь!
https://youtu.be/VFIw0LlULyc
Кстати, насчёт конечного числа нажатий на клавиши. Смотрите сами https://keysleft.com/
PS: спасибо @fjod10199 за ссылку на доклад в нашем чате.
Сегодня порекомендую вам великолепный доклад Скотта Хансельмана «Building Teams Through Systems Thinking and Stories» на конференции NDC Porto.
«У вас есть конечное число нажатий на клавиши в течение вашей жизни.»
Цитата, характеризующая доклад. Скотт даёт множество разнообразных советов о том, как нам строить свою карьеру. С какими трудностями нам приходится сталкиваться и как он их решал для себя. Выгорание, удалёнка, «удача» в карьере, менторство, истории из карьеры и многое другое.
Всё это приправлено огромным количеством искромётных шуток!
«Знаете, как называет себя Тим Бернерс-Ли, создатель интернета? Web Developer. Так вот, вы, сеньоры, старшие веб-разработчики. Вы можете называть себя сеньорами, только тогда, когда Тим Бернерс-Ли назовёт себя Senior Web Developer. Не раньше!
Хотя, впрочем, ему скорей подойдёт другое слово: The Web Developer (Разработчик Веба).»
Наслаждайтесь!
https://youtu.be/VFIw0LlULyc
Кстати, насчёт конечного числа нажатий на клавиши. Смотрите сами https://keysleft.com/
PS: спасибо @fjod10199 за ссылку на доклад в нашем чате.
👍9
День 1185. #ЧтоНовенького
Превью Обновлений ASP.NET Core в .NET 7
Вышло уже 3 превью новинок в ASP.NET Core в новой версии .NET 7, которая должна выйти в ноябре. Вот самое интересное, на мой взгляд.
1. Внедрение сервисов в методах контроллера
Теперь не обязательно использовать атрибут
В минимальных API теперь можно добавить аннотации для спецификаций OpenAPI. Либо через методы расширения:
Теперь можно выполнять связывание из заголовков HTTPS и строки запроса в массивы примитивных типов, строк или в
Фильтры выполняются перед основной логикой обработчика маршрута и могут использоваться для проверки и изменения параметров обработчика или перехвата выполнения обработчика.
Подробнее про них рассказывает Ник Чапсас https://youtu.be/Kt9TiXrwIp4
5. Привязка с использованием TryParse
Теперь вы можете привязывать значения параметров действия контроллера с помощью метода
- https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-2/
- https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-3/
Превью Обновлений ASP.NET Core в .NET 7
Вышло уже 3 превью новинок в ASP.NET Core в новой версии .NET 7, которая должна выйти в ноябре. Вот самое интересное, на мой взгляд.
1. Внедрение сервисов в методах контроллера
Теперь не обязательно использовать атрибут
[FromServices]
, сервис будет подставляться автоматически:public class MyController : ControllerBaseЭто можно отключить в настройках:
{
public ActionResult Get(MyService service) => Ok();
}
Services.Configure<ApiBehaviorOptions>(opt =>2. Описания конечных точек
{
opt.DisableImplicitFromServicesParameters = true;
})
В минимальных API теперь можно добавить аннотации для спецификаций OpenAPI. Либо через методы расширения:
app.MapGet("/hello", () => ...)Либо через атрибуты:
.WithDescription("Hello request");
app.MapGet("/hello", [EndpointSummary("Hello request")]() => ...);3. Привязка массивов и StringValues
Теперь можно выполнять связывание из заголовков HTTPS и строки запроса в массивы примитивных типов, строк или в
StringValues
:// GET /tags?q=1&q=24. Фильтры обработчиков маршрутов
app.MapGet("/tags", (int[] q) => $"1:{q[0]}, 2:{q[1]}");
// GET /tags?names=john&names=jack
app.MapGet("/tags", (string[] names) => $"1:{names[0]}, 2:{names[1]}");
app.MapGet("/tags", (StringValues names) => $"1:{names[0]}, 2:{names[1]} ");
Фильтры выполняются перед основной логикой обработчика маршрута и могут использоваться для проверки и изменения параметров обработчика или перехвата выполнения обработчика.
app.MapGet("/hello/{name}", HelloName)Это похоже на фильтры промежуточного ПО. Но теперь их можно «навесить» на отдельные конечные точки.
.AddFilter(async (сontext, next) =>
{
return await next(сontext);
});
Подробнее про них рассказывает Ник Чапсас https://youtu.be/Kt9TiXrwIp4
5. Привязка с использованием TryParse
Теперь вы можете привязывать значения параметров действия контроллера с помощью метода
TryParse
. В примере ниже контроллер привязывает данные из строки запроса с помощью метода TryParse
в типе параметра:public class TryParseController : ControllerBaseИсточники:
{
// GET /tryparse?data=MyName
[HttpGet]
public ActionResult Get([FromQuery]CustomParse data)
{
…
}
public class CustomParse
{
public string? Name { get; set; }
public static bool TryParse(string s, out CustomParse result)
{
if (s is null)
{
result = default;
return false;
}
result = new CustomParse { Name = s };
return true;
}
}
}
- https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-2/
- https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-3/
👍2
День 1186. #ЗаметкиНаПолях
Код или Тесты: Что Рефакторить?
Сегодня рассмотрим, как рефакторить производственный код, если у вас нет достаточного покрытия тестами.
Все мы иногда работаем над устаревшими проектами. Фактически, они даже более распространены, чем разработка с нуля. Устаревшие проекты печально известны своим «качеством» кода, как производственного, так и тестового. Некоторые проекты могут вообще не иметь тестов. Как провести рефакторинг такого проекта?
Для безопасного рефакторинга у вас должны быть тесты, чтобы гарантировать, что ваш рефакторинг ничего не сломает. Но как внедрить тесты в проект с тесно связанным, не тестируемым кодом? Если бы код был хорошим и его можно было тестировать, вам не нужно было бы его рефакторить.
Это проблема курицы и яйца в старых проектах:
- Нужны тесты, чтобы убедиться, что рефакторинг прошёл успешно.
- Нужно провести рефакторинг кода, чтобы сделать его пригодным для тестирования.
Обойти эту проблему невозможно: тестовый и рабочий код неразрывно связаны; невозможно создать хорошие тесты, не вложив усилий в кодовую базу, которую они охватывают.
Чтобы преодолеть эту проблему, надо начать со сквозных и интеграционных тестов.
Сквозные тесты полностью имитируют конечного пользователя. Например, если ваше приложение представляет собой веб-сайт, сквозные тесты проверяют его через веб-интерфейс. Как правило, их мало, и они должны применяться только к наиболее важному функционалу: функциям, в которых вы никогда не хотите видеть каких-либо ошибок, и только если вы не можете получить такую же степень защиты с помощью модульных или интеграционных тестов.
Большую часть работы обычно выполняют модульные тесты, потому что их дешевле писать и поддерживать. Однако в устаревшем проекте сквозные тесты являются единственным доступным вариантом, потому что это единственный тип тестов, который не требует изменений в коде (поскольку они взаимодействуют с приложением, используя тот же интерфейс, что и обычные пользователи). Сквозные тесты также обладают наибольшей устойчивостью к рефакторингу и не вызывают ложных срабатываний из-за ваших действий по рефакторингу.
В некоторых устаревших проектах также есть золотая середина, где вы можете писать интеграционные тесты вместо сквозных. Это проекты, которые имеют хотя бы некоторую степень разделения ответственности. Например, API с беспорядочным кодом, в котором всё же есть контроллеры. Вы можете протестировать эти контроллеры вместо полноценного вызова конечных точек API из отдельного процесса. Полученные тесты будут интеграционными, и их будет легче поддерживать, чем сквозные тесты.
Хорошая новость, что большое количество сквозных и интеграционных тестов — временные. Как только вы начнёте рефакторинг, замените сквозные тесты интеграционными, а интеграционные - модульными.
Итак, путь к рефакторингу устаревшего кода таков:
1. Определите небольшую связную область в приложении, которую можно было бы отрефакторить относительно быстро и без разрушения остального кода.
2. Покройте эту область сквозными или интеграционными тестами.
3. Выполняйте рефакторинг, разделив бизнес-логику и обязанности по оркестровке.
4. Покройте бизнес-логику юнит-тестами; оркестровку - интеграционными тестами.
5. Удалите сквозные тесты (если они не обеспечивают дополнительного тестового покрытия).
6. Помните, что адекватное покрытие модульными тестами невозможно без качественной кодовой базы.
Источник: https://khorikov.org/posts/2022-01-17-production-test-code-refactor/
Код или Тесты: Что Рефакторить?
Сегодня рассмотрим, как рефакторить производственный код, если у вас нет достаточного покрытия тестами.
Все мы иногда работаем над устаревшими проектами. Фактически, они даже более распространены, чем разработка с нуля. Устаревшие проекты печально известны своим «качеством» кода, как производственного, так и тестового. Некоторые проекты могут вообще не иметь тестов. Как провести рефакторинг такого проекта?
Для безопасного рефакторинга у вас должны быть тесты, чтобы гарантировать, что ваш рефакторинг ничего не сломает. Но как внедрить тесты в проект с тесно связанным, не тестируемым кодом? Если бы код был хорошим и его можно было тестировать, вам не нужно было бы его рефакторить.
Это проблема курицы и яйца в старых проектах:
- Нужны тесты, чтобы убедиться, что рефакторинг прошёл успешно.
- Нужно провести рефакторинг кода, чтобы сделать его пригодным для тестирования.
Обойти эту проблему невозможно: тестовый и рабочий код неразрывно связаны; невозможно создать хорошие тесты, не вложив усилий в кодовую базу, которую они охватывают.
Чтобы преодолеть эту проблему, надо начать со сквозных и интеграционных тестов.
Сквозные тесты полностью имитируют конечного пользователя. Например, если ваше приложение представляет собой веб-сайт, сквозные тесты проверяют его через веб-интерфейс. Как правило, их мало, и они должны применяться только к наиболее важному функционалу: функциям, в которых вы никогда не хотите видеть каких-либо ошибок, и только если вы не можете получить такую же степень защиты с помощью модульных или интеграционных тестов.
Большую часть работы обычно выполняют модульные тесты, потому что их дешевле писать и поддерживать. Однако в устаревшем проекте сквозные тесты являются единственным доступным вариантом, потому что это единственный тип тестов, который не требует изменений в коде (поскольку они взаимодействуют с приложением, используя тот же интерфейс, что и обычные пользователи). Сквозные тесты также обладают наибольшей устойчивостью к рефакторингу и не вызывают ложных срабатываний из-за ваших действий по рефакторингу.
В некоторых устаревших проектах также есть золотая середина, где вы можете писать интеграционные тесты вместо сквозных. Это проекты, которые имеют хотя бы некоторую степень разделения ответственности. Например, API с беспорядочным кодом, в котором всё же есть контроллеры. Вы можете протестировать эти контроллеры вместо полноценного вызова конечных точек API из отдельного процесса. Полученные тесты будут интеграционными, и их будет легче поддерживать, чем сквозные тесты.
Хорошая новость, что большое количество сквозных и интеграционных тестов — временные. Как только вы начнёте рефакторинг, замените сквозные тесты интеграционными, а интеграционные - модульными.
Итак, путь к рефакторингу устаревшего кода таков:
1. Определите небольшую связную область в приложении, которую можно было бы отрефакторить относительно быстро и без разрушения остального кода.
2. Покройте эту область сквозными или интеграционными тестами.
3. Выполняйте рефакторинг, разделив бизнес-логику и обязанности по оркестровке.
4. Покройте бизнес-логику юнит-тестами; оркестровку - интеграционными тестами.
5. Удалите сквозные тесты (если они не обеспечивают дополнительного тестового покрытия).
6. Помните, что адекватное покрытие модульными тестами невозможно без качественной кодовой базы.
Источник: https://khorikov.org/posts/2022-01-17-production-test-code-refactor/
👍10
День 1187. #ЗаметкиНаПолях
Апкаст Записей
Интересную особенность записей обнаружил Фил Хаак. Вы не можете сделать апкаст, как для класса. Допустим, у нас есть следующие записи.
Базовая (она же DTO для обновления):
Фил спросил сообщество, как решить эту проблему. Предлагались разные варианты от использования маппера до сериализации/десериализации. Но решение нашлось довольно элегантное.
Апкаст Записей
Интересную особенность записей обнаружил Фил Хаак. Вы не можете сделать апкаст, как для класса. Допустим, у нас есть следующие записи.
Базовая (она же DTO для обновления):
public record PersonUpdate()Производная (с добавленным свойством
{
public string Name {get; init;}
//... остальные свойства
};
Id
):public record Person(int Id)Задача стандартная: получить
: PersonUpdate() {};
Person
из базы или API, создать PersonUpdate
с изменёнными свойствами и отправить его в метод UpdatePerson
. Код получается довольно простой:var person = GetPerson(42);Вроде всё должно работать. Но давайте посмотрим, что у нас получилось в
var updated = (PersonUpdate)person
with { Name = "New Name", …};
UpdatePerson(42, updated);
updated
:Console.WriteLine(updated);Свойство обновилось, но тип всё равно производный и содержит
// Вывод:
// Person { Name = New Name, Id = 42 }
Id
. Это, конечно, может не быть проблемой, но для Фила стало, т.к. API для обновления принимал объект без свойства Id
, а в этом случае выдавал ошибку.Фил спросил сообщество, как решить эту проблему. Предлагались разные варианты от использования маппера до сериализации/десериализации. Но решение нашлось довольно элегантное.
public record PersonUpdate()Статический метод принимает запись и выдаёт её копию. И действительно:
{
//... свойства
public static PersonUpdate
Copy(PersonUpdate updated) => new(updated);
};
var updated = PersonUpdate.Copy(person)Источник: https://gist.github.com/haacked/b47ed096201a47c9ebceb7397c09d28b
with { Name = "New Name"};
Console.WriteLine(updated);
// Вывод:
// PersonUpdate { Name = New Name }
👍16
Software Engineering at Google.pdf
9.2 MB
День 1188. #Книги
Наткнулся на книгу «Software Engineering at Google». Сам ещё не читал, но похоже, прочитать нужно обязательно.
Сегодня инженеры-программисты должны знать не только, как эффективно программировать, но и как разрабатывать правильные инженерные методы, чтобы сделать кодовую базу устойчивой и здоровой. Эта книга подчеркивает эту разницу между программированием и программной инженерией. Как программисты могут управлять кодовой базой, которая развивается и реагирует на меняющиеся требования на протяжении своей жизни? Инженеры-программисты из Google Титус Уинтерс, Хайрам Райт и Том Мэншрек представляют откровенный и проницательный взгляд на то, как некоторые из ведущих мировых специалистов создают и поддерживают ПО. В книге рассказывается об уникальной инженерной культуре, процессах и инструментах Google, а также о том, как эти аспекты влияют на эффективность инженерной организации.
Наткнулся на книгу «Software Engineering at Google». Сам ещё не читал, но похоже, прочитать нужно обязательно.
Сегодня инженеры-программисты должны знать не только, как эффективно программировать, но и как разрабатывать правильные инженерные методы, чтобы сделать кодовую базу устойчивой и здоровой. Эта книга подчеркивает эту разницу между программированием и программной инженерией. Как программисты могут управлять кодовой базой, которая развивается и реагирует на меняющиеся требования на протяжении своей жизни? Инженеры-программисты из Google Титус Уинтерс, Хайрам Райт и Том Мэншрек представляют откровенный и проницательный взгляд на то, как некоторые из ведущих мировых специалистов создают и поддерживают ПО. В книге рассказывается об уникальной инженерной культуре, процессах и инструментах Google, а также о том, как эти аспекты влияют на эффективность инженерной организации.
👍23
День 1189. #ЗаметкиНаПолях #AsyncTips
Неизменяемые словари
Задача: Нужна коллекция «ключ/значение», которая не слишком часто изменяется и допускает безопасные обращения из нескольких потоков. Например, в этой коллекции могут храниться данные состояния приложения в подстановочной (lookup) таблице; данные состояния редко изменяются, но они должны быть доступны для разных потоков.
Решение
Есть два типа неизменяемых словарей:
Несортированные и отсортированные словари обладают сходным быстродействием - O(log N) для всех типов операций, но рекомендуется использовать неупорядоченные словари, если только не требуется, чтобы элементы были отсортированы (они могут работать в целом немного быстрее). Кроме того, несортированные словари могут использоваться с любыми типами ключей, тогда как отсортированные словари требуют, чтобы тип ключей был сравнимым (например,
Словари являются полезным и общепринятым инструментом при работе с состоянием приложения. Они могут использоваться в любых сценариях, связанных с ключами/значениями или подстановками.
Неизменяемые словари, как и другие неизменяемые коллекции, поддерживают механизм для эффективного построения экземпляров, содержащих большое количество элементов. Например, если исходные данные загружаются в начале работы программы, вы сможете воспользоваться механизмом построителей для конструирования исходного неизменяемого словаря. С другой стороны, если данные строятся постепенно во время выполнения, вероятно, можно будет воспользоваться обычным методом
См. также:
- Неизменяемые стеки и очереди
- Неизменяемые списки
- Неизменяемые множества
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
Неизменяемые словари
Задача: Нужна коллекция «ключ/значение», которая не слишком часто изменяется и допускает безопасные обращения из нескольких потоков. Например, в этой коллекции могут храниться данные состояния приложения в подстановочной (lookup) таблице; данные состояния редко изменяются, но они должны быть доступны для разных потоков.
Решение
Есть два типа неизменяемых словарей:
ImmutableDictionary<TKey, TValue>
и ImmutableSortedDictionary<TKey, TValue>
из пространства имён System.Collections.Immutable
, которые имеют очень похожие члены:var d = ImmutableDictionary<int, string>.Empty;Обратите внимание на использование
d = d.Add(10, "Ten");
d = d.Add(21, "Twenty-One");
d = d.SetItem(10, "Diez");
// Выводит "10Diez" и "21Twenty-One" в непредсказуемом порядке.
foreach (var item in d)
Console.WriteLine(item.Key + item.Value);
string ten = d[10];
// ten == "Diez"
d = d.Remove(21);
SetItem
. В изменяемом словаре можно было бы использовать конструкцию вида dictionary[key] = item
, но неизменяемые словари должны возвращать обновлённый неизменяемый словарь, поэтому вместо этого они должны использовать метод SetItem
.Несортированные и отсортированные словари обладают сходным быстродействием - O(log N) для всех типов операций, но рекомендуется использовать неупорядоченные словари, если только не требуется, чтобы элементы были отсортированы (они могут работать в целом немного быстрее). Кроме того, несортированные словари могут использоваться с любыми типами ключей, тогда как отсортированные словари требуют, чтобы тип ключей был сравнимым (например,
int
или реализующий IComparable
).Словари являются полезным и общепринятым инструментом при работе с состоянием приложения. Они могут использоваться в любых сценариях, связанных с ключами/значениями или подстановками.
Неизменяемые словари, как и другие неизменяемые коллекции, поддерживают механизм для эффективного построения экземпляров, содержащих большое количество элементов. Например, если исходные данные загружаются в начале работы программы, вы сможете воспользоваться механизмом построителей для конструирования исходного неизменяемого словаря. С другой стороны, если данные строятся постепенно во время выполнения, вероятно, можно будет воспользоваться обычным методом
Add
неизменяемых словарей.См. также:
- Неизменяемые стеки и очереди
- Неизменяемые списки
- Неизменяемые множества
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
👍4
Какой тип ресурса рекомендуется подключить к Azure Function App для целей логирования и монтиторинга?
#Quiz #Azure
#Quiz #Azure
Anonymous Quiz
14%
Azure Event Hubs
47%
Azure Log Analytics
38%
Azure Application Insights
1%
Azure Container Instances
👍2