День 2802. #Карьера #Юмор
Секреты Программирования, Известные Только Легендам
Ещё один пост из серии программистских советов, на этот раз менее серьёзный.

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

1. Лучший код — тот, который вы удаляете
Пишите меньше кода, чем, как вам кажется, необходимо. Каждая добавленная строка становится вашей «собственностью» навсегда. Она может сломаться, для неё нужен тест, и когда-нибудь её будет читать другой человек. Чем больше кода, тем больше мест, где могут прятаться баги. Меньше кода — меньше затрат на поддержку и объяснения. Лучший пулл-реквест – тот, в котором удаляется больше строк, чем добавляется.

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

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

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

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

6. Оцените срок выполнения… и удвойте его
Если у вас мало опыта в оценке сроков, какую бы оценку вы ни собирались дать — умножайте её на два. Вы представляете себе идеальный сценарий, но работа — это всё, что происходит вокруг него. Тестирование, обработка граничных случаев, ревью, совещания, сбои на демо. Что-то всегда идёт не так. «Первые 90% кода занимают первые 90% времени разработки. Оставшиеся 10% кода занимают вторые 90% времени».

7. Просите о помощи через час, а не через день
Застряли и не продвигаетесь уже час? Спрашивайте. Попытки справиться в одиночку после этого момента тешат лишь ваше самолюбие — и больше ничего.
Старший разработчик в вашей команде наверняка уже сталкивался с такой ошибкой. Один вопрос сэкономит вам часы. Умение вовремя попросить о помощи — это навык. Это признак рассудительности, а не слабости.

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

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

Итого
Этому не учат на курсах. Такой опыт приобретается ценой собственных ошибок и «шрамов». Или же его можно перенять у того, кто уже заплатил за него высокую цену.

Источник: https://medium.com/javarevisited/9-hidden-coding-secrets-only-great-developers-know-c0ffd93c0b63

День 2803. #Оффтоп
Чем Заняться, Пока Работают Агенты? У VS Code Есть Ответ
Сейчас большую часть кода за вас пишут агенты. И тут возникает вопрос: чем занять освободившееся время? Можно изучить новый фреймворк, но это подозрительно напоминает работу. К счастью, у команды VS Code нашлась идея получше. Они предложили завести питомца.

Что это?
Это интерактивный персонаж, который располагается над полем ввода в чате. Он реагирует на активность в чате и на ваши действия. Пока агент работает, питомец наблюдает. Раньше вы смотрели на индикатор выполнения, делая вид, что контролируете процесс. Теперь есть с кем разделить это занятие.
Примечание: этот питомец — экспериментальная функция, поэтому он может измениться или исчезнуть. Не привязывайтесь к нему слишком сильно.

Как завести питомца
Введите /vscode-pet в поле ввода чата, чтобы показать или скрыть его. Показать и скрыть — это все обязательства. Не нужны ни график кормления, ни ветеринар (по крайней мере, пока).

Чем заняться
- Кликнуть - чтобы вызвать реакцию. С клавиатуры: нажмите Tab, чтобы перевести на него фокус, а затем Enter или пробел. Да, питомец доступен для управления с клавиатуры.
- Перетаскивать по области чата и оставлять там, где захотите (правда, он падает, если под ним ничего нет).
- Начать перетаскивать и отпустить, чтоб подбросить.
- С помощью клавиш со стрелками «влево» и «вправо» заставлять прыгать.
- С помощью клавиш со стрелками «влево» и «вправо» при удержании Shift – бросать в стену. Да, у авторов своеобразное чувство юмора.

Нажмите правой кнопкой мыши на питомца (или Shift+F10, когда он в фокусе), чтобы открыть контекстное меню, где можно:
- посмотреть достижения,
- отправить побегать,
- изменить размер,
- переключаться между цветовыми схемами.

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

Один питомец — множество сеансов
В активной области чата одновременно отображается только один питомец. Его положение и размер сохраняются для всех чатов и окон, а также остаются неизменными после перезапуска VS Code. То есть питомец помнит, где вы его оставили.

Что дальше?
Значит ли это, что освободившееся время стоит тратить на игры с питомцем в редакторе? Решать вам.

Источник: https://laurentkempe.com/2026/09/26/csharp-15-collection-expression-arguments/

День 2804. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

48. Оптимизация производительности Entity Framework Core
«Как бы вы оптимизировали производительность Entity Framework Core? Приведите конкретные примеры методов и настроек, которые вы бы использовали для повышения эффективности взаимодействия с базой данных».

Хороший ответ
Оптимизация Entity Framework Core включает в себя ряд стратегий, направленных на минимизацию накладных расходов и повышение скорости доступа к данным.

Если в текущем контексте не требуется обновление данных, использование метода AsNoTracking позволяет существенно повысить производительность за счёт снижения накладных расходов на отслеживание изменений:

var products = await
  dbContext.Products.AsNoTracking().ToListAsync();

Также полезно избегать использования ленивой загрузки (lazy loading) в ситуациях, которые могут привести к проблеме «N+1 запросов». Вместо этого лучше использовать явную или жадную загрузку (eager loading) для получения всех необходимых данных одним запросом:

var order = await dbContext.Orders
  .Where(o => o.Id == orderId)
  .Include(o => o.OrderItems)
  .ThenInclude(oi => oi.Product)
  .SingleOrDefaultAsync();

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

Важно убедиться, что в БД корректно используются индексы для ускорения выполнения запросов — особенно для столбцов, часто фигурирующих в предложениях WHERE или условиях JOIN.

Регулярное профилирование SQL-запросов, генерируемых EF Core, с помощью таких инструментов, как SQL Profiler или встроенные средства логирования, позволяет выявлять неэффективные запросы и оптимизировать их.

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

Часто встречающийся неудачный ответ
«Важно использовать .Include() для связанных данных, чтобы избежать выполнения множества запросов к базе. Это просто и гарантирует, что все данные будут загружены за один запрос».

Почему этот подход неверен
- Чрезмерное использование жадной загрузки: Беспорядочное применение .Include() может привести к загрузке избыточного объёма данных (особенно при подтягивании нескольких связанных сущностей). Это существенно увеличивает потребление памяти и снижает производительность.

- Увеличение объёма передаваемых данных и рост задержек: Загрузка всех связанных данных одним запросом без учёта реальных потребностей приложения приводит к передаче больших объёмов информации и увеличению задержек. Это особенно критично в условиях высокой сетевой нагрузки или при большом количестве одновременных обращений к приложению.

- Отсутствие точечной оптимизации запросов: Такой подход свидетельствует о непонимании тонкостей работы EF Core и игнорировании более эффективных методов — например, явной загрузки (explicit loading) или выборочной проекции (selective projection), — которые могут обеспечить более высокую производительность.

Эта распространённая ошибка часто возникает из-за непонимания стратегий загрузки данных в EF Core и недостаточного опыта оптимизации производительности при работе со сложными ORM-системами.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

День 2805. #ЧтоНовенького #NET11
Аргументы в Выражениях Коллекций в C#15
В C#15 реализовано точечное улучшение выражений создания коллекций: возможность передавать аргументы с помощью элемента `with(…)`, указываемого в начале выражения.

Если вы уже используете выражения создания коллекций из C#12, это нововведение устраняет распространённое неудобство: теперь можно передавать аргументы (характерные для конструкторов или фабричных методов) непосредственно внутри […].

Сравнение C# версий 12, 13 и 15
C#12 - Добавлены выражения создания коллекций ([…]) и spread-оператор (..):

int[] values = [1, 2, 3];
int[] all = [0, ..values, 4];

C#13 - Расширена поддержка params для разных типов коллекций (не только массивов) в параметрах методов:

csharp 
public void LogValues(params Span<int> numbers) 
{
 // …
}
LogValues(1, 2, 3); 

C#15 - Добавлен элемент with(…) в начало выражений создания коллекций

List<int> numbers = 
 [with(capacity: 100), 1, 2, 3, ..more];

with(…) предоставляет аргументы для создания коллекции, где это поддерживается (параметры конструктора, построитель Create(…), отдельные сигнатуры интерфейсов).
При этом with(…) должен быть первым элементом.

Практические примеры
1) Предварительное определение размера коллекций для обеспечения читаемости и ясности намерений

List<int> ids = [with(capacity: 256), ..sourceIds];

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

2) Сценарии использования построителей коллекций
Для построителей коллекций C#15 поддерживает дополнительные параметры метода Create(…):

static MyCollection<T>
 Create(SomeOption option, ReadOnlySpan<T> items)
{
  // …
}

Использование:

Tags tags = [with(StringComparer.OrdinalIgnoreCase), "CSharp", "CSHARP", "csharp", "dotnet"];
Tags newTags = [with(), "CSharp", "CSHARP", "csharp", "dotnet"];
Tags oldTags = ["CSharp", "CSHARP", "csharp", "dotnet"];

[CollectionBuilder(typeof(Tags), nameof(Create))]
internal sealed class Tags(
  string[] values,
  StringComparer comparer)
 : HashSet<string>(values, comparer)
{
  public static Tags Create(
   StringComparer comparer,
   ReadOnlySpan<string> items)
    => new([.. items], comparer);

  public static Tags Create(ReadOnlySpan<string> items) 
   => new([.. items], StringComparer.OrdinalIgnoreCase);
}

Ограничения и нюансы
1. Если целевым типом является массив или span, использование with(…) невозможно.
2. Аргументы внутри with(…) не могут иметь тип dynamic.
3. Согласно замыслу, аргументы with(…) игнорируются при принятии решений о преобразовании или выводе типов (по аналогии с new(…)).
4. Действуют обычные правила выбора перегрузки конструктора или построителя. Если подходят несколько вариантов, возможна неоднозначность.

Почему важны аргументы выражений коллекций в C#15
C#15 улучшает инициализацию коллекций в одно выражение, обеспечивая:
- Более ясное выражение намерений (указание вместимости, опций, компараторов и т.д., где это поддерживается);
- Сокращение числа отдельных инструкций инициализации;
- Более чистый API для пользовательских построителей коллекций.

Источник: https://laurentkempe.com/2026/09/26/csharp-15-collection-expression-arguments/

День 2806. #ЗаметкиНаПолях
Типы Коллекций в .NET, Которые Стоит Попробовать. Начало
Большинство разработчиков ежедневно используют List<T> и Dictionary<TKey, TValue>. Однако в .NET есть и специализированные коллекции, способные сделать код быстрее, безопаснее и проще в сопровождении. Рассмотрим некоторые из них, о которых стоит знать каждому .NET-разработчику.

1. HashSet<T>
Многие разработчики используют List<T> для проверки наличия элемента.

if(users.Contains(id))

Проблема в том, что List.Contains() выполняет линейный поиск. HashSet<T> использует хэширование для гораздо более быстрого поиска:

var permissions =
 new HashSet<string>
 {
   "Read",
   "Write",
   "Delete"
 };
Console.WriteLine(
  permissions.Contains("Write"));

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

См. подробнее про HashSet

2. PriorityQueue<TElement,TPriority>
Нужно первым делом обработать элемент с наивысшим приоритетом?
Вместо того чтобы постоянно сортировать список, используйте PriorityQueue:

var queue = new PriorityQueue<string, int>();
queue.Enqueue("Low", 3);
queue.Enqueue("Medium", 2);
queue.Enqueue("High", 1);
while (queue.Count > 0)
  Console.WriteLine(queue.Dequeue());

// Вывод:
// High
// Medium
// Low

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

См. подробнее про PriorityQueue

3. ConcurrentDictionary<TKey,TValue>
Обычный словарь (Dictionary) не является потокобезопасным. Если несколько потоков будут одновременно читать и записывать данные, это неизбежно приведёт к возникновению исключений или нарушению целостности данных.
ConcurrentDictionary решает эту проблему:

using System.Collections.Concurrent;

var cache = new ConcurrentDictionary<int, string>();
Parallel.For(0, 1000, i =>
{
  cache.TryAdd(i, $"User {i}");
});
Console.WriteLine(cache.Count);

Почему не использовать блокировку?
Вместо:

lock(_lock)
{
  dictionary.Add(...);
}

Используйте:

cache.TryAdd(key, value);

- яснее,
- быстрее,
- безопаснее.

Где использовать:
- кэширование,
- фоновые сервисы,
- параллельная обработка.

См. также Использование потокобезопасных коллекций

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

Источник: https://medium.com/turbo-net/7-dotnet-collections-youre-probably-not-using-but-should-a76437aa6a62

🦈 Открытое собеседование на Middle C# | 6 октября, 19:00 МСК

Приглашаем на открытое собеседование: Senior C# разработчик проведёт его в прямом эфире. Можно посмотреть, как всё устроено изнутри, и понять, насколько ты готов к такому интервью.

Как это будет:
📂 Собеседует Александр Моргунов — Senior C# разработчик, 7+ лет в европейских высоконагруженных сервисах. Отвечает разработчик-доброволец;

📂 Всё как на настоящем собесе: Александр задаёт те вопросы и задачи, которые даёт кандидатам на своих интервью. Заранее их никто не знает;

📂 После каждого ответа Александр даст обратную связь: что прозвучало сильно, а что стоило раскрыть иначе. Так станет понятнее, на что обращают внимание на собесе;

📂 В конце можно задать любой вопрос.

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для C# разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир -> @shortcut_csharp_bot

Реклама.
О рекламодателе.