Библиотека шарписта | C#, F#, .NET, ASP.NET
22.5K subscribers
2.43K photos
40 videos
85 files
4.63K links
Все самое полезное для C#-разработчика в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/b60af5a4

Для обратной связи: @proglibrary_feeedback_bot

РКН: https://gosuslugi.ru/snet/67a5c81cdc130259d5b7fead
Download Telegram
📣 Исключения или Result — что выбрать для обработки ошибок

Когда речь заходит о том, как лучше обрабатывать ошибки в C#, многие разработчики оказываются в двух лагерях.

• Исключения — классический подход

Исключения используются в C# с самого начала. Они позволяют немедленно прерывать выполнение программы в случае ошибки и предоставить стек вызовов для диагностики проблемы.

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

• Result-типы — альтернатива

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

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

💬 Когда вы предпочитаете использовать исключения? А когда лучше использовать Result? Делитесь мнениями в комментариях 👇

🐸Библиотека шарписта #междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
3🤔1
🤔 Такие ли айтишники проблемные

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

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

Возможно, нужна более гибкая и заботливая рабочая среда?

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

Наш админ думает так:
Как тут не свихнёшься, когда тебя каждый день спрашивают одно и то же в надежде на изменения? Как попугаи «Какой статус? Какой статус?»


💬 Что думаете об этом? Как у вас обстоят дела с головой? Делитесь в комментариях 👇

Понравился пост? Поделитесь бустом, а мы взамен поделимся топовым контентом.

🐸Библиотека шарписта #междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
😁91
🎮 Снова сеньор без клавиатуры

Сеньору запретили писать откровения на ревью, поэтому он опять наказан использованием эмодзи.

Пишите в комментарии, что это он написал на картинке 👇

🐸Библиотека шарписта #междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
💬 Техдолга много не бывает

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

Один из наших подписчиков недавно спросил:
Как определить, когда стоит принимать новый функционал, а когда — гасить технический долг


На практике подход к техдолгу зависит от контекста проекта, команды и бизнес-целей. Вот основные моменты, которые помогут выбрать стратегию:

— Регулярно формируйте список всех известных проблем: устаревшие библиотеки, неочищенный код, отсутствие тестов.

— Делите техдолг на «осознанный» (trade-off ради скорости) и «неосознанный» (ошибки, хаотичный рост).

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

— Включайте небольшие задачи по техдолгу в каждый спринт (например, 10–20 % времени).

— Установите критерии «не допуска к продакшену» для новых заимствований (например, доля покрытия тестами).

💬 Как вы балансируете новые фичи и погашение техдолга? Поделитесь своим опытом в комментариях 👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека шарписта #междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
1
var в C# — удобство или маска

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

Вместо явного написания громоздких типов можно писать лаконичный код:
// Вместо List<Dictionary<string, List<Tuple<int, DateTime>>>> data = ...
var data = GetComplexData();


Также var не делает переменную динамической, это всё тот же строго типизируемый код.

Но есть и сильный аргумент против использования var. На примере кода выше:
// Вместо List<Dictionary<string, List<Tuple<int, DateTime>>>> data = ...
var data = GetComplexData(); // каков тип data? int, string, CustomType?


Тип, получаемый из функции неочевиден и это в разы ухудшает читаемость кода.

var — полезный инструмент, но требует дисциплины. При очевидном типе он упрощает код, при неочевидном — мешает пониманию.

💬 Вы используете var в коде или сторонник явного? Делитесь мыслями в комментариях 👇

🐸Библиотека шарписта #междусобойчик
Please open Telegram to view this post
VIEW IN TELEGRAM
🌚10💯93😢2🤩2