🎮 Снова сеньор без клавиатуры

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

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

🐸Библиотека шарписта #междусобойчик

💬 Техдолга много не бывает

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

Один из наших подписчиков недавно спросил:

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

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

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

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

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

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

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

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

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

🐸Библиотека шарписта #междусобойчик

❓ 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 в коде или сторонник явного? Делитесь мыслями в комментариях 👇

🐸Библиотека шарписта #междусобойчик

👨‍💻 Бесполезные знания для работы

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

Вот что думает наш админ:

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

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

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

🐸Библиотека шарписта #междусобойчик

✏️ Кроссворд на выходных

Отвлечёмся от работы, но не совсем. Сегодня будем отгадывать термины из разработки.

1. Специальный оператор, возвращающий имя переменной, метода или типа как строку.

2. Модификатор метода, обозначающий его асинхронное выполнение в сочетании с await.

3. Специальный член класса, позволяющий обращаться к экземпляру как к массиву: obj[i].

4. Модификатор, позволяющий объявить один класс/метод/структуру в нескольких файлах.

5. Ключевое слово, позволяющее из метода-итератора возвращать значения по одному.

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

7. Контекст или модификатор, разрешающий небезопасный (низкоуровневый) код с указателями.

Пишите под спойлер свои варианты в комментариях 👇

🐸Библиотека шарписта #междусобойчик

💡 ИИ в обучении: возможности и ловушки

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

Один из наших подписчиков недавно спросил:

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

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

1. Вместо нейросети пользоваться документацией.

Когда вам нужно что-то реализовать сначала подумайте что вам нужно. Декомпозируйте проект на модули а модули на функции.

После декомпозиции можно погуглить как это реализовать. Например, вы хотите принимать данные по REST, значит вам нужна точка входа в сервис.

Гуглите как это сделать. Буквально: «Как передать данные по REST в приложение на .NET». Бегло смотрите по выдаче и находите названия библиотек или инструментов, небольшие куски реализации и ищите по ним документацию.

Первое время это может быть тяжело, особенно после вайбкоддинга.

2. Просить у нейросети пояснение, а не решение.

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

💬 Как вы поддерживаете баланс между помощью нейронки и самостоятельным погружением? Поделитесь опытом в комментариях 👇

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

🐸Библиотека шарписта #междусобойчик

🚦 Долгосрочное планирование: мираж или необходимость

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

Почему планирование — это опасная ловушка:

• Сложно предсказать технологические тренды.

• Чаще требуется гибкость и быстрота изменений, чем спланированный ком задач.

• Конкуренты не спят и могут испортить ваши планы.

Когда планирование полезно:

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

• Долгосрочные планы показывают инвесторам, что компания думает о будущем и готова к масштабированию.

💬 Какой у вас горизонт планирования? Нужно ли долгосрочное планирование в IT? Делитесь мыслями в комментариях 👇

🐸Библиотека шарписта #междусобойчик

🤨 Нужен ли async в каждом методе

Асинхронное программирование стало неотъемлемой частью разработки на C#. Но появляется вопрос: нужно ли использовать асинхронность в каждом методе?

Когда стоит использовать async

— Асинхронность идеально подходит для работы с медленными операциями, такими как запросы к базе данных, сетевые операции или чтение/запись файлов.

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

— Применяя async/await, мы освобождаем потоки от ожидания завершения I/O операций.

Но за плюсами спрятались и минусы

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

— Применение асинхронности везде может привести к проблемам с синхронизацией данных и контекстом выполнения.

— Если приложение не работает с большим количеством асинхронных операций, добавление async/await в каждый метод не даст значительного прироста производительности.

💬 Как вам асинхронность? Даёшь в каждый метод или лучше дважды подумать?

🐸Библиотека шарписта #междусобойчик

🍆 Почему именно C#

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

Один из подписчиков задает вопрос:

Почему вы выбрали C# и какие его особенности вам особенно нравятся?

Вот несколько причин, почему C# — это отличный выбор:

• Разрабатывать можно всё — от мобильных приложений с Xamarin до веб-сервисов на ASP.NET Core, а для игр вообще не найти лучшего варианта, чем Unity.

• С# чёткий и стильный, и получается регулярные обновления.

• У языка огромное комьюнити. Разработчики активно делятся опытом, решают проблемы и делятся фишками.

💬 За что вы полюбили C#? Делитесь в комментариях👇

🐸Библиотека шарписта #междусобойчик

🧩 Субботний ребус

Что мы загадали в ребусе? Пишите под спойлер в комментарии 👇

🐸Библиотека шарписта #междусобойчик

🤨 Разработчики бывают разные

В команде всегда важен баланс: навыков, взаимодействия, доверия.
Но что делать, если приходится выбирать?

Наш подписчик поделился историей:

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

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

В итоге один тянул вниз, а второй — разрывал команду изнутри.

Какой тип разработчика на самом деле опаснее?

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

💬 А теперь вопрос: кого бы вы оставили, если нужно выбрать одного?

🐸Библиотека шарписта #междусобойчик

🧑‍💻 Почему SOAP — это прошлое

Когда мы говорим о веб-сервисах, старые технологии вроде SOAP уже не так популярны. Но почему?

Такой вопрос, который нам недавно задал подписчик:

Почему SOAP считается устаревшим, а REST стал стандартом?

Сейчас объясним почему REST стал стандартом.

SOAP использует XML, который довольно тяжёлый и сложный в обработке. В REST для обмена данными чаще используется JSON — лёгкий формат, который легче читается и быстрее обрабатывается.

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

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

SOAP был хорош, но сегодня REST предоставляет всё, что нужно для современных приложений.

💬 А вы когда-нибудь использовали SOAP? Поделитесь своим опытом в комментариях 👇

🐸Библиотека шарписта

#междусобойчик

🤖 C# для машинного обучения

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

Давайте разберемся, подходит ли C# для машинного обучения или всё-таки стоит обратить внимание на более традиционные инструменты.

Плюсы использования C# для машинного обучения:

• C# является частью экосистемы .NET, что даёт разработчикам доступ к множеству библиотек для работы с большими данными, многозадачностью и асинхронными операциями.

• Microsoft предлагает ML.NET — библиотеку, которая позволяет работать с алгоритмами машинного обучения в C#.

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

Минусы использования C# для машинного обучения:

• Хотя ML.NET предоставляет некоторые возможности, C# не имеет такого богатого выбора фреймворков и моделей, как Python.

• В интернете гораздо меньше примеров и документации по машинному обучению на C# по сравнению с Python

💬 Используете ли вы C# для машинного обучения или предпочли бы выбрать Python? Поделитесь своим мнением в комментариях 👇

🐸Библиотека шарписта

#междусобойчик

💬 Короткая экономия, долгие риски

Глава AWS Мэтт Гарман раскритиковал практику «замены» младших специалистов ИИ, назвав её «одной из самых глупых вещей», которые он слышал. По его словам, компании рискуют лишиться кадрового резерва через несколько лет, ведь именно джуны вырастают в мидлов и сеньоров.

Гарман также отмечает, что новички часто наиболее активно осваивают AI-инструменты, а стоят дешевле, чем опытные инженеры — значит, их обучение экономически оправдано.

💬 Что думаете вы? Замена джунов поможет сэкономить или в будущем такие компании могут понести большие убытки?

🐸Библиотека шарписта

#междусобойчик

👨‍💻 ImmutableCollection и многозадачность в C#

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

ImmutableCollection помогает решить эту задачу, предоставляя коллекции, которые нельзя изменять после их создания. Но стоит ли использовать их везде?

Таким вопросом и задался наш подписчик:

Как ImmutableCollection помогает при разработке многозадачных приложений? Стоит ли использовать их везде, где возможно?

Когда не стоит использовать:

• Каждый раз при изменении коллекции создается новая копия, что может снизить производительность.

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

Когда ImmutableCollection — это идеальный выбор:

• Когда данные не изменяются часто
• Когда важна безопасность многозадачности
• В функциональном программировании

💬 Как вы используете ImmutableCollection? Поделитесь опытом в комментариях 👇

🐸Библиотека шарписта

#междусобойчик

👨‍💻 Нужен ли разработчику сайт-визитка или это лишнее

Сейчас у каждого есть GitHub, LinkedIn, Telegram и куча других платформ.
Казалось бы — зачем ещё и свой сайт-портфолио?

Давайте разберёмся.

✅ Аргументы за сайт-визитку

• Контроль над брендом — соцсети меняются, сайты блокируют, а домен и сервер — ваша территория.

• Выделяетесь среди резюме — вместо унылого PDF можно показать проекты, интерактивные демки, блог.

• SEO и видимость — вас могут найти рекрутеры или клиенты через поиск.

• Тренировка навыков — сайт сам по себе демонстрирует, что вы умеете в верстку, дизайн, деплой и инфраструктуру.

❌ Аргументы против или «пустая трата времени»

• Все и так смотрят GitHub/LinkedIn — работодателям важнее код и опыт, а не красивый лендинг.

• Поддерживать сложно — технологии быстро устаревают, сайт превращается в «заброшенный музей».

• Не решает ключевых задач — оффер дадут не за HTML-визитку, а за навыки и проекты.

• Время лучше потратить на реальные пет-проекты или open-source.

💬 Что думаете вы? Может у вас есть визитки? Скидывайте в комменты 👇

🐸Библиотека шарписта

#междусобойчик

👨‍💻 Как реагировать на код-ревью

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

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

Проблемы с кодом — это не проблемы с вами. Ошибки в коде — это нормальная часть работы. Главное — это стремление исправить их.

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

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

🐸Библиотека шарписта

#междусобойчик

🔐 Хэширование в C#: как и когда использовать

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

Основная цель хэширования — ускорить операции, например, поиск элементов в коллекциях или в базах данных.

Как работает хэширование

В C# хэширование чаще всего встречается в таких структурах данных, как Dictionary и HashSet, где хэш-функции используются для быстрого поиска элементов. Эти коллекции используют хэш-таблицы для того, чтобы операции поиска, добавления и удаления выполнялись за время O(1) в среднем.

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

Пример реализации собственного хэширования:

// Переопределение метода GetHashCode для обеспечения корректного хэширования
    public override int GetHashCode()
    {
        // Простой хэш-функции, использующей значения полей объекта
        // Здесь мы комбинируем хэши Name и Age для создания уникального хэш-значения
        int hashName = Name == null ? 0 : Name.GetHashCode();
        int hashAge = Age.GetHashCode();
        
        // Используем формулу для комбинирования хэшей, чтобы минимизировать коллизии
        return hashName ^ hashAge;
    }

Когда стоит использовать хэширование

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

Хэширование используется для защиты данных, например, в процессе хранения паролей. В этом случае важно использовать криптографически стойкие хэш-функции, такие как SHA-256 или bcrypt.

Хэш-функции могут использоваться для проверки, не изменились ли данные, например, для контроля над целостностью файлов.

💬 Как вы используете хэширование в своих проектах? Делитесь примерами в комментариях 👇

🐸Библиотека шарписта

#междусобойчик

💬 Full-Stack или глубокая специализация

Разработчики всегда стояли на перепутье: либо углубляться в одну область, становясь мастерами в ней, либо учить всё и сразу, чтобы быть востребованными на рынке.

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

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

💬 Как думаете вы? Лучше углубиться в одну область или быть «швейцарским ножом»?

🐸Библиотека шарписта

#междусобойчик