.NET Разработчик

Description
Дневник сертифицированного .NET разработчика.

Для связи: @SBenzenko

Поддержать канал: https://pay.cloudtips.ru/p/70df3b3b
Subscribers

We recommend to visit

Сотрудничество info@litvinpr.ru

Last updated 3 months, 2 weeks ago

Мы #1 в кино🎬

Все материалы размещены по партнёрской програме ivi.ru | All materials are posted on the partner program ivi.ru

❗️Администрация не несёт ответственность за рекламу. Будьте внимательны❗️

Менеджер по рекламе: @kuzr103

Last updated 3 months, 2 weeks ago

Утро начинается не с кофе.

Сотрудничество: @evoanna (по всем вопросам, только мне писать)

Last updated 3 months, 2 weeks ago

7 months, 3 weeks ago
7 months, 3 weeks ago

День 1227. #Карьера
Прекратите Прокрастинировать и Займитесь Наконец Своим Проектом
Мы все слышали стандартный совет по продуктивности — нужно «съесть эту лягушку», т.е. сначала решить самые сложные и важные задачи, чтобы не тратить весь день на прокрастинацию. Это легче сказать, чем сделать.

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

1. Начните с лёгкого изменения поведенияКогда цель большая, сложная или долгосрочная, требуется огромное количество мотивации, чтобы продолжать двигаться вперёд. Проект обычно требует много времени и множества шагов (мозговой штурм, POC, модели, реализация, исправления, обратная связь, дополнительные исправления и т. д.). Как же поддерживать мотивацию?

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

2. Устанавливайте дедлайныКаждый управленец слышал мантру: «Что можно измерить, то и делается». Это верно как для отслеживания продаж, так и для достижения наших собственных долгосрочных амбиций.

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

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

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

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

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

Источник: https://hbr.org/2022/05/stop-procrastinating-and-tackle-that-big-project

7 months, 3 weeks ago

День 1226. #ЧтоНовенького
Критическое Изменение: Удаление Привязки HTTPS по Умолчанию в Kestrel
Привязка адреса и порта HTTPS по умолчанию удалена в Kestrel в превью версии 6 .NET 7.Предыдущее поведениеРаньше, если значения для адреса и порта не указывались явно, но был доступен локальный сертификат для разработки, Kestrel по умолчанию привязывался как к http://localhost:5000, так и к https://localhost:5001.

Теперь пользователи должны вручную привязываться к HTTPS и явно указывать адрес и порт одним из следующих вариантов:
- в файле launchSettings.json,
- в переменной среды ASPNETCORE_URLS,
- в аргументе командной строки \-\-urls,
- в конфигурации хоста по ключу urls,
- с помощью метода расширения UseUrls.

Привязка HTTP не изменилась.

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

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

Рекомендованное действиеЕсли вы не использовали привязку https://localhost:5001 по умолчанию, никаких изменений не требуется. Однако, если вы использовали эту привязку, ознакомьтесь с этим руководством где описано, как вы можете обновить свой сервер, чтобы включить HTTPS.

Источник: https://github.com/aspnet/Announcements/issues/486

7 months, 3 weeks ago

День 1224. #ЗаметкиНаПолях
Несколько Папок для Статических Файлов в ASP.NET Core
Если вам по какой-то причине нужно разделить ваши статические файлы (к примеру, JS/CSS/картинки в одной папке, и файлы, которые могут скачивать пользователи – в другой), наивным – но неправильным - решением будет использовать UseStaticFiles дважды:

```
app.UseStaticFiles();

app.UseStaticFiles(new StaticFileOptions()
{
// Добавляем ещё папку
FileProvider = new PhysicalFileProvider(
Path.Combine(
builder.Environment.ContentRootPath,
"Docs"
))
});

`` На первый взгляд, это работает. Промежуточное ПО будет искать файлы в обычной папкеwwwroot, а затем в папкеDocsи возвращать их. Проблема возникает, если вы попытаетесь использовать что\-нибудь, типаasp-append-versionв представлениях для файлов изDocs`. Версия просто не будет добавляться. Добавление версии в URL зависит от контрольной суммы файла. В этом случае система не может её найти, и этот атрибут просто будет проигнорирован.

StaticFiles на самом деле используют не просто промежуточное ПО для поиска файла, а полагаются на WebRootFileProvider. Но что такое FileProvider?

В документации есть хорошая статья об этом. Если коротко, это сервис, который знает, как находить файлы разными способами. Платформа имеет несколько реализаций, включая PhysicalFileProvider или ManifestEmbeddedFileProvider. В нашем плохом примере выше используется PhysicalFileProvider. А на самом деле UseStaticFiles использует WebRootFileProvider для поиска статических файлов (и этот провайдер просто ищет в wwwroot). Таким образом, реальный способ справиться с проблемой — изменить WebRootFileProvider приложения.

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

```
var webRootProvider =
new PhysicalFileProvider(
builder.Environment.WebRootPath
);

var docPathProvider =
new PhysicalFileProvider(
Path.Combine(
builder.Environment.ContentRootPath,
"Docs"
));

`` Теперь нам нужен третий тип, который позволит объединить наши провайдеры. Этот провайдер называетсяCompositeFileProvider`:

```
var compositeProvider =
new CompositeFileProvider(
webRootProvider,
docPathProvider
);

`` И наконец, заменяемWebRootFileProviderнашим новымCompositeFileProvider`:

```
app.Environment.WebRootFileProvider = compositeProvider;
app.UseStaticFiles();

```
Источник: https://wildermuth.com/2022/04/25/multiple-directories-for-static-files-in-aspnetcore/

7 months, 3 weeks ago

День 1223. #МоиИнструменты
VoidTools "Everything"
Сегодня расскажу об очень полезной утилите, которую мне посоветовал коллега.VoidTools "Everything""Everything" — это поисковая система для Windows, которая мгновенно находит файлы и папки по имени. В отличие от поиска Windows, "Everything" при открытии отображает все файлы и папки на вашем компьютере (отсюда и название). Вы вводите фильтр поиска, чтобы отфильтровать отображаемые файлы и папки.

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

Поиск практически мгновенный и невероятно удобный. Например, на картинке ниже я объединил в фильтрах через пробел значения .csproj и имена папок (начиная с \), в которых это имя надо искать. Заметьте, что имена папок могут идти в любом порядке. Жирным в результатах подсвечены совпадения. Поиск можно настроить, отфильтровав по типу файла, добавив регулярные выражения и т.п. Отображение результатов также можно изменить.

И ещё парочка «хаков» для улучшения работы.

Смотрим содержимое нестандартных файловХотя "Everything" позволяет посмотреть содержимое множества разных типов файлов, в том числе текстовых, Microsoft Office, картинок, .cs файлов и т.п., некоторые могут не поддерживаться. Например, файлы .csproj, как показано на картинке ниже. Чтобы это исправить, нужно внести небольшое изменение в реестр. Создайте файл <имя>.reg и добавьте в него следующее содержимое:

```
REGEDIT4

[HKEY_CLASSES_ROOT.CSPROJ]
"Content Type"="text/plain"
"PerceivedType"="text"

```
Сохраните файл. Затем двойным щелчком на файле внесите изменения в реестр. После этого этот тип файлов можно будет посмотреть в виде текста. Понятно, что это глобальная настройка отображения для Windows. "Everything" просто использует эти значения.

Горячая клавиша с использованием клавиши WindowsМожно назначить для нового поиска в "Everything" (да и для чего угодно ещё) горячую клавишу с кнопкой Windows, например, Win+S. Поэтому его можно отключить, добавив значение в реестр. Аналогично предыдущей, это глобальная настройка.
Зайдите в Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced и добавьте новое значение Expandable String Value с именем DisabledHotKeys и значением S.
Перезагрузите Windows. После этого сочетание Win+S перестанет работать (если что, это глобальный поиск, его также можно открыть по Win+Q). После этого в "Everything" зайдите в Tools > Options > General > Keyboard и задайте для File | New Search Window значение Win+S. Некоторые сочетания с клавишей Windows сработают и без изменений в реестре (например, Win+Y или Win+J). Однако, возможно, в будущем им в Windows будет назначено какое-нибудь действие, тогда они работать перестанут.

7 months, 3 weeks ago

**День 1222. #ЗаметкиНаПолях #AsyncTips
Блокирующие очереди

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

РешениеТип .NET BlockingCollection<T> проектировался для создания таких коммуникационных каналов. По умолчанию BlockingCollection<T> работает в режиме блокирующей очереди и предоставляет поведение «первым зашел, первым вышел».

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

```
private readonly BlockingCollection<int> _bq =
new BlockingCollection<int>();

```
Обычно поток делает что-то одно: либо добавляет элементы в коллекцию, либо удаляет элементы. Потоки, добавляющие элементы, называются потоками-производителями, а потоки, удаляющие элементы, называются потоками-потребителями.

Потоки-производители могут добавлять элементы вызовами Add, а когда поток-производитель завершится (когда будут добавлены все элементы), он может завершить коллекцию вызовом CompleteAdding. Тем самым он уведомляет коллекцию о том, что элементы далее добавляться не будут, а коллекция может сообщить своим потребителям, что элементов больше не будет.
В следующем простом примере производитель добавляет два элемента, а потом помечает коллекцию как завершенную:

```
_bq.Add(7);
_bq.Add(13);
_bq.CompleteAdding();

`` Потоки\-потребители обычно выполняются в цикле, ожидая следующего элемента и выполняя его последующую обработку. Если выделить код производителя в отдельный поток (например, вызовомTask.Run`), то эти элементы можно будет потреблять следующим образом:

```
// Выводит "7", затем "13".
foreach (int item in _bq.GetConsumingEnumerable())
Console.WriteLine(item);

`` Если потребителей должно быть несколько,GetConsumingEnumerable` может вызываться из нескольких потоков одновременно. Тем не менее каждый элемент передается только одному из этих потоков. При завершении коллекции завершается и перечисляемый объект.

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

Блокирующие очереди хорошо работают при наличии отдельного потока (например, из пула потоков), действующего как производитель или потребитель. Они не настолько хороши, если вы хотите обращаться к коммуникационному каналу асинхронно — например, если UI-поток должен действовать в режиме потребителя. Если вы вводите в своё приложение подобный коммуникационный канал, подумайте о переходе на библиотеку TPL Dataflow. Во многих случаях решение с использованием TPL Dataflow проще самостоятельного построения коммуникационных каналов и фоновых потоков.
Тип BufferBlock<T> из TPL Dataflow может работать как блокирующая очередь, к тому же TPL Dataflow позволяет построить конвейер или сеть для обработки. Впрочем, во многих простых случаях обычные блокирующие очереди (например, BlockingCollection<T>) станут более подходящим вариантом при проектировании.

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.

8 months ago

**День 1212. #ЗаметкиНаПолях #AsyncTips
Потокобезопасные словари

Задача**Имеется коллекция «ключ/значение» (например, кэш в памяти), которая должна поддерживаться в синхронизированном состоянии, даже если несколько потоков выполняют с ней операции чтения и записи.

РешениеТип ConcurrentDictionary<TKey, TValue> является потокобезопасным гарантирует быстрый доступ в подавляющем большинстве сценариев. Его API сильно отличается от стандартного типа Dictionary<TKey, TValue>, поскольку он должен иметь дело с конкурентным доступом из многих потоков.

ЗаписьЧтобы задать значение для ключа, используйте метод AddOrUpdate:

```
var d = new ConcurrentDictionary<int, string>();
string newValue = d.AddOrUpdate(
0,
key => "Zero",
(key, oldValue) => "Zero"
);

`` МетодAddOrUpdateвыглядит сложно, так как должен делать несколько вещей в зависимости от текущего содержимого словаря. Аргументы: \- ключ, \- делегат, преобразующий ключ (в данном случае0) в значение, которое будет добавлено в словарь (в данном случае"Zero"). Вызывается, только если ключа не существует в словаре. \- делегат, преобразующий ключ (0) и старое значение в обновлённое значение, которое должно быть сохранено в словаре ("Zero"). Вызывается, если ключ уже существует в словаре.AddOrUpdate` возвращает новое значение для этого ключа (значение, которое было возвращено одним из делегатов).

Чтобы конкурентный словарь работал правильно, может оказаться, что метод AddOrUpdate должен вызвать один (или оба) делегата несколько раз. Такое бывает очень редко, но это возможно. А значит, делегаты должны быть простыми и быстрыми и не должны иметь побочных эффектов, т.е. должны только создавать значение, не изменяя никакие другие переменные в приложении.

Добавить значение в словарь можно и через индекс:

```
// Добавляет (или обновляет) ключ 0,
// связывая с ним значение "Zero".
d[0] = "Zero";

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

Чтение
```
bool keyExists = d.TryGetValue(0, out string current);

``TryGetValueвернётtrueи задаст значениеcurrent, если ключ был найден в словаре. Если ключ не найден,TryGetValueвернетfalse`. Прочитать значение можно и через индекс, но при отсутствии ключа будет выдано исключение.

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

УдалениеАналогично чтению:

```
bool keyExisted = d.TryRemove(0, out string removed);

`` ХотяConcurrentDictionary<TKey, TValue>является потокобезопасным, это не означает атомарности его операций. Если несколько потоков вызываютAddOrUpdate` конкурентно, может оказаться, что два потока обнаружат отсутствие ключа, а затем оба одновременно выполнят своего делегата, создающего новое значение.

ConcurrentDictionary<TKey, TValue> хорошо работает при чтении и записи со стороны нескольких потоков в общую коллекцию.
Если обновления относительно редки, возможно, ImmutableDictionary<TKey, TValue> будет более подходящим вариантом.

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.

8 months, 1 week ago
8 months, 1 week ago

День 1211. #ЗаметкиНаПолях
SQL Последовательности для Создания Уникальных Значений
Для создания уникального номера, например заказа в системе продаж, вы можете:
- использовать автогенерацию первичного ключа из базы данных,
- выбирать максимальный номер заказа из базы и добавлять единицу,
- использовать свой код, генерирующий уникальные числа.
– использовать SQL-последовательность.

Последовательность (sequence) - простой и эффективный способ создания уникальных упорядоченных значений потокобезопасным способом.

SQL код для создания очень прост:

```
CREATE SEQUENCE TestSeq
START WITH 1
INCREMENT BY 1

```
Начальный номер и число инкремента могут быть любыми.
Выбрать следующее значение можно так:

```
SELECT NEXT VALUE FOR TestSeq

`` Entity Framework также поддерживает последовательности… ну, более\-менее. Создать последовательность можно вOnModelCreatingвашегоDbContext`:

```
protected override void OnModelCreating(ModelBuilder mb)
{
mb.HasSequence("TestSeq",
x => x.StartsAt(1000).IncrementsBy(2));

```
А вот простого метода получения следующего значения нет. Большинство документации сводится к использованию значения по умолчанию через вот такую конструкцию:

```
mb.Entity<Order>()
.Property(o => o.OrderNo)
.HasDefaultValueSql("NEXT VALUE FOR TestSeq");

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

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

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

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

Источник: https://dotnetcoretutorials.com/2022/03/22/using-sql-server-sequences-to-generate-unique-values/

8 months, 3 weeks ago

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

Правила кода — это правила, которые компилятор или инструмент анализа кода применяет на уровне сборки. Они обеспечивают соблюдение соглашений о кодировании, выявляют ошибки и предоставляют инструменты для исправлений. Roslyn и другие инструменты .NET/C# используют статический анализ кода, чтобы проверить, где в вашем коде есть нарушения. Rider и Resharper предоставляют инструменты статического анализа кода поверх существующего анализа кода от Roslyn.

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

Без правил кода этот код компилируется нормально:

```
public static class Program
{
public static void Main() =>
Console.WriteLine(
string.Format(new CultureInfo("en-US"),
"Hello {0}{1}!", "World")
);
}

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

Правила кода включаются на уровне csproj, а затем можно изменить файл editorconfig для отдельных правил. Нужно добавить Nuget пакет Microsoft.CodeAnalysis.NetAnalyzers (Roslyn Analysers). Это самый распространённый набор анализаторов. Они работают на всех IDE и платформах и внутри конвейеров CI/CD. Вы также можете добавить другие пакеты Nuget для дополнительных анализаторов.

Если в вашем решении несколько проектов, нужно переместить конфигурацию в файл Directory.Build.props. Это позволит совместно использовать параметры проекта для нескольких проектов в вашем решении.

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

Рекомендуется включить все правила кода и постепенно исправлять ошибки, с которыми вы сталкиваетесь в своём решении. Существуют инструменты массового исправления, которые помогут вам решить многие проблемы. Команда CLI dotnet format применит множество исправлений, но чаще бывает безопаснее применять исправления для правил по одному вручную. Устранение всех проблем может занять некоторое время. Однако не нужно исправлять все нарушения правил кода за один раз.

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

Источник: https://christianfindlay.com/2022/04/24/code-rules/

We recommend to visit

Сотрудничество info@litvinpr.ru

Last updated 3 months, 2 weeks ago

Мы #1 в кино🎬

Все материалы размещены по партнёрской програме ivi.ru | All materials are posted on the partner program ivi.ru

❗️Администрация не несёт ответственность за рекламу. Будьте внимательны❗️

Менеджер по рекламе: @kuzr103

Last updated 3 months, 2 weeks ago

Утро начинается не с кофе.

Сотрудничество: @evoanna (по всем вопросам, только мне писать)

Last updated 3 months, 2 weeks ago