День девятьсот шестьдесят девятый. #Оффтоп #Обучение
Как Быть Лучше Всех как Разработчик? Окончание
Начало
Как узнать, какую новинку выбрать?
Да никак! Мы, вероятно, можем предположить, что новинка потенциально может решить наши проблемы. Однако мы не можем изучать все новинки и таким образом быть в курсе всех возможных трендов. Поэтому нам нужно с умом выбирать новинки, особенно в сфере технологий. Выберите, в чём хотите быть впереди, и сфокусируйтесь на этом. Нужно сосредоточиться на этой сфере, но всегда быть готовым изменить направление, поскольку ветер изменчив, и новинка, на которую вы так надеялись, может потерять популярность.
Тогда у вас есть выбор: продолжить изучать ту блестяшку, которую вы выбрали, или перейти к следующей теме, в которой вы хотите быть впереди всех.
Как оставаться впереди?
Банальный ответ: упорным трудом. Однако давайте разберёмся, потому что есть некоторые вполне реальные и осязаемые вещи, которые мы можем делать. Вот те, которые подходят мне, ваш список может быть длиннее или короче.
Часто мы можем подогнать их под наш график. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях.
Всё это требует времени, но всё это пассивно. Если мы потратим на это время, мы соберём несколько кусочков полезной информации, которая поможет нам опередить приближающийся поезд. Однако этого недостаточно.
Есть несколько более активных действий, которые мы можем выполнить и которые потребуют от вас больше времени, но, возможно, принесут более ощутимую награду с точки зрения понимания предмета. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях…
…Но делать это активно. То есть использовать полученные знания и применять их к чему-то в реальном мире. Поиграть с новой игрушкой - это первый шаг. Такие вопросы как:
- Какие проблемы она решает?
- Чью жизнь облегчает (допустим, что облегчает)?
- Где её можно применить в нашем мире?
- Какие есть конкуренты?
- Где её нельзя применить или в каких случаях она не сработает?
Это поможет вам «потыкать блестяшку палкой» и сформулировать некоторые мысли о том, ЧТО вы узнали. Создание контента на тему, по моему опыту, является одним из лучших способов быть впереди в теме. Это помогает закрепить знания в голове, и даёт дополнительный бонус в том, что может помочь кому-то ещё в сообществе. Эти люди могут не хотеть быть впереди всех, но хотели бы узнать о новинках и использовать их в своей работе.
Как находить время, чтобы быть впереди всех?
Как и всё, что соперничает за наше время, изучение новинок требует тщательной расстановки приоритетов. Мы не можем рассчитывать на то, что сможем быть впереди всех в чём-либо, если не найдём времени на изучение этого. Конечно, наше время – дефицит. Но мы можем искать возможности для обучения как в профессиональной, так и в личной сфере.
Многие работодатели рады, что мы тратим часть своего рабочего времени на изучение чего-то нового, особенно если это может принести им пользу в долгосрочной перспективе. Это привилегия, и не у всех она есть, но многие компании осознают тот факт, что нам нужно время, чтобы отточить навыки в некоторых областях, и неспособность дать это время принесёт ущерб как сотрудникам, так и потенциально продуктам компании.
Мы также можем использовать для этого своё личное время. Оно вам надо? Только вы можете ответить на этот вопрос. Если это приносит пользу лично вам и вашей карьере, возможно, это стоит того. Это путь, который может принести существенные выгоды. В итоге всё зависит от вас, вашего выбора понравившейся блестяшки и вашего графика.
Источник: https://helenjoscott.iss.onedium.com/how-can-you-stay-ahead-of-the-curve-as-a-developer-a27d728980a2
Автор оригинала: Helen Scott
Как Быть Лучше Всех как Разработчик? Окончание
Начало
Как узнать, какую новинку выбрать?
Да никак! Мы, вероятно, можем предположить, что новинка потенциально может решить наши проблемы. Однако мы не можем изучать все новинки и таким образом быть в курсе всех возможных трендов. Поэтому нам нужно с умом выбирать новинки, особенно в сфере технологий. Выберите, в чём хотите быть впереди, и сфокусируйтесь на этом. Нужно сосредоточиться на этой сфере, но всегда быть готовым изменить направление, поскольку ветер изменчив, и новинка, на которую вы так надеялись, может потерять популярность.
Тогда у вас есть выбор: продолжить изучать ту блестяшку, которую вы выбрали, или перейти к следующей теме, в которой вы хотите быть впереди всех.
Как оставаться впереди?
Банальный ответ: упорным трудом. Однако давайте разберёмся, потому что есть некоторые вполне реальные и осязаемые вещи, которые мы можем делать. Вот те, которые подходят мне, ваш список может быть длиннее или короче.
Часто мы можем подогнать их под наш график. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях.
Всё это требует времени, но всё это пассивно. Если мы потратим на это время, мы соберём несколько кусочков полезной информации, которая поможет нам опередить приближающийся поезд. Однако этого недостаточно.
Есть несколько более активных действий, которые мы можем выполнить и которые потребуют от вас больше времени, но, возможно, принесут более ощутимую награду с точки зрения понимания предмета. Мы можем:
- читать посты в блогах,
- смотреть видео,
- слушать доклады на конференциях…
…Но делать это активно. То есть использовать полученные знания и применять их к чему-то в реальном мире. Поиграть с новой игрушкой - это первый шаг. Такие вопросы как:
- Какие проблемы она решает?
- Чью жизнь облегчает (допустим, что облегчает)?
- Где её можно применить в нашем мире?
- Какие есть конкуренты?
- Где её нельзя применить или в каких случаях она не сработает?
Это поможет вам «потыкать блестяшку палкой» и сформулировать некоторые мысли о том, ЧТО вы узнали. Создание контента на тему, по моему опыту, является одним из лучших способов быть впереди в теме. Это помогает закрепить знания в голове, и даёт дополнительный бонус в том, что может помочь кому-то ещё в сообществе. Эти люди могут не хотеть быть впереди всех, но хотели бы узнать о новинках и использовать их в своей работе.
Как находить время, чтобы быть впереди всех?
Как и всё, что соперничает за наше время, изучение новинок требует тщательной расстановки приоритетов. Мы не можем рассчитывать на то, что сможем быть впереди всех в чём-либо, если не найдём времени на изучение этого. Конечно, наше время – дефицит. Но мы можем искать возможности для обучения как в профессиональной, так и в личной сфере.
Многие работодатели рады, что мы тратим часть своего рабочего времени на изучение чего-то нового, особенно если это может принести им пользу в долгосрочной перспективе. Это привилегия, и не у всех она есть, но многие компании осознают тот факт, что нам нужно время, чтобы отточить навыки в некоторых областях, и неспособность дать это время принесёт ущерб как сотрудникам, так и потенциально продуктам компании.
Мы также можем использовать для этого своё личное время. Оно вам надо? Только вы можете ответить на этот вопрос. Если это приносит пользу лично вам и вашей карьере, возможно, это стоит того. Это путь, который может принести существенные выгоды. В итоге всё зависит от вас, вашего выбора понравившейся блестяшки и вашего графика.
Источник: https://helenjoscott.iss.onedium.com/how-can-you-stay-ahead-of-the-curve-as-a-developer-a27d728980a2
Автор оригинала: Helen Scott
День девятьсот семидесятый. #NuGet
Генерация QR Кодов в .NET
QR коды сегодня повсюду, поэтому часто требуется возможность их генерировать. Сегодня расскажу вам про полезный пакет Net.Codecrete.QrCodeGenerator, позволяющий генерировать QR коды из текста или массива байт буквально в 2 строчки. Библиотека создана для .NET Standard 2.0 и поэтому работает на большинстве современных платформ .NET (.NET Core, .NET Framework, Mono и т.д.).
Основные особенности
- Поддерживает кодирование всех 40 версий (размеров) и всех 4 уровней коррекции ошибок в соответствии со стандартом QR Code Model 2.
- Форматы вывода: чистые пиксели QR символа, строка SVG XML, растровое изображение.
Параметры
- Вы можете указать минимальный и максимальный разрешённый номер версии, и библиотека автоматически выберет наименьшую версию в диапазоне, который соответствует данным.
- Вы можете указать шаблон маски вручную, либо библиотека автоматически оценит все 8 масок и выберет оптимальную.
- Вы можете указать уровень исправления ошибок или, при желании, разрешить библиотеке повышать его, если это не увеличивает номер версии.
- Вы можете создать список сегментов данных вручную и добавить сегменты ECI.
В GitHub проекта есть пример генерации файлов в консольном приложении, но я решил, что пример на сайте более нагляден.
Добавим в проект NuGet пакет:
Генерация QR Кодов в .NET
QR коды сегодня повсюду, поэтому часто требуется возможность их генерировать. Сегодня расскажу вам про полезный пакет Net.Codecrete.QrCodeGenerator, позволяющий генерировать QR коды из текста или массива байт буквально в 2 строчки. Библиотека создана для .NET Standard 2.0 и поэтому работает на большинстве современных платформ .NET (.NET Core, .NET Framework, Mono и т.д.).
Основные особенности
- Поддерживает кодирование всех 40 версий (размеров) и всех 4 уровней коррекции ошибок в соответствии со стандартом QR Code Model 2.
- Форматы вывода: чистые пиксели QR символа, строка SVG XML, растровое изображение.
Параметры
- Вы можете указать минимальный и максимальный разрешённый номер версии, и библиотека автоматически выберет наименьшую версию в диапазоне, который соответствует данным.
- Вы можете указать шаблон маски вручную, либо библиотека автоматически оценит все 8 масок и выберет оптимальную.
- Вы можете указать уровень исправления ошибок или, при желании, разрешить библиотеке повышать его, если это не увеличивает номер версии.
- Вы можете создать список сегментов данных вручную и добавить сегменты ECI.
В GitHub проекта есть пример генерации файлов в консольном приложении, но я решил, что пример на сайте более нагляден.
Добавим в проект NuGet пакет:
dotnet add package Net.Codecrete.QrCodeGenerator --version 1.6.1Создадим простую страничку с формой, принимающей текст, который мы хотим видеть в QR коде, и отображающей сам код после отправки формы:
@model Byte[]QR код передаётся в представление в виде массива байтов и отображается как изображение base64. А вот код метода действия контроллера, обрабатывающего форму:
@using (Html.BeginForm(FormMethod.Post))
{
<label>Текст для QR кода:</label><br />
<input type="text" name="qrText" size="40" />
<button>Сгенерировать</button>
}
@if (Model != null)
{
<label>QR Код Успешно Сгенерирован:</label><br />
<img src="@string.Format("data:image/png;base64,{0}",
Convert.ToBase64String(Model))" />
}
using System.Drawing.Imaging;В методе используем статический метод
using System.IO;
using Net.Codecrete.QrCodeGenerator;
[HttpPost]
public IActionResult Index(string qrText)
{
if (string.IsNullOrEmpty(qrText))
return View();
var qr = QrCode.EncodeText(qrText, QrCode.Ecc.Medium);
var img = qr.ToBitmap(6, 1);
using var stream = new MemoryStream();
img.Save(stream, ImageFormat.Bmp);
return View(stream.ToArray());
}
EncodeText для преобразования текста в QR код. Затем преобразуем изображение в поток байт и отправляем в представление. Получаем результат, как на картинке ниже.День девятьсот семьдесят первый. #Оффтоп
Советы для Продвинутого Пользователя Git. Начало
Хорошо это или плохо, но Git превзошёл другие системы контроля версий, такие как Subversion, Perforce и ClearCase, и стал стандартом системы управления исходным кодом для современного разработчика. Если вы не знакомы ни с одной из этих систем, считайте, что вам повезло жить в эпоху простых локальных ветвлений, поддержки нескольких рабочих процессов и множества распределённых платформ хостинга репозиториев.
Хотя Git легко изучить, его постоянное развитие и широкий спектр возможностей усложняют освоение его продвинутого использования. В результате как новички, так и опытные программисты частенько (вероятно, матерясь) гуглят «как мне это сделать в Git».
В этой серии постов рассмотрим несколько команд для некоторых продвинутых сценариев при работе с репозиторием Git.
1. Клонирование и удалённые URL
Git поддерживает учётные данные Secure Shell (SSH), уникальный криптографический идентификатор для клиентов, при этом большинство ключей создается с использованием алгоритма RSA. Ключи SSH действуют как имя пользователя и пароль для удалённого экземпляра репозитория кода. Для программиста это значит, что имя пользователя и пароль придётся вводить гораздо реже.
При работе с удалёнными репозиториями вы можете случайно клонировать репозиторий, используя HTTPS URL-адрес вместо SSH. Хотя через HTTPS всё равно можно работать, но все пуши в репозиторий потребуют от вас ввода имени пользователя и пароля. Чтобы проверить адрес удалённого репозитория, вы можете использовать Git CLI:
Продолжение следует…
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
Советы для Продвинутого Пользователя Git. Начало
Хорошо это или плохо, но Git превзошёл другие системы контроля версий, такие как Subversion, Perforce и ClearCase, и стал стандартом системы управления исходным кодом для современного разработчика. Если вы не знакомы ни с одной из этих систем, считайте, что вам повезло жить в эпоху простых локальных ветвлений, поддержки нескольких рабочих процессов и множества распределённых платформ хостинга репозиториев.
Хотя Git легко изучить, его постоянное развитие и широкий спектр возможностей усложняют освоение его продвинутого использования. В результате как новички, так и опытные программисты частенько (вероятно, матерясь) гуглят «как мне это сделать в Git».
В этой серии постов рассмотрим несколько команд для некоторых продвинутых сценариев при работе с репозиторием Git.
1. Клонирование и удалённые URL
Git поддерживает учётные данные Secure Shell (SSH), уникальный криптографический идентификатор для клиентов, при этом большинство ключей создается с использованием алгоритма RSA. Ключи SSH действуют как имя пользователя и пароль для удалённого экземпляра репозитория кода. Для программиста это значит, что имя пользователя и пароль придётся вводить гораздо реже.
При работе с удалёнными репозиториями вы можете случайно клонировать репозиторий, используя HTTPS URL-адрес вместо SSH. Хотя через HTTPS всё равно можно работать, но все пуши в репозиторий потребуют от вас ввода имени пользователя и пароля. Чтобы проверить адрес удалённого репозитория, вы можете использовать Git CLI:
> git remote -vЧтобы изменить URL для удалённого источника, вы можете использовать команду set-url. URL-адрес SSH можно найти у вашего Git провайдера. В случае репозиториев GitHub он обычно следует шаблону
origin https://github.com/user/Repo.git (fetch)
origin https://github.com/user/Repo.git (push)
[email protected]:<username>/<repository_name>.git:Вы можете снова запустить команду git remote -v, чтобы убедиться, что URL-адрес обновлён:
> git remote set-url origin [email protected]:user/Repo.git
> git remote -vПри работе в Visual Studio или Rider вы можете использовать меню Git > Manage Remotes.
origin [email protected]:user/Repo.git (fetch)
origin [email protected]:user/Repo.git (push)
Продолжение следует…
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
День девятьсот семьдесят второй. #Оффтоп
Советы для Продвинутого Пользователя Git. Продолжение
Начало
2. Очистить хранилище от всех неотслеживаемых артефактов.
Репозитории проектов могут быстро съедать дисковое пространство из-за артефактов сборки, сторонних зависимостей и неотслеживаемых файлов. Раздутие папок особенно актуально для долгосрочных проектов, которые претерпели множество итераций на вашем компьютере. Для возврата к «чистому» состоянию в папке вашего репозитория можно использовать команду
Предупреждение: убедитесь, что все файлы, которые вы хотите сохранить, зафиксированы; это деструктивная команда без возможности восстановления.
-
-
-
Если вы не хотите запускать команду
3. Исправить орфографические ошибки в сообщениях коммитов
У вас бывало, что вы тратили бесчисленное количество часов, чтобы исправить ошибку, и после этого допускали орфографическую ошибку в сообщении коммита? Такие очепятки сами себя не исправят. Но не волнуйтесь, вы можете исправить последнее сообщение коммита, используя флаг
После коммита неверного сообщения вы можете использовать следующую команду, чтобы изменить его:
Обратите внимание, что эта команда перезаписывает историю Git, поэтому вам придется использовать force push, если вы уже отправили ошибку в удалённый репозиторий.
Окончание следует…
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
Советы для Продвинутого Пользователя Git. Продолжение
Начало
2. Очистить хранилище от всех неотслеживаемых артефактов.
Репозитории проектов могут быстро съедать дисковое пространство из-за артефактов сборки, сторонних зависимостей и неотслеживаемых файлов. Раздутие папок особенно актуально для долгосрочных проектов, которые претерпели множество итераций на вашем компьютере. Для возврата к «чистому» состоянию в папке вашего репозитория можно использовать команду
git clean.Предупреждение: убедитесь, что все файлы, которые вы хотите сохранить, зафиксированы; это деструктивная команда без возможности восстановления.
> git clean -xdfРассмотрим, что означает каждый из флагов:
-
x - Обычно команда clean игнорирует файлы и папки из файла .gitignore репозитория. Этот флаг указывает команде удалить все неотслеживаемые файлы, даже если они игнорируются.-
d - сообщает команде о необходимости рекурсивного просмотра всех каталогов, независимо от того, отслеживаются они или нет.-
f - заставляет команду удалить файлы и каталоги.Если вы не хотите запускать команду
clean, не зная, что она сделает с вашим репозиторием, добавьте флаг n вместе с другими, чтобы выполнить пробный запуск:> git clean -xdfnЭта команда пригодится, если вы покопались в новом репозитории и теперь хотите вернуться к чистому состоянию. В долгосрочных проектах она поможет удалить годы неиспользуемых зависимостей и устаревшие файлы. Но, повторюсь, будьте осторожны при использовании, так как эту операцию нельзя отменить.
Would remove .idea/.idea.Repo/.idea/workspace.xml
Would remove bin/
Would remove obj/
3. Исправить орфографические ошибки в сообщениях коммитов
У вас бывало, что вы тратили бесчисленное количество часов, чтобы исправить ошибку, и после этого допускали орфографическую ошибку в сообщении коммита? Такие очепятки сами себя не исправят. Но не волнуйтесь, вы можете исправить последнее сообщение коммита, используя флаг
--amend.После коммита неверного сообщения вы можете использовать следующую команду, чтобы изменить его:
// Откроет редактор Git по умолчаниюПри использовании Visual Studio или Rider вы можете отметить флажок Amend рядом с сообщением коммита в окне Git Changes (VS) или Commit (Rider). Кроме того, вы можете изменить сообщение коммита в окне Git, где показана история репозитория.
> git commit --amend
// Сразу заменит сообщение коммита
> git commit --amend -m "исправлена ошибка зависимости"
Обратите внимание, что эта команда перезаписывает историю Git, поэтому вам придется использовать force push, если вы уже отправили ошибку в удалённый репозиторий.
Окончание следует…
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
День девятьсот семьдесят третий. #Оффтоп
Советы для Продвинутого Пользователя Git. Окончание
Начало
Продолжение
4. Добавить файлы в предыдущий коммит
Как и при исправлении орфографических ошибок в сообщении коммита, вы иногда можете забыть добавить файл в конкретный коммит. Вместо добавления нового коммита в историю Git вы можете изменить предыдущий коммит, не изменяя сообщение. Сначала нужно добавить все файлы, которые вы хотите добавить в предыдущий коммит.
5. Отменить изменения в ранее зафиксированных файлах
Вы можете начать вносить изменения, а потом обнаружить, что изменения вам больше не нужны. К счастью, вернуться к заведомо исправному состоянию просто:
- В Visual Studio нажмите правой кнопкой мыши на файл в окне Solution Explorer и выберите пункт меню Git > Undo changes.
- В Rider нажмите правой кнопкой мыши на файл в окне Commit и выберите пункт Rollback.
6. Отменить последний локальный коммит Git
Вы работали над важным функционалом, а потом случайно сделали коммит в основную ветку, когда надо было создать новую ветку для функции? Чтобы отменить коммит локально, выполните следующую команду:
Если вы хотите откатить изменения в IDE:
- В Visual Studio в окне Git с историей репозитория нажмите правой кнопкой мыши на предыдущий коммит и выберите Reset. Вам будет предложено 2 варианта: Keep changes (--mixed), который сохранит изменения, или Delete changes (--hard), который удалит все изменения до выбранного коммита.
- В Rider в окне Git выберите коммит и в выпадающем меню выберите Reset Current Branch To Here. Rider предложит дополнительные варианты: soft (вернёт изменения в статус staged), keep (откатит файлы до выбранного коммита, но сохранит локальные изменения).
Как и
Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
Советы для Продвинутого Пользователя Git. Окончание
Начало
Продолжение
4. Добавить файлы в предыдущий коммит
Как и при исправлении орфографических ошибок в сообщении коммита, вы иногда можете забыть добавить файл в конкретный коммит. Вместо добавления нового коммита в историю Git вы можете изменить предыдущий коммит, не изменяя сообщение. Сначала нужно добавить все файлы, которые вы хотите добавить в предыдущий коммит.
> git add .А затем выполнить команду commit с параметрами
amend и no-edit:> git commit --amend --no-editВ Visual Studio или Rider также можно использовать флажок Amend, как и в предыдущем совете. Также, как и предыдущем совете, эта команда изменяет историю Git и может потребовать принудительного пуша, если изменения уже были отправлены в удалённый репозиторий.
5. Отменить изменения в ранее зафиксированных файлах
Вы можете начать вносить изменения, а потом обнаружить, что изменения вам больше не нужны. К счастью, вернуться к заведомо исправному состоянию просто:
> git co Program.csЕсли вы хотите откатить изменения в IDE:
Updated 1 path from the index
- В Visual Studio нажмите правой кнопкой мыши на файл в окне Solution Explorer и выберите пункт меню Git > Undo changes.
- В Rider нажмите правой кнопкой мыши на файл в окне Commit и выберите пункт Rollback.
6. Отменить последний локальный коммит Git
Вы работали над важным функционалом, а потом случайно сделали коммит в основную ветку, когда надо было создать новую ветку для функции? Чтобы отменить коммит локально, выполните следующую команду:
> git reset --soft HEAD~1Git сравнит текущий коммит в HEAD (ваш последний коммит) с коммитом перед ним (предыдущим) и вернёт файлы в статус предыдущего коммита. На этом этапе у вас будет возможность создать новую ветку и правильно сохранить изменения.
Если вы хотите откатить изменения в IDE:
- В Visual Studio в окне Git с историей репозитория нажмите правой кнопкой мыши на предыдущий коммит и выберите Reset. Вам будет предложено 2 варианта: Keep changes (--mixed), который сохранит изменения, или Delete changes (--hard), который удалит все изменения до выбранного коммита.
- В Rider в окне Git выберите коммит и в выпадающем меню выберите Reset Current Branch To Here. Rider предложит дополнительные варианты: soft (вернёт изменения в статус staged), keep (откатит файлы до выбранного коммита, но сохранит локальные изменения).
Как и
amend, команда reset перезапишет историю Git. Но, в отличие от неё, reset используется для защищённых веток, таких как main, которые вы могли случайно изменить локально, но не собирались отправлять изменения в удалённый репозиторий.Источник: https://blog.jetbrains.com/dotnet/2021/09/13/advanced-git-workflow-tips/
День девятьсот семьдесят четвёртый. #ЧтоНовенького
Глобальные Директивы Using в C #10
Размер поста в телеграмме ограничен, поэтому я часто пытаюсь сократить его, насколько это возможно. Больше всего проблем доставляют примеры кода. С одной стороны, хочется показать пример, который можно было бы скопировать и выполнить, и всё бы работало. С другой стороны, C# довольно многословен, в отличие от того же F# или чисто скриптовых языков, например. Поэтому приходится удалять из кода всё лишнее. Это касается в том числе директив using в начале файла. Часто они просто загромождают код и редко добавляют ему какую-то ценность.
В .NET 6 и C #10 появились глобальные директивы
Помните, что эта функция доступна только в .NET 6. Кроме того, на данный момент вам может потребоваться отредактировать файл
При этом некоторые используют файл
Публичное обсуждение функционала ведётся здесь: https://github.com/dotnet/csharplang/issues/3428
Источник: https://dotnetcoretutorials.com/2021/08/19/global-using-statements-in-c10/
Глобальные Директивы Using в C #10
Размер поста в телеграмме ограничен, поэтому я часто пытаюсь сократить его, насколько это возможно. Больше всего проблем доставляют примеры кода. С одной стороны, хочется показать пример, который можно было бы скопировать и выполнить, и всё бы работало. С другой стороны, C# довольно многословен, в отличие от того же F# или чисто скриптовых языков, например. Поэтому приходится удалять из кода всё лишнее. Это касается в том числе директив using в начале файла. Часто они просто загромождают код и редко добавляют ему какую-то ценность.
В .NET 6 и C #10 появились глобальные директивы
using. Теперь вы можете поместить все общие директивы using (в основном, System) в один файл, который будет автоматически доступен для использования в рамках всего проекта.Помните, что эта функция доступна только в .NET 6. Кроме того, на данный момент вам может потребоваться отредактировать файл
.csproj, чтобы разрешить функции в предварительном просмотре (см. LangVersion):<Project Sdk="Microsoft.NET.Sdk">Синтаксис для добавления глобальных директив
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<LangVersion>preview</LangVersion>
</PropertyGroup>
</Project>
using на самом деле довольно прост: добавьте ключевое слово global перед любым using в любом месте, чтобы сделать директиву глобальной.global using System;Интересно, что пока нет чётко определённого места для их размещения. Вы можете поместить их в любой файл в своем проекте, и они сразу станут глобальными везде (в отличие от стандартного AssemblyInfo.cs, который у нас был раньше).
При этом некоторые используют файл
GlobalUsings.cs в корне проекта, содержащий что-нибудь вроде:global using System;Нет ограничений на количество директив using, которые вы можете разместить здесь, или на то, где находится этот файл, но, как правило, неплохо, чтобы этот список был достаточно кратким и содержал только то, что нужно. При этом единственным недостатком добавления сюда всего, что взбредёт в голову, будет то, что IntelliSense может сойти с ума, ну и выдавать вам километровые списки предложений.
global using System.Collections.Generic;
global using System.IO;
global using System.Linq;
Публичное обсуждение функционала ведётся здесь: https://github.com/dotnet/csharplang/issues/3428
Источник: https://dotnetcoretutorials.com/2021/08/19/global-using-statements-in-c10/
День девятьсот семьдесят пятый. #Оффтоп
Интервью - Это Плохой Способ Нанять Программиста
Давненько мы ничего не обсуждали по поводу собесов. А тут первый день октября, пятница. Почему бы и нет?
Тему на этот раз дал ютубер и программист из Нидерландов Алексей Корепанов. Вот его канал, если что.
Тема такая: "Собеседования - это плохой способ найти подходящего программиста". Но другие - ещё хуже. Что не так с техническими интервью и есть ли им какая-то замена?
В подробностях расписывать не буду, мысли автора есть в видео по ссылке ниже. Выскажу лишь своё отношение. Мне не приходилось быть «с другой стороны», в смысле собеседующим. Да и не сказать, что у меня за плечами сотни (или хотя бы десятки) пройденных собеседований. Но в принципе, я с автором видео согласен. И мем про то, что на собеседовании вас просят развернуть бинарное дерево, а потом на работе «сделать вот эту кнопочку побольше», думаю, не так далёк от истины.
Но действительно, есть ли какие-нибудь альтернативы? В принципе, в видео предложена одна, которая мне лично пришлась бы по душе: поработать на испытательном сроке. Но я бы развил эту мысль. Короткое (до получаса) собеседование всё же нужно, чтобы отсеять совсем уж непроходные варианты. А потом день-два (оплачиваемых) поработать уже в реальных боевых условиях.
Понятно, что далеко не каждая компания согласится платить человеку с улицы, который совсем не факт, что подойдёт. Но фактически ведь реальные навыки кандидата, и то, насколько они будут полезны для конкретной компании и конкретной команды, всё равно можно узнать только так. Тогда стоит ли тратить несколько часов своих специалистов, чтобы гонять десятки кандидатов по внутреннему устройству сборщика мусора?
Есть, конечно, вариант тестового задания. Но тут перекос в другую сторону. Либо оно будет настолько тривиальное, что не позволит адекватно оценить навыки. Либо это будет разработка полноценного (пусть небольшого) приложения, на которое кандидат должен будет потратить несколько часов, а то и весь день (читал про такой случай, по-моему, на Хабре, после чего кандидата просто отшили без особых пояснений). А если оно оплачиваемое, то зачем писать код, который потом всё равно выкинут? Понятно, что есть нюансы о коммерческой тайне, но думаю, их можно утрясти или не допускать кандидатов к секретным частям.
Что скажете? Были ли у вас интересные собеседования, которые хотелось пройти ещё раз или чем бы вы заменили собеседования?
Источник: https://www.youtube.com/watch?v=GdV-H0uDHZc
Интервью - Это Плохой Способ Нанять Программиста
Давненько мы ничего не обсуждали по поводу собесов. А тут первый день октября, пятница. Почему бы и нет?
Тему на этот раз дал ютубер и программист из Нидерландов Алексей Корепанов. Вот его канал, если что.
Тема такая: "Собеседования - это плохой способ найти подходящего программиста". Но другие - ещё хуже. Что не так с техническими интервью и есть ли им какая-то замена?
В подробностях расписывать не буду, мысли автора есть в видео по ссылке ниже. Выскажу лишь своё отношение. Мне не приходилось быть «с другой стороны», в смысле собеседующим. Да и не сказать, что у меня за плечами сотни (или хотя бы десятки) пройденных собеседований. Но в принципе, я с автором видео согласен. И мем про то, что на собеседовании вас просят развернуть бинарное дерево, а потом на работе «сделать вот эту кнопочку побольше», думаю, не так далёк от истины.
Но действительно, есть ли какие-нибудь альтернативы? В принципе, в видео предложена одна, которая мне лично пришлась бы по душе: поработать на испытательном сроке. Но я бы развил эту мысль. Короткое (до получаса) собеседование всё же нужно, чтобы отсеять совсем уж непроходные варианты. А потом день-два (оплачиваемых) поработать уже в реальных боевых условиях.
Понятно, что далеко не каждая компания согласится платить человеку с улицы, который совсем не факт, что подойдёт. Но фактически ведь реальные навыки кандидата, и то, насколько они будут полезны для конкретной компании и конкретной команды, всё равно можно узнать только так. Тогда стоит ли тратить несколько часов своих специалистов, чтобы гонять десятки кандидатов по внутреннему устройству сборщика мусора?
Есть, конечно, вариант тестового задания. Но тут перекос в другую сторону. Либо оно будет настолько тривиальное, что не позволит адекватно оценить навыки. Либо это будет разработка полноценного (пусть небольшого) приложения, на которое кандидат должен будет потратить несколько часов, а то и весь день (читал про такой случай, по-моему, на Хабре, после чего кандидата просто отшили без особых пояснений). А если оно оплачиваемое, то зачем писать код, который потом всё равно выкинут? Понятно, что есть нюансы о коммерческой тайне, но думаю, их можно утрясти или не допускать кандидатов к секретным частям.
Что скажете? Были ли у вас интересные собеседования, которые хотелось пройти ещё раз или чем бы вы заменили собеседования?
Источник: https://www.youtube.com/watch?v=GdV-H0uDHZc
День девятьсот семьдесят шестой.
Юнит-Тесты Приватных Методов и Абстракций
Большинство специалистов советуют проводить юнит-тесты только публичного API класса. Тестирование закрытых методов приводит к привязке ваших тестов к деталям реализации, что приводит к ложным срабатываниям, что, в свою очередь, снижает точность и ценность теста.
где
-
-
Вместо того, чтобы напрямую тестировать закрытые методы, вы должны тестировать их косвенно, как часть общего наблюдаемого поведения (с использованием публичного API класса).
Однако тогда возникают вопросы:
- Что, если закрытые методы содержат важную логику, требующую тестирования?
- Что, если эта логика слишком сложна и её тестирование как часть наблюдаемого поведения класса не обеспечивает достаточного покрытия?
- Как тогда её протестировать?
Обычно такая сложность закрытых методов является признаком отсутствующей абстракции, которую следует выделить в отдельный класс. Допустим, у нас есть класс заказа, в котором есть закрытый метод расчёта стоимости с учётом всех возможных скидок. А публичный API только показывает итоговый результат. В этом случае вместо того, чтобы открывать метод расчёта стоимости, лучше сделать эту абстракцию явной, введя класс «калькулятор стоимости».
Некоторые могут возразить, что извлечение закрытого метода в общедоступный класс не является решением, поскольку вы в любом случае делаете логику общедоступной. Следовательно, раскрытие закрытого метода ничем не отличается от извлечения класса?
Нет. Модульные тесты – не единственная причина, по которой вы могли бы извлечь закрытый метод в класс. Чтобы понять почему, доведём этот аргумент до крайности. Допустим, в вашем проекте нет модульных тестов. Означает ли это, что весь код можно хранить в одном гигантском классе? Вы всё ещё можете разделить его на закрытые методы, так почему бы и нет?
Конечно, это было бы ужасным решением, потому что абстракции (представленные в виде отдельных классов) полезны независимо от того, нужно ли вам тестировать эти абстракции. Они помогают структурировать проект и сохранять контроль над его сложностью.
Таким образом, необходимость модульного тестирования закрытого метода является лишь намёком на отсутствующую (или неуместную) абстракцию. Эта необходимость сама по себе не является требованием для создания такой абстракции.
Другими словами, дизайн кода всегда идёт на первом месте. Модульные тесты просто помогают выявить проблемы с этим дизайном. Даже без модульных тестов было бы неплохо выделить сложный закрытый метод в отдельный класс. Тесты просто явно указывают на это.
Источник: https://www.getdrip.com/deliveries/kjdniknl44vo4fplhd26
Автор оригинала: Vladimir Khorikov
Юнит-Тесты Приватных Методов и Абстракций
Большинство специалистов советуют проводить юнит-тесты только публичного API класса. Тестирование закрытых методов приводит к привязке ваших тестов к деталям реализации, что приводит к ложным срабатываниям, что, в свою очередь, снижает точность и ценность теста.
Ценность теста = сигнал/шум,где
-
сигнал – количество найденных ошибок,-
шум – количество ложных срабатываний.Вместо того, чтобы напрямую тестировать закрытые методы, вы должны тестировать их косвенно, как часть общего наблюдаемого поведения (с использованием публичного API класса).
Однако тогда возникают вопросы:
- Что, если закрытые методы содержат важную логику, требующую тестирования?
- Что, если эта логика слишком сложна и её тестирование как часть наблюдаемого поведения класса не обеспечивает достаточного покрытия?
- Как тогда её протестировать?
Обычно такая сложность закрытых методов является признаком отсутствующей абстракции, которую следует выделить в отдельный класс. Допустим, у нас есть класс заказа, в котором есть закрытый метод расчёта стоимости с учётом всех возможных скидок. А публичный API только показывает итоговый результат. В этом случае вместо того, чтобы открывать метод расчёта стоимости, лучше сделать эту абстракцию явной, введя класс «калькулятор стоимости».
Некоторые могут возразить, что извлечение закрытого метода в общедоступный класс не является решением, поскольку вы в любом случае делаете логику общедоступной. Следовательно, раскрытие закрытого метода ничем не отличается от извлечения класса?
Нет. Модульные тесты – не единственная причина, по которой вы могли бы извлечь закрытый метод в класс. Чтобы понять почему, доведём этот аргумент до крайности. Допустим, в вашем проекте нет модульных тестов. Означает ли это, что весь код можно хранить в одном гигантском классе? Вы всё ещё можете разделить его на закрытые методы, так почему бы и нет?
Конечно, это было бы ужасным решением, потому что абстракции (представленные в виде отдельных классов) полезны независимо от того, нужно ли вам тестировать эти абстракции. Они помогают структурировать проект и сохранять контроль над его сложностью.
Таким образом, необходимость модульного тестирования закрытого метода является лишь намёком на отсутствующую (или неуместную) абстракцию. Эта необходимость сама по себе не является требованием для создания такой абстракции.
Другими словами, дизайн кода всегда идёт на первом месте. Модульные тесты просто помогают выявить проблемы с этим дизайном. Даже без модульных тестов было бы неплохо выделить сложный закрытый метод в отдельный класс. Тесты просто явно указывают на это.
Источник: https://www.getdrip.com/deliveries/kjdniknl44vo4fplhd26
Автор оригинала: Vladimir Khorikov
День девятьсот семьдесят седьмой. #ЧтоНовенького
Неявные Директивы Using в .NET 6
Недавно мы говорили о возможности использовать global using в C #10. Так почему бы не включать эту функцию сразу же при создании нового проекта в .NET 6? Если вы создаёте новый веб-проект, появляется много автоматически сгенерированных как часть шаблона файлов. Логично было бы явно создавать файл
В .NET 6 решили проблему немного по-другому. Новый функционал неявных директив using создаёт скрытый автоматически сгенерированный файл внутри папки
Заметьте, что т.к. это автоматически созданный файл, мы не можем его здесь редактировать. Но мы видим, что он объявляет за нас целую кучу глобальных директив using. Каждый тип проекта будет иметь свой набор глобальных директив. Например, в веб проект добавятся
Если мы попытаемся импортировать пространство имен, которое уже есть в этом файле, мы получим обычное предупреждение:
CS0105: The using directive for 'System' appeared previously in this namespace
Отключение
Если вы используете .NET 6 и C #10, то эта функция включена по умолчанию. Но что, если вы захотите отключить её? Это может быть полезно, если автоматически импортируемое пространство имён имеет тип, который конфликтует с типом, который вы сами хотите объявить. Это можно сделать в файле
Это хорошая функция?
Сложно сказать. Придумывали её люди намного умнее меня, и наверняка они знают, что делают. Когда появлялись такие вещи, как дженерики, лямбда-выражения, async/await, они тоже были непривычны и непонятны.
С одной стороны, мне нравится, что каждый тип проекта имеет свой набор подключённых по умолчанию пространств имён. Если вы, например, активно используете async/await, то импорт
При этом настораживает «скрытая» сущность функционала. Я почти уверен, что StackOverflow будет переполнен вопросами, почему компилятор говорит, что System уже импортирован, хотя его импорта нигде не найти. Кроме того, после обновления существующего решения с .NET 5 на .NET 6 функция автоматически включится… ну такое.
При этом, может быть, через годы мы просто привыкнем к этому, и это просто станет «частью .NET», как и многие другие вещи. Что думаете?
Источник: https://dotnetcoretutorials.com/2021/08/31/implicit-using-statements-in-net-6/
Неявные Директивы Using в .NET 6
Недавно мы говорили о возможности использовать global using в C #10. Так почему бы не включать эту функцию сразу же при создании нового проекта в .NET 6? Если вы создаёте новый веб-проект, появляется много автоматически сгенерированных как часть шаблона файлов. Логично было бы явно создавать файл
GlobalUsings.cs, верно?В .NET 6 решили проблему немного по-другому. Новый функционал неявных директив using создаёт скрытый автоматически сгенерированный файл внутри папки
obj, который за кулисами объявляет глобальные директивы using. После сборки проекта в obj/Debug/net6.0 появится файл<имя_проекта>.ImplicitNamespaceImports.cs, со примерно таким содержимым:global using global::System;…
global using global::System.Collections.Generic;
global using global::System.IO;
Заметьте, что т.к. это автоматически созданный файл, мы не можем его здесь редактировать. Но мы видим, что он объявляет за нас целую кучу глобальных директив using. Каждый тип проекта будет иметь свой набор глобальных директив. Например, в веб проект добавятся
System.Net.Http.Jsonи т.п.
Microsoft.AspNetCore.Hosting
Microsoft.Extensions.Configuration
Microsoft.Extensions.DependencyInjection
Если мы попытаемся импортировать пространство имен, которое уже есть в этом файле, мы получим обычное предупреждение:
CS0105: The using directive for 'System' appeared previously in this namespace
Отключение
Если вы используете .NET 6 и C #10, то эта функция включена по умолчанию. Но что, если вы захотите отключить её? Это может быть полезно, если автоматически импортируемое пространство имён имеет тип, который конфликтует с типом, который вы сами хотите объявить. Это можно сделать в файле
.csproj. Можно либо отключить функцию полностью:<PropertyGroup>Либо выбрать, какие пространства имён включать, а какие нет:
…
<DisableImplicitNamespaceImports>true</DisableImplicitNamespaceImports>
</PropertyGroup>
<ItemGroup>Это также может быть заменой обсуждённому в предыдущем посте файлу
<Import Remove="System.Threading" />
<Import Include="Microsoft.Extensions.Logging" />
</ItemGroup>
GlobalUsings.cs, но в этом варианте, в недрах файла .csproj, это более «скрыто».Это хорошая функция?
Сложно сказать. Придумывали её люди намного умнее меня, и наверняка они знают, что делают. Когда появлялись такие вещи, как дженерики, лямбда-выражения, async/await, они тоже были непривычны и непонятны.
С одной стороны, мне нравится, что каждый тип проекта имеет свой набор подключённых по умолчанию пространств имён. Если вы, например, активно используете async/await, то импорт
System.Threading.Tasks потребуется чуть ли не в каждом файле, поскольку ваши методы должны возвращать тип Task.При этом настораживает «скрытая» сущность функционала. Я почти уверен, что StackOverflow будет переполнен вопросами, почему компилятор говорит, что System уже импортирован, хотя его импорта нигде не найти. Кроме того, после обновления существующего решения с .NET 5 на .NET 6 функция автоматически включится… ну такое.
При этом, может быть, через годы мы просто привыкнем к этому, и это просто станет «частью .NET», как и многие другие вещи. Что думаете?
Источник: https://dotnetcoretutorials.com/2021/08/31/implicit-using-statements-in-net-6/
День девятьсот семьдесят восьмой. #ЗаметкиНаПолях #AsyncTips
В этой серии постов будут выдержки из книги Стивена Клири. Просто разнообразные советы по работе с асинхронным кодом.
Возвращение завершённых задач
Задача: реализовать синхронный метод с асинхронной сигнатурой. Например, при модульном тестировании асинхронного кода, когда нужна простая заглушка или имитированная реализация для асинхронного интерфейса.
Решение:
1. Для возврата значения - использовать Task.FromResult:
Если вы регулярно используете
Помимо этого, иногда требуется протестировать асинхронное поведение метода. В этом поможет
В этой серии постов будут выдержки из книги Стивена Клири. Просто разнообразные советы по работе с асинхронным кодом.
Возвращение завершённых задач
Задача: реализовать синхронный метод с асинхронной сигнатурой. Например, при модульном тестировании асинхронного кода, когда нужна простая заглушка или имитированная реализация для асинхронного интерфейса.
Решение:
1. Для возврата значения - использовать Task.FromResult:
public Task<int> GetValueAsync()2. Для методов, не имеющих возвращаемого значения - Task.CompletedTask:
=> Task.FromResult(42);
public Task DoSomethingAsync()3. Для возврата исключения - Task.FromException:
=> Task.CompletedTask;
public Task<T> ThrowsAsync<T>()4. Для отменённых задач - Task.FromCanceled:
=> Task.FromException<T>(new Exception());
public Task<int> GetValueAsync(CancellationToken ct) {
if (ct.IsCancellationRequested)
return Task.FromCanceled<int>(ct);
return Task.FromResult(13);
}
Если в синхронной реализации может произойти отказ, перехватывайте исключения и используйте Task.FromException:public Task DoSomethingAsync() {
try {
DoSomethingSynchronously();
return Task.CompletedTask;
}
catch (Exception ex)
{
return Task.FromException(ex);
}
}
Если вы реализуете асинхронный интерфейс синхронным кодом, избегайте любых форм блокировки. Избегайте блокирования с последующим возвращением завершённой задачи в асинхронном методе, если метод может быть реализован асинхронно. Если асинхронный метод блокируется, он не позволяет вызывающему потоку запускать другие задачи, что противоречит идее конкурентности и может привести к взаимоблокировке.Если вы регулярно используете
Task.FromResult, задачу можно кэшировать, чтобы не создавать объекты Task каждый раз:private static readonly Task<int> zeroTaskНа логическом уровне
= Task.FromResult(0);
…
Task<int> GetValueAsync()
=> zeroTask;
Task.FromResult, Task.FromException и Task.FromCanceled являются вспомогательными методами и сокращёнными формами обобщённого типа TaskCompletionSource<T>. TaskCompletionSource<T> представляет собой низкоуровневый тип, полезный для взаимодействия с другими формами асинхронного кода. В общем случае следует применять сокращенную форму Task.FromResult и родственные формы, если хотите вернуть уже завершённую задачу. TaskCompletionSource<T> используется для возвращения задачи, которая завершается в некоторый момент в будущем.Помимо этого, иногда требуется протестировать асинхронное поведение метода. В этом поможет
Task.Yield. Заметьте, что в отличие от вышеупомянутых методов, этот метод помечен как асинхронный и содержит await:public async Task<int> DoSomethingAsync()Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 2.
{
// Принудительно включить асинхронное поведение
await Task.Yield();
return 13;
}
День девятьсот семьдесят девятый. #Оффтоп #CodeReview
Обзоры Кода. Передовой Опыт. Начало
Обзоры кода - это процесс, в котором один или несколько разработчиков систематически проверяют код, написанный другим разработчиком, для обнаружения дефектов и улучшения кода. Обзоры кода чаще выполняются опытными разработчиками, которые учитывают различные аспекты, включая качество и безопасность кода. Кроме того, они способствуют обмену знаниями, лучшей кооперации, формированию культуры взаимных проверок, укреплению уверенности команды в коде, над которым они работают.
Затраты на обзор кода
Помимо анализа кода, есть ещё два хорошо известных метода, использующихся в процессе разработки.
- Написание тестов для частой и автоматической проверки нового и отредактированного кода.
- Использование инструментов, которые проверяют код, на предмет «запахов» и ошибок.
В отличие от тестов и инструментов анализа, обзор кода, выполняемый человеком, может рассматриваться как попытка учуять запах дыма. По аналогии с дымовым тестированием (Smoke testing). Это значит, что вручную выполняется поверхностная проверка определённого функционала на наличие явных ошибок. При изменении кода его нужно проводить снова, точно так же, как обзор кода. По этой причине обзор кода - дорогостоящая задача, поскольку требует человеческих ресурсов и должна повторяться снова и снова после каждого изменения кода.
Преимущества обзоров кода
Стоимость обзоров кода высока. С другой стороны, преимущества довольно ощутимы:
1. Обучение
При обзорах кода младшие программисты получают советы от старших относительно их собственного кода. Нет лучшего способа изучить правильные методы и продвигать принципы и требования корпоративного стиля.
2. Коммуникация
При обзорах кода программисты непременно общаются друг с другом и делятся мнениями. Это способствует развитию дружеских отношений и улучшает сплочённость команды.
3. Распространение знаний
Каждая команда должна бороться с единоличным владением кодом, т.е. когда один человек владеет какой-то кодовой базой или компонентом. Владение кодом вызывает трения и стресс как для владельца кода, так и для его/её коллег. Владелец больше не учится у других и может лениться, поскольку его работа не оценивается другими. С другой стороны, другие могут столкнуться с серьёзной проблемой, когда владелец отсутствует или покидает команду. Проверка кода - лучший способ распространения знаний и предотвращения владения кодом.
4. Мотивация к прогрессу
Очевидно, что, если вы знаете, что ваш код будет проверяться коллегами, вы уделите ему больше внимания. Вы потратите время на то, чтобы правильно назвать идентификаторы, написать тесты, ввести хорошо продуманные абстракции и тщательно использовать корпоративные шаблоны.
5. Лучший код
Поскольку в основе анализа кода лежат интеллект, опыт и внимание разработчика, он может помочь на ранней стадии обнаружить дефекты, которые нельзя обнаружить с помощью тестирования и автоматизированных инструментов.
При обзорах кода не только улучшается результирующий код, но и прогрессирует каждый член команды как разработчик. Такие чисто человеческие преимущества не могут быть получены с помощью другой практики. Однако они могут стать решающим фактором между успешным проектом и провалом. Таким образом, обзоры кода, вне зависимости от их стоимости могут стоить того.
Продолжение следует…
Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/
Обзоры Кода. Передовой Опыт. Начало
Обзоры кода - это процесс, в котором один или несколько разработчиков систематически проверяют код, написанный другим разработчиком, для обнаружения дефектов и улучшения кода. Обзоры кода чаще выполняются опытными разработчиками, которые учитывают различные аспекты, включая качество и безопасность кода. Кроме того, они способствуют обмену знаниями, лучшей кооперации, формированию культуры взаимных проверок, укреплению уверенности команды в коде, над которым они работают.
Затраты на обзор кода
Помимо анализа кода, есть ещё два хорошо известных метода, использующихся в процессе разработки.
- Написание тестов для частой и автоматической проверки нового и отредактированного кода.
- Использование инструментов, которые проверяют код, на предмет «запахов» и ошибок.
В отличие от тестов и инструментов анализа, обзор кода, выполняемый человеком, может рассматриваться как попытка учуять запах дыма. По аналогии с дымовым тестированием (Smoke testing). Это значит, что вручную выполняется поверхностная проверка определённого функционала на наличие явных ошибок. При изменении кода его нужно проводить снова, точно так же, как обзор кода. По этой причине обзор кода - дорогостоящая задача, поскольку требует человеческих ресурсов и должна повторяться снова и снова после каждого изменения кода.
Преимущества обзоров кода
Стоимость обзоров кода высока. С другой стороны, преимущества довольно ощутимы:
1. Обучение
При обзорах кода младшие программисты получают советы от старших относительно их собственного кода. Нет лучшего способа изучить правильные методы и продвигать принципы и требования корпоративного стиля.
2. Коммуникация
При обзорах кода программисты непременно общаются друг с другом и делятся мнениями. Это способствует развитию дружеских отношений и улучшает сплочённость команды.
3. Распространение знаний
Каждая команда должна бороться с единоличным владением кодом, т.е. когда один человек владеет какой-то кодовой базой или компонентом. Владение кодом вызывает трения и стресс как для владельца кода, так и для его/её коллег. Владелец больше не учится у других и может лениться, поскольку его работа не оценивается другими. С другой стороны, другие могут столкнуться с серьёзной проблемой, когда владелец отсутствует или покидает команду. Проверка кода - лучший способ распространения знаний и предотвращения владения кодом.
4. Мотивация к прогрессу
Очевидно, что, если вы знаете, что ваш код будет проверяться коллегами, вы уделите ему больше внимания. Вы потратите время на то, чтобы правильно назвать идентификаторы, написать тесты, ввести хорошо продуманные абстракции и тщательно использовать корпоративные шаблоны.
5. Лучший код
Поскольку в основе анализа кода лежат интеллект, опыт и внимание разработчика, он может помочь на ранней стадии обнаружить дефекты, которые нельзя обнаружить с помощью тестирования и автоматизированных инструментов.
При обзорах кода не только улучшается результирующий код, но и прогрессирует каждый член команды как разработчик. Такие чисто человеческие преимущества не могут быть получены с помощью другой практики. Однако они могут стать решающим фактором между успешным проектом и провалом. Таким образом, обзоры кода, вне зависимости от их стоимости могут стоить того.
Продолжение следует…
Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/
👍1
День девятьсот семьдесят девятый. Часть 2.
Конференция Dotnetos 2021
Вопреки обыкновению, второй пост за сегодня. Потому что раньше я это как-то упустил, а завтра уже будет поздно. Расписание семинаров конференции Dotnetos 2021 от Конрода Кокосы и ко.
Вторник, 5 октября:
5 PM - 5:45 PM CEST (18:00 - 18:45 мск)
Kevin Gosse - Debugging one layer deeper
https://www.youtube.com/watch?v=nahz_LCSo0U
6 PM - 6:45 PM CEST (19:00 - 19:45 мск)
Jared Parsons - Performance features in C#
https://www.youtube.com/watch?v=Q_tvcyl-e60
7 PM - 7:45 PM CEST (20:00 - 20:45 мск)
David Fowler - Turtles all the way down: You don’t need to understand the details of .NET. Until you do
https://www.youtube.com/watch?v=Uyg4_4TZINE
8 PM - 8:45 PM CEST (21:00 - 21:45 мск)
Jiří Činčura - How I put .NET into Firebird database engine
https://www.youtube.com/watch?v=5Qw6l8M-nJU
Среда, 6 октября:
5 PM - 5:45 PM CEST (18:00 - 18:45 мск)
Oren Eini - Performance Architecture
https://www.youtube.com/watch?v=KIErf6b2RoI
6 PM - 6:45 PM CEST (19:00 - 19:45 мск)
Oleg Karasik - Making fun with parallelism in .NET
https://www.youtube.com/watch?v=nEFwG3jpUiQ
7 PM - 7:45 PM CEST (20:00 - 20:45 мск)
Reuben Bond - A Deep Dive into Orleans
https://www.youtube.com/watch?v=kgRag4E6b4c
8 PM - 8:45 PM CEST (21:00 - 21:45 мск)
Adam Furmanek - Hacking C# from the inside
https://www.youtube.com/watch?v=uYdmtqFbU8M
Конференция Dotnetos 2021
Вопреки обыкновению, второй пост за сегодня. Потому что раньше я это как-то упустил, а завтра уже будет поздно. Расписание семинаров конференции Dotnetos 2021 от Конрода Кокосы и ко.
Вторник, 5 октября:
5 PM - 5:45 PM CEST (18:00 - 18:45 мск)
Kevin Gosse - Debugging one layer deeper
https://www.youtube.com/watch?v=nahz_LCSo0U
6 PM - 6:45 PM CEST (19:00 - 19:45 мск)
Jared Parsons - Performance features in C#
https://www.youtube.com/watch?v=Q_tvcyl-e60
7 PM - 7:45 PM CEST (20:00 - 20:45 мск)
David Fowler - Turtles all the way down: You don’t need to understand the details of .NET. Until you do
https://www.youtube.com/watch?v=Uyg4_4TZINE
8 PM - 8:45 PM CEST (21:00 - 21:45 мск)
Jiří Činčura - How I put .NET into Firebird database engine
https://www.youtube.com/watch?v=5Qw6l8M-nJU
Среда, 6 октября:
5 PM - 5:45 PM CEST (18:00 - 18:45 мск)
Oren Eini - Performance Architecture
https://www.youtube.com/watch?v=KIErf6b2RoI
6 PM - 6:45 PM CEST (19:00 - 19:45 мск)
Oleg Karasik - Making fun with parallelism in .NET
https://www.youtube.com/watch?v=nEFwG3jpUiQ
7 PM - 7:45 PM CEST (20:00 - 20:45 мск)
Reuben Bond - A Deep Dive into Orleans
https://www.youtube.com/watch?v=kgRag4E6b4c
8 PM - 8:45 PM CEST (21:00 - 21:45 мск)
Adam Furmanek - Hacking C# from the inside
https://www.youtube.com/watch?v=uYdmtqFbU8M
День девятьсот восьмидесятый. #Оффтоп #CodeReview
Обзоры Кода. Передовой Опыт. Продолжение
Начало
Как проводить обзор кода
1. Уведомление о том, что код готов к обзору
Часто обзор кода проводится неформально. Когда разработчик завершает какую-то часть кодирования, он уведомляет одного или нескольких членов команды, чтобы они проверили код, когда смогут. Неплохо для начала, но такие обзоры не являются систематическими, плохо отслеживаются и не поддаются измерению.
2. Обзор «через плечо»
В отличие от предыдущего способа, обзор «через плечо» предполагает синхронную проверку. Он заключается в том, чтобы попросить одного или нескольких разработчиков присоединиться, чтобы представить им сделанную работу и получить комментарии. В идеале коллега присоединяется физически, но в настоящее время многие разработчики работают из дома, и такой обзор может проводиться удалённо. Обзор «через плечо» страдает теми же недостатками неформальности, что и предыдущий способ. Однако он побуждает разработчика участвовать в реальном обсуждении, а не просто отправить комментарии по почте когда-нибудь потом, что лучше для командной работы.
3. Парное программирование
Парное программирование - это метод гибкой разработки программного обеспечения, пришедший из XP (Extreme Programming). Парное программирование предполагает команду из двух разработчиков, работающих вместе на одном компьютере. Они объединяют свои усилия для написания кода и тестов. Это является одной из форм проверки кода, поскольку клавиатура одна: один проверяет код, написанный другим.
Парное программирование имеет несколько преимуществ. Это отличный способ наставить младшего разработчика и как можно раньше выявить некоторые дефекты.
С другой стороны, разработчики часто достигают пика своей продуктивности, когда они одни, «в потоке», и когда их не отвлекают. Таким образом, систематическое парное программирование снижает продуктивность и снижает энтузиазм разработчиков. Код, написанный одним разработчиком «в потоке», все равно может быть пересмотрен и улучшен позже другими.
4. Инструменты для автоматической проверки кода
Инструменты автоматической проверки кода помогают серьёзно улучшить процесс обзора кода. С помощью инструментов обзоры могут стать систематическими. Их можно отследить, и можно сделать вывод о том, как улучшить процесс на основании некоторых показателей. Пул-реквесты в Github сейчас популярный способ проведения большинства проверок. Существуют также более сложные инструменты, такие как SmartBear Collaborator с широким спектром поддерживаемых систем управления версиями.
Однако обратная сторона обзора кода - его высокая стоимость, поскольку он требует больших человеческих усилий. Вот почему команда должна бороться за автоматизацию большинства проверок, чтобы максимально снизить человеческое участие. Другой инструмент – NDepend - анализирует многие аспекты кода, такие как именование, сложность, дизайн, запахи кода, покрытие кода тестами и т.п. При этом он создаёт моментальные снимки кода. Два моментальных снимка можно сравнить между собой. Инструмент также поддерживает LINQ-подобные запросы для оценки качества кода. Например, перед любой проверкой кода человеком, можно внедрить правило проверки на сложность методов с помощью запроса ниже:
Окончание следует…
Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/
Обзоры Кода. Передовой Опыт. Продолжение
Начало
Как проводить обзор кода
1. Уведомление о том, что код готов к обзору
Часто обзор кода проводится неформально. Когда разработчик завершает какую-то часть кодирования, он уведомляет одного или нескольких членов команды, чтобы они проверили код, когда смогут. Неплохо для начала, но такие обзоры не являются систематическими, плохо отслеживаются и не поддаются измерению.
2. Обзор «через плечо»
В отличие от предыдущего способа, обзор «через плечо» предполагает синхронную проверку. Он заключается в том, чтобы попросить одного или нескольких разработчиков присоединиться, чтобы представить им сделанную работу и получить комментарии. В идеале коллега присоединяется физически, но в настоящее время многие разработчики работают из дома, и такой обзор может проводиться удалённо. Обзор «через плечо» страдает теми же недостатками неформальности, что и предыдущий способ. Однако он побуждает разработчика участвовать в реальном обсуждении, а не просто отправить комментарии по почте когда-нибудь потом, что лучше для командной работы.
3. Парное программирование
Парное программирование - это метод гибкой разработки программного обеспечения, пришедший из XP (Extreme Programming). Парное программирование предполагает команду из двух разработчиков, работающих вместе на одном компьютере. Они объединяют свои усилия для написания кода и тестов. Это является одной из форм проверки кода, поскольку клавиатура одна: один проверяет код, написанный другим.
Парное программирование имеет несколько преимуществ. Это отличный способ наставить младшего разработчика и как можно раньше выявить некоторые дефекты.
С другой стороны, разработчики часто достигают пика своей продуктивности, когда они одни, «в потоке», и когда их не отвлекают. Таким образом, систематическое парное программирование снижает продуктивность и снижает энтузиазм разработчиков. Код, написанный одним разработчиком «в потоке», все равно может быть пересмотрен и улучшен позже другими.
4. Инструменты для автоматической проверки кода
Инструменты автоматической проверки кода помогают серьёзно улучшить процесс обзора кода. С помощью инструментов обзоры могут стать систематическими. Их можно отследить, и можно сделать вывод о том, как улучшить процесс на основании некоторых показателей. Пул-реквесты в Github сейчас популярный способ проведения большинства проверок. Существуют также более сложные инструменты, такие как SmartBear Collaborator с широким спектром поддерживаемых систем управления версиями.
Однако обратная сторона обзора кода - его высокая стоимость, поскольку он требует больших человеческих усилий. Вот почему команда должна бороться за автоматизацию большинства проверок, чтобы максимально снизить человеческое участие. Другой инструмент – NDepend - анализирует многие аспекты кода, такие как именование, сложность, дизайн, запахи кода, покрытие кода тестами и т.п. При этом он создаёт моментальные снимки кода. Два моментальных снимка можно сравнить между собой. Инструмент также поддерживает LINQ-подобные запросы для оценки качества кода. Например, перед любой проверкой кода человеком, можно внедрить правило проверки на сложность методов с помощью запроса ниже:
// <Name>Avoid complex methods</Name>Строка
warnif count > 0
from m in JustMyCode.Methods
where m.CyclomaticComplexity > 20
select new { m, m.CyclomaticComplexity, m.NbLinesOfCode }
warnif count > 0 автоматически переводит запрос в правило, которое выдаст предупреждение компилятора.Окончание следует…
Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/
День девятьсот восемьдесят первый. #Оффтоп #CodeReview
Обзоры Кода. Передовой Опыт. Окончание
Начало
Продолжение
На что обращать внимание при обзоре кода
Многие аспекты проверки кода можно автоматизировать, но человеческие навыки и опыт остаются критичными для обнаружения важных улучшений:
1. Ошибки требований
Разработчик мог неправильно понять некоторые требования. Его код может быть протестирован на 100%, но, если и код, и написанные тесты основаны на неправильных предположениях, задача не может считаться выполненной.
2. Изменения пользовательского интерфейса
Создание правильного UI, который сделает пользователей продуктивными, - одна из самых сложных задач разработки. Проверка кода и проверка UI специалистами команды являются обязательными, чтобы убедиться, что продукт развивается в правильном направлении.
3. Трудно находимые ошибки
Ошибки, связанные с параллельной обработкой (взаимоблокировки, состояния гонки и т.п.), трудно обнаружить, трудно воспроизвести и трудно исправить. Младшие разработчики часто их допускают, даже не подозревая, что они могут произойти. При обзоре кода опытный программист сможет оценить, возможно ли возникновение ошибки. Например, он проверит изменение общего состояния и чистоту метода. Также могут быть обнаружены некоторые другие сложные ошибки, включая утечку памяти и проблемы производительности, вроде проблемы N+1 запроса.
4. Уязвимости
Существует широкий спектр потенциальных ловушек безопасности, требующих специальных знаний. Некоторые инструменты, такие как Semmle, могут автоматически обнаруживать многие из этих подводных камней. Но если безопасность вас беспокоит (а она должна беспокоить), необходимы регулярные обзоры кода, проводимые экспертами по безопасности.
5. Именование
Для обеспечения соблюдения простых требований к именованию могут быть написаны автоматические правила. Также инструментальные средства могут заставить использовать предопределённую терминологию основного домена. Кроме того, правильное именование особенно важно для публичных идентификаторов API. Вот почему требуется тщательный анализ именования человеком.
6. Тестирование
Тестирование можно измерить и в значительной степени автоматизировать. Но коэффициента покрытия кода и количества пройденных тестов недостаточно. Человек должен просмотреть тесты, чтобы убедиться в правильности установленных условий и в том, что тесты не слишком сложны.
7. Последовательность
Часто молодые участники команды заново изобретают колесо, потому что не знакомы с общекорпоративными шаблонами и библиотеками. Некоторые автоматические правила могут быть написаны для принудительного использования определённых классов в определённых ситуациях. Но обзоры кода представляют собой отличный способ рассказать о культуре и базе знаний компании.
8. Комментарий
Комментарии должны быть написаны тщательно на правильном человеческом языке, чтобы объяснить, почему этот код написан и почему написан именно таким образом. Например, когда какой-то нетривиальный код адаптируется из ответа со Stackoverflow, стоит указать URL ответа и контекст. С другой стороны, код должен быть достаточно читабельным, чтобы не нужно было комментариев, объясняющих, что он делает.
9. Документация
Инструменты могут легко обнаружить недостающую документацию. IDE, вроде Visual Studio, может легко сгенерировать скелет класса или документацию метода. Но документация пишется человеком и для человека. Чтобы она была действительно информативной, необходима надлежащая проверка со стороны человека. Мы, разработчики, регулярно разочаровываемся в поверхностной и устаревшей документации, которая на самом деле не объясняет, зачем нужен API, как его следует использовать и чего от него ожидать. Правильная документация - отличный способ снизить затраты на поддержку и снизить разочарование пользователей.
Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/
Обзоры Кода. Передовой Опыт. Окончание
Начало
Продолжение
На что обращать внимание при обзоре кода
Многие аспекты проверки кода можно автоматизировать, но человеческие навыки и опыт остаются критичными для обнаружения важных улучшений:
1. Ошибки требований
Разработчик мог неправильно понять некоторые требования. Его код может быть протестирован на 100%, но, если и код, и написанные тесты основаны на неправильных предположениях, задача не может считаться выполненной.
2. Изменения пользовательского интерфейса
Создание правильного UI, который сделает пользователей продуктивными, - одна из самых сложных задач разработки. Проверка кода и проверка UI специалистами команды являются обязательными, чтобы убедиться, что продукт развивается в правильном направлении.
3. Трудно находимые ошибки
Ошибки, связанные с параллельной обработкой (взаимоблокировки, состояния гонки и т.п.), трудно обнаружить, трудно воспроизвести и трудно исправить. Младшие разработчики часто их допускают, даже не подозревая, что они могут произойти. При обзоре кода опытный программист сможет оценить, возможно ли возникновение ошибки. Например, он проверит изменение общего состояния и чистоту метода. Также могут быть обнаружены некоторые другие сложные ошибки, включая утечку памяти и проблемы производительности, вроде проблемы N+1 запроса.
4. Уязвимости
Существует широкий спектр потенциальных ловушек безопасности, требующих специальных знаний. Некоторые инструменты, такие как Semmle, могут автоматически обнаруживать многие из этих подводных камней. Но если безопасность вас беспокоит (а она должна беспокоить), необходимы регулярные обзоры кода, проводимые экспертами по безопасности.
5. Именование
Для обеспечения соблюдения простых требований к именованию могут быть написаны автоматические правила. Также инструментальные средства могут заставить использовать предопределённую терминологию основного домена. Кроме того, правильное именование особенно важно для публичных идентификаторов API. Вот почему требуется тщательный анализ именования человеком.
6. Тестирование
Тестирование можно измерить и в значительной степени автоматизировать. Но коэффициента покрытия кода и количества пройденных тестов недостаточно. Человек должен просмотреть тесты, чтобы убедиться в правильности установленных условий и в том, что тесты не слишком сложны.
7. Последовательность
Часто молодые участники команды заново изобретают колесо, потому что не знакомы с общекорпоративными шаблонами и библиотеками. Некоторые автоматические правила могут быть написаны для принудительного использования определённых классов в определённых ситуациях. Но обзоры кода представляют собой отличный способ рассказать о культуре и базе знаний компании.
8. Комментарий
Комментарии должны быть написаны тщательно на правильном человеческом языке, чтобы объяснить, почему этот код написан и почему написан именно таким образом. Например, когда какой-то нетривиальный код адаптируется из ответа со Stackoverflow, стоит указать URL ответа и контекст. С другой стороны, код должен быть достаточно читабельным, чтобы не нужно было комментариев, объясняющих, что он делает.
9. Документация
Инструменты могут легко обнаружить недостающую документацию. IDE, вроде Visual Studio, может легко сгенерировать скелет класса или документацию метода. Но документация пишется человеком и для человека. Чтобы она была действительно информативной, необходима надлежащая проверка со стороны человека. Мы, разработчики, регулярно разочаровываемся в поверхностной и устаревшей документации, которая на самом деле не объясняет, зачем нужен API, как его следует использовать и чего от него ожидать. Правильная документация - отличный способ снизить затраты на поддержку и снизить разочарование пользователей.
Источник: https://blog.ndepend.com/what-is-code-review-guidelines-best-practices/
День девятьсот восемьдесят второй. #ЗаметкиНаПолях #AsyncTips
Передача информации о ходе выполнения операции
Задача: отреагировать на прогресс выполнения операции.
Решение:
Используйте
Лучше определить
Заметьте, что, если метод поддерживает уведомления о прогрессе, лучше, чтоб он также поддерживал отмену.
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 2.
Передача информации о ходе выполнения операции
Задача: отреагировать на прогресс выполнения операции.
Решение:
Используйте
IProgress<T> и Progress<T>. Ваш асинхронный метод должен получать аргумент IProgress<T>; здесь T — тип прогресса, о котором вы хотите сообщать:async Task MyMethodAsync(IProgress<double> progress = null)Пример использования в вызывающем коде:
{
bool done = false;
double completed = 0;
while (!done) {
...
progress?.Report(completed);
}
}
async Task CallMyMethodAsync()По действующим соглашениям параметр
{
var progress = new Progress<double>(
p => progressBar.Value = p
);
await MyMethodAsync(progress);
}
IProgress<T> может быть равен null, если вызывающей стороне не нужны уведомления о прогрессе. Включите соответствующую проверку в асинхронный метод.Лучше определить
T как неизменяемый тип (или тип-значение). Если T является изменяемым ссылочным типом, то вам придётся самостоятельно создавать отдельную копию при каждом вызове IProgress<T>.Report.Progress<T> сохраняет текущий контекст при создании и активизирует свой обратный вызов в этом контексте. Это означает, что если Progress<T> конструируется в UI-потоке (как в методе CallMyMethodAsync выше), то вы сможете обновить пользовательский интерфейс из его обратного вызова, даже если асинхронный метод вызывает Report из фонового потока.Заметьте, что, если метод поддерживает уведомления о прогрессе, лучше, чтоб он также поддерживал отмену.
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 2.
👍1
День девятьсот восемьдесят третий. #юмор
Не знаю, как с этим в последних версиях .NET, но в .NET Framework приходилось помучиться. Не до пересоздания проекта, конечно, но...
Не знаю, как с этим в последних версиях .NET, но в .NET Framework приходилось помучиться. Не до пересоздания проекта, конечно, но...
День девятьсот восемьдесят четвёртый. #ЗаметкиНаПолях
Фигурные Скобки и Область Видимости Переменных
Даже если вы опытный разработчик C#, есть функции, о которых вы могли не знать. Например, в C# вы можете объявлять переменные в блоках кода в фигурных скобках для определения методов, условных операторов, циклов и т.п. Например, фигурные скобки определяют область видимости переменной в методе:
Что произойдет, если мы добавим следующий оператор вне блока, как в следующем примере?
CS0103: The name 'theVar' does not exist in the current context
(Имя 'theVar' не существует в текущем контексте)
Как видите, переменная, определённая внутри блока кода, недоступна вне его.
Другими словами, вы можете создать область видимости переменной, просто используя фигурные скобки в любом месте вашего кода. Эта функция может быть полезна, когда у вас есть короткая последовательность операторов, которым необходимо передать значение через переменную. Вы создаёте блок кода на лету, объявляете переменную и используете её. Однако предлагаю не злоупотреблять этим. Иногда лучше создать метод и вызвать его. Это может быть более читабельным, чем безымянный блок кода.
Источник: https://auth0.com/blog/five-csharp-features-you-dont-know/
Фигурные Скобки и Область Видимости Переменных
Даже если вы опытный разработчик C#, есть функции, о которых вы могли не знать. Например, в C# вы можете объявлять переменные в блоках кода в фигурных скобках для определения методов, условных операторов, циклов и т.п. Например, фигурные скобки определяют область видимости переменной в методе:
static void Main(string[] args)Также вы можете определить область видимости внутри оператора if:
{
var name = Console.ReadLine();
…
}
if (…)… или while:
{
var dayOfWeek = DateTime.Today.ToString("dddd");
…
}
while (…)Независимо от контекста фигурные скобки ограничивают область действия переменной. Знаете ли вы, что с помощью фигурных скобок можно определить область видимости переменной даже без специального оператора?
{
var dayOfWeek = DateTime.Today.ToString("dddd");
…
}
static void Main(string[] args)Здесь у нас есть блок кода, выделенный фигурными скобками внутри метода
{
Console.WriteLine("Hello");
{
var theVar = "World";
Console.WriteLine(theVar);
}
}
Main(). Блок кода определяет и инициализирует переменную theVar и выводит её значение в консоль. Обратите внимание, что нет if, while, for или другого оператора перед фигурными скобками.Что произойдет, если мы добавим следующий оператор вне блока, как в следующем примере?
static void Main(string[] args)Если вы попытаетесь запустить эту программу, вы получите следующую ошибку:
{
Console.WriteLine("Hello");
{
var theVar = "World";
Console.WriteLine(theVar);
}
//оператор вне блока
Console.WriteLine(theVar);
}
CS0103: The name 'theVar' does not exist in the current context
(Имя 'theVar' не существует в текущем контексте)
Как видите, переменная, определённая внутри блока кода, недоступна вне его.
Другими словами, вы можете создать область видимости переменной, просто используя фигурные скобки в любом месте вашего кода. Эта функция может быть полезна, когда у вас есть короткая последовательность операторов, которым необходимо передать значение через переменную. Вы создаёте блок кода на лету, объявляете переменную и используете её. Однако предлагаю не злоупотреблять этим. Иногда лучше создать метод и вызвать его. Это может быть более читабельным, чем безымянный блок кода.
Источник: https://auth0.com/blog/five-csharp-features-you-dont-know/
День девятьсот восемьдесят пятый. #ЗаметкиНаПолях
Правильное Использование Ключевого Слова static в C#
Основная проблема в том, что static плохо сочетается с изменяемым состоянием, т.е. состоянием, которое может изменяться в течение жизненного цикла программы. Как следствие правила использования следующие:
1. Статические поля должны быть только для чтения (по возможности, константами).
2. Статические поля должны ссылаться на неизменяемое состояние.
3. Статические методы должны быть чистыми функциями, то есть вычислять результат из входных параметров, без изменения состояния входных данных или любого другого состояния.
4. Статические классы допустимы, если их поля и методы соответствуют этим рекомендациям.
Основная мотивация для создания статического поля - создать объект, который живет в течение всего времени выполнения программы. Часто это важный объект, например контекст, доступ к которому осуществляется многими методами. На первый взгляд, сделать его статическим и видимым всем удобнее, чем передавать везде как параметр. Посмотрим, какие проблемы это сулит.
1. Код должен выполняться в пределах сессии
Объект, живущий всё время, пока исполняется программа, зачастую не нужен. На самом деле состояние требуется в пределах «сессии»: в течение веб-запроса или во время выполнения тестов. При этом совместное использование изменяемого состояния – не лучшая идея. Все «сессии» теперь должны заботиться о том, чтобы общее состояние было правильно инициализировано и правильно финализировано. Кроме того, веб-запросы де-факто выполняются конкурентно. Даже тесты можно запустить параллельно. В такой ситуации вам необходимо синхронизировать доступ к статическому изменяемому состоянию. А синхронизация доступа - это не только боль, но и убийца производительности.
2. Управление состоянием в конкурентной среде
В этом случае использование одного ресурса на поток устраняет необходимость в синхронизации. Идея в том, что к объекту всегда обращается один и тот же поток, т.е. каждый поток имеет свой собственный экземпляр. Вы можете использовать для этого статическое поле, помеченное атрибутом
3. Глобальное состояние и поддержка
Статические поля представляют глобальное состояние, доступ к которому можно получить из любого места кода. И разработчики могут создать зависимость от глобального состояния где угодно. Со временем это неизбежно приведёт к неуправляемому доступу к глобальному состоянию, и результатом будет подверженный ошибкам код, неконтролируемые побочные эффекты и утомительные сеансы отладки.
4. Чистые функции
Часто классы содержат функции, которые вычисляют результат без использования полей экземпляра объекта. Эти функции могут быть объявлены статическими. В результате получаются жирные классы, которые трудно понять и поддерживать. Поэтому в случае сложной логики лучше размещать такую реализацию во вспомогательных статических классах. Это не только делает классы экземпляров меньше и понятнее, но и сами статические классы хорошо поддаются тестированию: тесту нужно инициализировать входные данные, вызвать статический метод и проверить результат. Нет никакого скрытого состояния, о котором стоит беспокоиться, не нужно создавать объекты-имитации.
А методы расширения помогают не только отделить объект от его поведения, но и сделать вызовы более естественными.
Итого
Ключевое слово static плохо сочетается с изменяемым состоянием. Неправильное использование обязательно приведёт к серьёзным неприятностям. Но оно может стать серьёзным подспорьем, если использовать его с умом.
Источник: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/
Правильное Использование Ключевого Слова static в C#
Основная проблема в том, что static плохо сочетается с изменяемым состоянием, т.е. состоянием, которое может изменяться в течение жизненного цикла программы. Как следствие правила использования следующие:
1. Статические поля должны быть только для чтения (по возможности, константами).
2. Статические поля должны ссылаться на неизменяемое состояние.
3. Статические методы должны быть чистыми функциями, то есть вычислять результат из входных параметров, без изменения состояния входных данных или любого другого состояния.
4. Статические классы допустимы, если их поля и методы соответствуют этим рекомендациям.
Основная мотивация для создания статического поля - создать объект, который живет в течение всего времени выполнения программы. Часто это важный объект, например контекст, доступ к которому осуществляется многими методами. На первый взгляд, сделать его статическим и видимым всем удобнее, чем передавать везде как параметр. Посмотрим, какие проблемы это сулит.
1. Код должен выполняться в пределах сессии
Объект, живущий всё время, пока исполняется программа, зачастую не нужен. На самом деле состояние требуется в пределах «сессии»: в течение веб-запроса или во время выполнения тестов. При этом совместное использование изменяемого состояния – не лучшая идея. Все «сессии» теперь должны заботиться о том, чтобы общее состояние было правильно инициализировано и правильно финализировано. Кроме того, веб-запросы де-факто выполняются конкурентно. Даже тесты можно запустить параллельно. В такой ситуации вам необходимо синхронизировать доступ к статическому изменяемому состоянию. А синхронизация доступа - это не только боль, но и убийца производительности.
2. Управление состоянием в конкурентной среде
В этом случае использование одного ресурса на поток устраняет необходимость в синхронизации. Идея в том, что к объекту всегда обращается один и тот же поток, т.е. каждый поток имеет свой собственный экземпляр. Вы можете использовать для этого статическое поле, помеченное атрибутом
ThreadStatic. Конкурентный доступ при этом исключается, но каждый поток по-прежнему должен беспокоиться об управлении состоянием. Поэтому создание выделенного объекта на поток более элегантно, чем статическое поле с атрибутом ThreadStatic: так вы можете правильно отслеживать историю изменений состояния.3. Глобальное состояние и поддержка
Статические поля представляют глобальное состояние, доступ к которому можно получить из любого места кода. И разработчики могут создать зависимость от глобального состояния где угодно. Со временем это неизбежно приведёт к неуправляемому доступу к глобальному состоянию, и результатом будет подверженный ошибкам код, неконтролируемые побочные эффекты и утомительные сеансы отладки.
4. Чистые функции
Часто классы содержат функции, которые вычисляют результат без использования полей экземпляра объекта. Эти функции могут быть объявлены статическими. В результате получаются жирные классы, которые трудно понять и поддерживать. Поэтому в случае сложной логики лучше размещать такую реализацию во вспомогательных статических классах. Это не только делает классы экземпляров меньше и понятнее, но и сами статические классы хорошо поддаются тестированию: тесту нужно инициализировать входные данные, вызвать статический метод и проверить результат. Нет никакого скрытого состояния, о котором стоит беспокоиться, не нужно создавать объекты-имитации.
А методы расширения помогают не только отделить объект от его поведения, но и сделать вызовы более естественными.
Select, Where, First и т.п. - это статические методы расширения для IEnumerable, которые не изменяют входную последовательность, а возвращают новую.Итого
Ключевое слово static плохо сочетается с изменяемым состоянием. Неправильное использование обязательно приведёт к серьёзным неприятностям. Но оно может стать серьёзным подспорьем, если использовать его с умом.
Источник: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/
День девятьсот восемьдесят шестой. #Курсы
Бесплатная Неделя на Pluralsight
Налетай! Торопись! Изучай! Левел-апсь!)))
Pluralsight объявили неделю бесплатного доступа ко всем своим курсам. До понедельника, 18 октября 7 утра по Москве все курсы, видео и проекты можно получить абсолютно бесплатно.
Зарегистрироваться можно здесь https://www.pluralsight.com/offer/2021/q4-free-week
Если кому интересно, чтоб не искать, вот ссылки на мою подборку курсов (работают после регистрации на Pluralsight):
- ASP .NET Core (для экзамена 70-486) https://app.pluralsight.com/channels/details/e6a5dd31-af53-4320-b160-7c4e712b06cb
- Azure Fundamentals (для экзамена AZ-900) https://app.pluralsight.com/paths/certificate/microsoft-azure-fundamentals-az-900
- ASP .NET API, Blazor и Azure https://app.pluralsight.com/channels/details/1e5510d8-c21c-4590-b639-08dc23020281
- Прочее https://app.pluralsight.com/channels/details/b5f23d94-9914-45ba-9bd7-23ea00b5769f
Бесплатная Неделя на Pluralsight
Налетай! Торопись! Изучай! Левел-апсь!)))
Pluralsight объявили неделю бесплатного доступа ко всем своим курсам. До понедельника, 18 октября 7 утра по Москве все курсы, видео и проекты можно получить абсолютно бесплатно.
Зарегистрироваться можно здесь https://www.pluralsight.com/offer/2021/q4-free-week
Если кому интересно, чтоб не искать, вот ссылки на мою подборку курсов (работают после регистрации на Pluralsight):
- ASP .NET Core (для экзамена 70-486) https://app.pluralsight.com/channels/details/e6a5dd31-af53-4320-b160-7c4e712b06cb
- Azure Fundamentals (для экзамена AZ-900) https://app.pluralsight.com/paths/certificate/microsoft-azure-fundamentals-az-900
- ASP .NET API, Blazor и Azure https://app.pluralsight.com/channels/details/1e5510d8-c21c-4590-b639-08dc23020281
- Прочее https://app.pluralsight.com/channels/details/b5f23d94-9914-45ba-9bd7-23ea00b5769f
День девятьсот восемьдесят седьмой. #ЗаметкиНаПолях
Основные Заблуждения о Внедрении Зависимостей в ASP.NET Core. Начало
Разработчики, которые недавно начали работать с внедрением зависимостей в ASP.NET Core, часто неверно понимают принципы его работы. Некоторые заблуждения вызывают ошибки, а другие приводят к избыточному коду. Рассмотрим наиболее распространённые.
1. Scoped сервис создаётся только один раз для каждого веб-запроса
Разработчики могут выбрать время жизни сервиса при внедрении зависимости:
- Transient - новый экземпляр класса создается каждый раз, когда он запрашивается из контейнера DI,
- Singleton - один экземпляр класса будет создан на всё время существования приложения,
- Scoped - экземпляр класса должен быть создан один раз для каждого веб-запроса.
Область действия - это область кода между созданием экземпляра типа
Если один и тот же тип в области действия запрашивается несколько раз, всегда будет возвращаться один и тот же экземпляр. ASP.NET Core создаёт область действия в начале веб-запроса и удаляет её в конце веб-запроса. Поэтому экземпляры, ограниченные областью действия, создаются один раз для каждого веб-запроса. Но не всегда.
Ничто не мешает разработчикам создавать дочерние области действия. Экземпляры одного и того же типа, разрешённые из разных областей действия, также будут разными:
Продолжение следует…
Источник: https://levelup.gitconnected.com/top-misconceptions-about-dependency-injection-in-asp-net-core-c6a7afd14eb4
Основные Заблуждения о Внедрении Зависимостей в ASP.NET Core. Начало
Разработчики, которые недавно начали работать с внедрением зависимостей в ASP.NET Core, часто неверно понимают принципы его работы. Некоторые заблуждения вызывают ошибки, а другие приводят к избыточному коду. Рассмотрим наиболее распространённые.
1. Scoped сервис создаётся только один раз для каждого веб-запроса
Разработчики могут выбрать время жизни сервиса при внедрении зависимости:
- Transient - новый экземпляр класса создается каждый раз, когда он запрашивается из контейнера DI,
- Singleton - один экземпляр класса будет создан на всё время существования приложения,
- Scoped - экземпляр класса должен быть создан один раз для каждого веб-запроса.
services.AddScoped<IUserRepository, UserRepository>();Однако время жизни, ограниченное областью действия, (scoped) не гарантирует, что класс создаётся только один раз для каждого веб-запроса. Это означает, что класс будет создан только один раз в заданной области действия, но в одном веб-запросе можно создать несколько областей.
Область действия - это область кода между созданием экземпляра типа
IServiceScope и вызовом его метода Dispose. IServiceScope содержит свойство ServiceProvider, которое используется для разрешения экземпляров сервисов, зарегистрированных в методе ConfigureServices.Если один и тот же тип в области действия запрашивается несколько раз, всегда будет возвращаться один и тот же экземпляр. ASP.NET Core создаёт область действия в начале веб-запроса и удаляет её в конце веб-запроса. Поэтому экземпляры, ограниченные областью действия, создаются один раз для каждого веб-запроса. Но не всегда.
Ничто не мешает разработчикам создавать дочерние области действия. Экземпляры одного и того же типа, разрешённые из разных областей действия, также будут разными:
public class SomeServiceБывают случаи, когда создание области вручную - это единственный правильный способ получить экземпляр сервиса, например, для разрешения scoped сервиса из синглтона. Знание особенностей областей действия может защитить вас от множества проблем.
{
private readonly IServiceScopeFactory _factory;
public SomeService(IServiceScopeFactory factory)
=> _factory = factory;
public void DoSomething()
{
using (IServiceScope scope = _factory.CreateScope());
var obj1 =
scope.ServiceProvider.GetService<IUserRepository>();
using (IServiceScope childScope =
_factory.CreateScope())
{
var obj2 = childScope.ServiceProvider
.GetService<IUserRepository>();
if (obj1 != obj2)
Console.WriteLine("Экземпляры разные.");
}
}
}
Продолжение следует…
Источник: https://levelup.gitconnected.com/top-misconceptions-about-dependency-injection-in-asp-net-core-c6a7afd14eb4