телеграм канал .NET Разработчик
Оцени!

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

Дневник сертифицированного .NET разработчика.
Для связи: @SBenzenko

Информация о канале

Телеграм канал «.NET Разработчик» @netdeveloperdiary (2420 подписчиков). Добавлен в каталог 17 Октября 2020. Категория 💻 IT, технологии. Открыть в: Telegram | в web версии | Ссылка в каталоге: https://tgram.me/netdeveloperdiary | Телеграм ссылка: https://t.me/netdeveloperdiary Язык: Русский, Английский.
Ваш канал? Вы можете увеличить его конверсию, купив платное размещение.

Дата добавления
17 Октября 2020 01:46
Последнее обновление
2 Июля 2021 18:54
Дата создания
31 Января 2019 04:59
Адрес в каталоге
https://tgram.me/netdeveloperdiary
Telegram ссылка
https://t.me/netdeveloperdiary
Подписчики
2420
Язык
Русский, Английский

Похожие каналы

Телеграм каналы похожие на @netdeveloperdiary

Отзывы на канал @netdeveloperdiary

Оставьте пожалуйста свой комментарий о телеграм канале «.NET Разработчик».

Популярное в каталоге

Посмотрите популярные ресурсы в каталоге

Последние посты

Последние сообщения в телеграм канале «.NET Разработчик».

День девятьсот пятый. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Продолжение
Начало

3. Если вы не можете написать чёткий комментарий, возможно, проблема в коде
Самый печально известный комментарий в исходном коде Unix: «Никто не ожидает, что вы это поймёте», - располагался перед каким-то непонятным кодом переключения контекста. Позже Деннис Ричи объяснил, что это было написано в смысле "Этого не будет на экзамене", а не чтобы потроллить читателей. К сожалению, выяснилось, что ни он, ни соавтор Кен Томпсон сами не понимали этого кода и позже пришлось его переписать.

Это напоминает закон Кернигана: «Отладка в два раза сложнее, чем изначальное написание кода. Следовательно, если вы напишете код настолько умно, насколько это возможно, вы по определению недостаточно умны, чтобы отлаживать его.»

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

4. Комментарии должны прояснять ситуацию, а не запутывать
Обсуждение плохих комментариев было бы неполным без этой истории из книги Стивена Леви «Хакеры: герои компьютерной революции»:
[Питер Сэмсон] отличался тем, что отказывался добавлять поясняющие комментарии к своему исходному коду. Одна хорошо распространённая программа, написанная Сэмсоном, содержала сотни инструкций на языке ассемблера, с одним комментарием рядом с инструкцией, содержащей число 1750. Комментарий был: «RIPJSB», - и люди ломали голову над его значением, пока кто-то не понял, что 1750 - это был год смерти Баха, и что Сэмсон написал аббревиатуру для «Покойся с миром Иоганн Себастьяна Баха».

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

5. Поясняйте нестандартный код в комментариях
Рекомендуется комментировать код, который кто-то может счесть ненужным или избыточным, например этот код из App Inventor:
final Object value = (new JSONTokener(jsonString)).nextValue();
// Note that JSONTokener.nextValue() may return
// a value equals() to null.
if (value == null || value.equals(null)) {
return null;
}
Без этого комментария кто-то может «упростить» код или рассматривать его как загадочное, но важное заклинание. Сэкономьте время и беспокойство будущих читателей, написав, зачем нужен код.

Необходимо принять решение относительно того, требует ли код пояснения. Например, в учебнике по Kotlin есть такой код:
if (b == true)
Странно, почему бы не использовать просто if (b), как это было бы в Java или C# (да и куче других языков). Однако, оказывается, что обнуляемые булевы переменные в Kotlin специально явно сравниваются с true, чтобы избежать уродливой проверки на null:
if (b != null && b)

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

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

Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/

936 06:31

День девятьсот шестой. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Продолжение
Начало
Продолжение

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

Например, рассмотрим этот комментарий:
/* Преобразует Drawable в Bitmap.
См. https://stackoverflow.com/a/46018816/2219998 */

Переход по ссылке на ответ показывает:
- Автор кода - Tomáš Procházka, который входит в топ 3% контрибьюторов на Stack Overflow.
- Один комментатор предлагает оптимизацию, уже включенную в репозиторий.
- Другой комментатор предлагает способ избежать крайнего случая.

Сравните это с этим комментарием (слегка изменённым для защиты авторов):
// Магическая формула, взятая со stackoverflow.
// По общему мнению, основана на человеческом восприятии.
return (int) (0.3 * red + 0.59 * green + 0.11 * blue);

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

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

Люди копируют много кода из вопросов и ответов на Stack Overflow. Этот код подпадает под действие лицензий Creative Commons, требующей указания авторства. Комментарий со ссылкой удовлетворяет этому требованию.

Точно так же вы можете ссылаться на полезные учебные пособия, чтобы их можно было найти снова, а также в виде благодарности их автору:
// Большое спасибо Chris Veness за отличные примеры:
// http://www.movable-type.co.uk/scripts/latlong.html

7. Добавляйте ссылки на внешние источники, где они будут наиболее полезны
Например:
/* На http://tools.ietf.org/html/rfc4180
советуют завершать строки в CSV файле символом CRLF
поэтому используем \r\n */
csvStringBuilder.append("\r\n");
Ссылки на стандарты и другую документацию могут помочь читателям понять проблему, которую решает ваш код. Хотя эта информация может быть где-то в проектном документе, комментарий в правильном месте даст читателям информацию там, где она больше всего нужна. В этом случае переход по ссылке даст полезную информацию о том, что стандарт RFC 4180 был обновлен до RFC 7111.

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

Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/

896 05:29

NIX приглашает .NET разработчиков в свою дружную команду!

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

Сейчас у нас открыты 3 вакансии по направлению Backend web-development:

Junior .Net developer
Middle .Net developer
Senior .Net developer

Перенимай опыт профессионалов и совершенствуй навыки вместе с NIX!

NIX — это команда с почти 3000 специалистами по всему миру, разрабатывающая программное обеспечение с 1994 года. Пользуясь приобретенным опытом и знаниями, мы создаем инновационные решения, которые позволяют нашим клиентам занимать лидирующие позиции в своих сферах бизнеса.

Заполняй резюме на сайте — карьера в NIX ждет тебя!
#реклама

896 07:02

День девятьсот седьмой. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Окончание
Начало
Продолжение 1
Продолжение 2

8. Добавляйте комментарии при исправлении ошибок
Комментарии следует добавлять не только при первоначальном написании кода, но и при его изменении, особенно при исправлении ошибок. Обратите внимание на этот комментарий:
/* ПРИМЕЧАНИЕ: как минимум, в Firefox 2, если пользователь уводит курсор за пределы окна браузера, событие перемещения мыши (и даже отпускания мыши) не будет получено, пока пользователь не перетащит курсор обратно в окно. Обойти проблему можно, реализовав onMouseLeave(). */
public void onMouseMove(Widget sender, int x, int y) { … }

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

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

Если в системе контроля версий вы чётко следите за сообщениями коммитов, и добавляете в них ссылки на проблемы багтрекера, git blame можно использовать для поиска коммита, в котором было изменение. Хотя здесь могут быть варианты. Если исправление состояло из нескольких коммитов или были более серьёзные изменения, вроде перемещения метода в другой класс или переименования/перемещения файлов, тогда поиск источника исправления может сильно усложниться.

9. Используйте комментарии, чтобы отмечать незавершённые реализации
Иногда необходимо внести код в систему контроля версий, даже если он не завершён. Хотя может возникнуть соблазн не сообщать об известных недостатках в коде, лучше сделать их явными, например, с помощью комментария TODO:
/* TODO(hal): мы используем десятичный разделитель точку, вне зависимости от региона пользователя. Нам нужно подумать о том, как разрешить запятую в качестве десятичного разделителя, что потребует обновления синтаксического анализа чисел и других мест, где числа парсятся из строк, таких как FormatAsDecimal */

Использование стандартного формата для таких комментариев помогает измерить и устранить технический долг. А ещё лучше добавить проблему в багтрекер и указать ссылку на неё в своём комментарии.

Итого
Я надеюсь, что приведённые выше примеры показали, что комментарии не извиняют и не исправляют плохой код; они дополняют хороший код, предоставляя информацию другого типа. Как писал соучредитель Stack Overflow Джефф Этвуд: «Код говорит вам, как, а комментарии говорят вам, почему».
Следование этим правилам поможет вам и вашим товарищам по команде сэкономить время и нервы. Тем не менее, я уверен, что эти правила не являются исчерпывающими, и с нетерпением жду ваших вариантов в комментариях.

Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/

833 07:20

День девятьсот восьмой. #DesignPatterns #Microservices
Паттерны в Микросервисах
7. Душитель (Strangler)
Если мы хотим использовать микросервисную архитектуру в унаследованном проекте, нам необходимо перенести устаревшие или существующие монолитные приложения на микросервисы. Перемещение существующих и работающих крупных монолитных приложений на микросервисы является довольно сложной задачей, так как это может нарушить доступность приложения.

Одно из решений - использовать паттерн Душитель. Он предполагает постепенную миграцию монолитного приложения на микросервисную архитектуру путём постепенной замены определённых функций новыми микросервисами. Кроме того, новый функционал добавляется только в микросервисы, минуя устаревшее монолитное приложение. Затем настраивается фасад (API-шлюз https://tgram.me/NetDeveloperDiary/1106) для маршрутизации запросов между устаревшим монолитом и микросервисами. После того, как функциональность перенесена на микросервисы, фасад перехватывает клиентский запрос и направляет его на новые микросервисы. После переноса всего функционала старого монолита получается, что монолитное приложение «задушено», то есть оно выводится из эксплуатации. См. картинку ниже.

Достоинства
- Безопасная миграция монолитного приложения на микросервисы.
- Миграция и разработка нового функционала могут идти параллельно.
- Процесс миграции может иметь свой темп, весь функционал постоянно доступен клиентам.

Недостатки
- Совместное использование хранилища данных между существующим монолитным приложением и новыми микросервисами становится сложной задачей.
- Добавление фасада (API-шлюза) увеличит время отклика системы.
- Сквозное тестирование становится трудным.

Когда использовать
- Постепенная миграция большого серверного монолитного приложения на микросервисы.

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

Поддержка
Бэкенд фреймворки с поддержкой API-шлюзов.

Подробнее
- Паттерн Душитель
- Microservices Pattern: Strangler application

Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41

794 05:16

794 05:16

Исполни свою мечту попасть в IT — научись правильно составлять резюме и готовиться к собеседованию. В этом тебе помогут Монстры Интервью из NIX!

Монстры Интервью — это эксперты и рекрутеры NIX, которые расскажут:
🔹 как правильно оформить резюме;
🔹 как подготовиться к собеседованию и к технической части интервью;
🔹 с чего начать карьеру в .NET, Java, JS и DevOps и каких специалистов ждут в NIX.

Когда: 31 июля, с 11:00 до 19:00
Где: Харьков, Fabrika.space, ул. Благовещенская, 1

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

Узнай, как улучшить резюме, пройди экспресс-интервью с техническим экспертом и рекрутером NIX. И в случае успеха ты получишь оффер в тот же день.

Регистрируйся, прикрепляй свое резюме и записывайся на экспресс-собеседование!

Стань ближе к IT вместе с NIX!
#реклама

827 07:02

День девятьсот девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
92. Когда Программисты и Тестировщики Сотрудничают
Когда тестировщики и программисты начинают сотрудничать, случается магия. Меньше времени тратится на отправку ошибок туда-сюда через багтрекер. Меньше времени тратится на попытки выяснить, действительно ли что-то является ошибкой или новой функцией, и больше времени тратится на разработку хорошего программного обеспечения, отвечающего ожиданиям клиентов. Есть много возможностей начать сотрудничать ещё до того, как начнётся кодирование.

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

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

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Janet Gregory

782 05:39

День девятьсот десятый. #ВопросыНаСобеседовании
Сегодня порекомендую вам не видео, а серию подкаста DotNet & More про вопросы на собеседовании. Серия вышла ещё в конце мая, но вот наткнулся на неё только сейчас. Ребята 2,5 часа обсуждают, что их спрашивали на собеседованиях, и что они стараются спрашивать, когда находятся по другую сторону стола.

Вообще, обсуждение довольно интересное. Поэтому, если у вас есть свободное время по пути на работу (или в отпуск), слушайте.

Выпуск доступен на YouTube или звуком на Anchor.

682 05:01