Библиотека шарписта | C#, F#, .NET, ASP.NET

🧩 Чек-лист Senior .NET-разработчика на 2026 год Какие темы действительно стоит знать, если хотите уверенно чувствовать себя на позиции Senior? На этой схеме собрали ключевые направления, которые чаще всего встречаются в современных .NET-проектах: • C# и новые возможности языка; • async/await, многопоточность и управление памятью; • ASP.NET Core и проектирование API; • EF Core, Dapper, SQL и Redis; • производительность, CLR, JIT и Native AOT; • безопасность, OWASP Top 10 и Identity; • OpenTelemetry, логирование и мониторинг; • DDD, System Design и распределённые системы; • Docker, Kubernetes и CI/CD. 📌 Это не список «что нужно выучить за неделю», а удобный ориентир, который поможет оценить свои сильные стороны и понять, что стоит подтянуть дальше. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #схема

❓ Как устроен пул потоков и почему его нельзя блокировать Большая часть CPU-bound работы и продолжений после await в .NET выполняется на потоках из ThreadPool. Именно поэтому проблемы с производительностью часто начинаются здесь. ➡️ Пул хранит набор рабочих потоков и несколько очередей задач. У каждого потока есть своя локальная очередь, а также существует общая. Если поток остаётся без работы, он может забирать задачи из очередей других потоков. Этот механизм называется work stealing и помогает равномерно загружать все ядра. Главное правило — не блокируйте потоки пула. Когда код вызывает .Result или .Wait() для незавершённой задачи, поток простаивает, но остаётся занятым. Если таких потоков становится много, возникает голодание пула (ThreadPool starvation): новые задачи ждут свободных потоков, а приложение начинает «подвисать». Пул умеет создавать новые потоки, но делает это постепенно, чтобы не тратить ресурсы впустую. Поэтому большое количество блокирующих вызовов особенно болезненно. 💡 Используйте await вместо .Result и .Wait(), а длительную блокирующую работу не держите на потоках пула. Это поможет избежать голодания и сохранить отзывчивость приложения. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

💡 EF Core научился переводить FullJoin в FULL OUTER JOIN В .NET 11 Preview 6 EF Core получил поддержку трансляции нового LINQ-оператора FullJoin в SQL. Теперь запросы могут выполняться целиком на стороне базы данных, без ручных обходных решений. Сам оператор FullJoin появился в .NET 11 раньше, но сначала работал только для LINQ to Objects. Теперь EF Core умеет преобразовывать его в FULL OUTER JOIN для реляционных провайдеров, которые поддерживают этот оператор. Это удобно для задач, где нужно сохранить все строки из обеих таблиц, включая несовпавшие: поиск расхождений, сверка данных, объединение нескольких источников или построение отчётов. Раньше такие запросы часто приходилось собирать вручную из нескольких JOIN и UNION либо писать сырой SQL. ⚠️ Пока это часть .NET 11 Preview 6. До финального релиза в ноябре поведение ещё может измениться. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

💡 Компилируйте регулярки заранее Обычный new Regex("...") разбирает шаблон при первом использовании уже во время работы программы. Если регулярное выражение используется часто, это лишние накладные расходы, а ошибки в шаблоне обнаружатся только в рантайме. В .NET 7 появился атрибут [GeneratedRegex]. Достаточно объявить частичный метод, а генератор исходного кода создаст реализацию ещё на этапе сборки. Если шаблон известен заранее и используется регулярно, выбирайте [GeneratedRegex]. Если регулярное выражение приходит от пользователя или из конфигурации во время работы программы — остаётся обычный Regex. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

без подписи

❓ Server GC или Workstation GC. Что выбрать? В .NET сборщик мусора работает в двух режимах, и выбор между ними влияет на производительность приложения. Workstation GC рассчитан на клиентские приложения. Он экономнее расходует память и старается не занимать все доступные ядра. ➡️ Server GC ориентирован на высокую нагрузку. Он использует несколько управляемых куч и потоков GC, что позволяет эффективнее справляться с большим количеством аллокаций на многоядерных машинах. Цена — более высокое потребление памяти. Ещё одна особенность — Background GC. Во время сборки старших поколений он позволяет сократить длительные паузы, выполняя значительную часть работы параллельно с приложением. Server GC настраивается через свойство ServerGarbageCollection, хотя многие серверные шаблоны уже используют его по умолчанию. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

Какая концепция C# позволяет объекту принимать различные формы и, следовательно, отображать соответствующее поведение? 👾 — Полиморфизм 👍 — Инкапусляция 🥰 — Абстракция ⚡️ — Ничего из вышеперечисленного Библиотека задач по C#

🧑‍💻 Сёрфить .NET без Blazor Можно ли запустить .NET-приложение в браузере без Blazor? Да, существуют несколько альтернативных методов, которые могут подойти для различных проектов. Один из таких методов — это WebAssembly. Эта технология позволяет компилировать .NET-код в байткод, который выполняется в браузере. Однако WebAssembly не поддерживает все возможности .NET, а настройка может быть сложной. Если нужна большая гибкость, можно использовать JavaScript Interop. Этот подход позволяет обмениваться данными между JavaScript и .NET, что дает возможность интегрировать их в одно приложение. Это решение для тех, кто хочет сохранить существующий JavaScript-код, но при этом использовать возможности .NET в клиентской части. Также можно использовать инструменты вроде Mono и CoreRT для компиляции .NET-приложений в WebAssembly, или платформы, такие как Ooui и Uno Platform, которые упрощают перенос .NET-кода в браузер. ➡️ Подробнее про запуск с WebAssembly можно почитать в статье 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

💡 25 .NET-советов, которые пригодятся почти в любом проекте На одной картинке собрали практики, которые регулярно встречаются в реальных .NET-приложениях: от async/await и LINQ до EF Core, DI, производительности и работы с памятью. Что особенно стоит запомнить: • не блокируйте асинхронный код через .Result и .Wait(); • не создавайте HttpClient вручную — используйте IHttpClientFactory; • для запросов только на чтение не забывайте про AsNoTracking(); • материализуйте коллекции (ToList()) как можно позже; • прежде чем оптимизировать код — измерьте его с помощью BenchmarkDotNet. 📌 Сохраните шпаргалку — она пригодится и начинающим, и опытным C#-разработчикам. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #схема

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector

без подписи

🔗 LINQ за пределами Where() и Select() Большинство разработчиков регулярно используют лишь небольшую часть LINQ. Но за последние версии .NET коллекция операторов заметно выросла. На шпаргалке собраны методы, которые часто упрощают код: 🔹 DistinctBy() — убрать дубликаты по ключу 🔹 Chunk() — разбить последовательность на пачки 🔹 MaxBy() / MinBy() — получить элемент по максимальному или минимальному значению ключа 🔹 CountBy() — посчитать элементы по группам 🔹 AggregateBy() — агрегировать данные по ключу за один проход 🔹 SelectMany() — развернуть вложенные коллекции 🔹 ToLookup() — построить быстрый lookup по ключу 🔹 Zip() — объединить две последовательности попарно 📌 Если до сих пор используете GroupBy(...).Count() или пишете собственную логику для поиска максимального элемента — возможно, в LINQ уже есть готовый оператор. 🔗 Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #схема

😑 Мокать зависимости или тестировать на настоящих? Один из главных споров в тестировании. Одни мокают почти всё вокруг проверяемого класса. Такие тесты быстрые, изолированные и падают только из-за логики самого кода. Другие предпочитают реальные зависимости: базу в контейнере, настоящие сервисы и интеграционные сценарии. Да, такие тесты медленнее, зато они лучше показывают, как код ведёт себя в реальных условиях. На практике многие выбирают компромисс: внешние API и нестабильные сервисы мокают, а свои компоненты стараются тестировать вместе. 💬 А как у вас? 👍 — максимум моков, главное скорость и изоляция. 🔥 — минимум моков, лучше реальные зависимости. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #entry_point

👾 Времена жизни сервисов в ASP.NET Core DI Если постоянно путаете AddSingleton, AddScoped и AddTransient — сохраните эту шпаргалку. На одной схеме показано: ✅ сколько живёт каждый сервис; ✅ где обычно используется; ✅ какую ошибку чаще всего допускают при работе с DI. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #схема

👨‍💻 Мгновенная валидация кода В стремительном темпе разработки важно улавливать ошибки сразу же после правки. Представьте, что можно запускать тесты каждый раз, когда вы сохраняете файл — без лишних кликов и ожидания. Команда дня: dotnet watch test --filter "Category=Unit» Эта команда активирует «наблюдение» за исходниками проекта и при каждом изменении автоматически запускает только те тесты, которые помечены категорией Unit. Вы сразу увидите результаты проверки критичных компонентов, не тратя время на полную прогонку всех тестов. Если вы хотите параллельно следить и за интеграционными тестами, достаточно изменить фильтр: dotnet watch test --filter "Category=Integration» Ещё и интегрировать со скриптами и конвейерами проще простого. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

😬 Microsoft показала ещё один кусочек будущего .NET Вышел .NET 11 Preview 7. Апдейт затронул почти весь стек: C#, Runtime, SDK, ASP.NET Core, EF Core, MAUI, F# и Windows Forms. Главное изменение это перевод NativeAOT в режим по умолчанию в CLI ради заметно более быстрого старта приложений. Из языка подъехали фичи C# 15, среди них паттерны union и помеченные break и continue для управления вложенными циклами. В библиотеки добавили десятичные типы по стандарту IEEE 754 и шифрование паролем для ZIP. Стабильный .NET 11 ожидается в ноябре, а пока Preview 7 можно использовать как полигон: проверить свои проекты на новом SDK и заранее найти проблемы с совместимостью. 👍 — тестирую превью 🔥 — до релиза даже не трогаю 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

🥳🥳 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector

🚀 Анализ изменений с git log Команда git log позволяет понять, как эволюционировал код — просмотреть последовательность коммитов и метаданные. Просмотр истории: git log История коммитов построчно: git log --oneline Граф веток + метки (ветки, теги) для всех веток: git log --graph --decorate --all Показать diff последних двух коммитов: git log -p -2 Коммиты за последние 2 недели от указанного автора: git log --since="2 weeks ago" --author="ProgLib» Настраиваемый формат: короткий хеш, дата, сообщение, автор: git log --pretty=format:"%h %ad | %s%d [%an]" --date=short 💬 Вы смотрите историю log'ом или используете сторонние инструменты? 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

🔖 Помеченные break и continue в C# 15. Выход из вложенных циклов без костылей Знакомая боль. Есть вложенные циклы, и из внутреннего нужно прервать или продолжить внешний. Обычный break выходит только из ближайшего цикла, поэтому приходилось заводить булев флаг и проверять его на каждом уровне, либо прыгать через goto. И то и другое замусоривает логику. В C# 15 у циклов появились метки, а break и continue научились указывать, какой именно цикл они имеют в виду. Метка ставится прямо на нужный цикл. outer: for (int row = 0; row < grid.Height; row++) { for (int col = 0; col < grid.Width; col++) { if (grid[row, col].IsBlocked) continue outer; if (grid[row, col].IsGoal) break outer; } } 🔵 Читается ровно так, как задумано. continue outer переходит к следующей итерации внешнего цикла, а break outer полностью выходит из него, минуя остаток внутреннего. Никаких флагов и подсчёта уровней. Пара нюансов. break можно нацелить и на цикл, и на switch, а continue только на цикл, ведь продолжать switch нечего. И метка привязывается именно к тому циклу, перед которым стоит, поэтому двусмысленности, как с goto, здесь нет. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

👍 Современные помощники для валидации параметров Помните те времена, когда каждый метод начинался с целой простыни проверок входных параметров? Копипаста if (string.IsNullOrEmpty(...)) была ежедневной рутиной: public void ProcessUser(string name, string email, int age) { if (string.IsNullOrEmpty(name)) throw new ArgumentException("Value cannot be null or empty.", nameof(name)); if (string.IsNullOrEmpty(email)) throw new ArgumentException("Value cannot be null or empty.", nameof(email)); if (age < 0) throw new ArgumentOutOfRangeException(nameof(age), "Value must be non-negative."); // Наконец-то бизнес-логика! } Код становился шумным, а реальная логика терялась в океане проверок. Каждый разработчик писал по-своему, сообщения об ошибках отличались, а про опечатки в nameof() вообще молчим. Теперь всё это превращается в лаконичные однострочники: public void ProcessUser(string name, string email, int age) { ArgumentException.ThrowIfNullOrEmpty(name); ArgumentException.ThrowIfNullOrEmpty(email); ArgumentOutOfRangeException.ThrowIfNegative(age); } Стандартная библиотека предлагает методы на все случаи жизни: // Проверки на null ArgumentNullException.ThrowIfNull(user); // Числовые диапазоны ArgumentOutOfRangeException.ThrowIfNegative(temperature); ArgumentOutOfRangeException.ThrowIfZero(divisor); ArgumentOutOfRangeException.ThrowIfNegativeOrZero(count); // Сравнения ArgumentOutOfRangeException.ThrowIfGreaterThan(progress, 100); ArgumentOutOfRangeException.ThrowIfLessThan(quantity, 1); ArgumentOutOfRangeException.ThrowIfEqual(status, Status.Invalid); ArgumentOutOfRangeException.ThrowIfNotEqual(version, expectedVersion); Эти методы — не просто синтаксический сахар. Они воплощают принцип fail-fast: обнаруживай проблемы немедленно, не позволяй невалидным данным распространяться по системе. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view