Перед тем как читать новый проект, я первым делом иду не в код, а в Git.

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

Что меняют чаще всего

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

Показывает 20 файлов, которые меняли чаще всего за последний год. Верхние строчки списка обычно быстро находят тот самый файл, к которому все боятся прикасаться.

Кто реально поддерживает проект

git shortlog -sn --no-merges

Сразу видно распределение коммитов между разработчиками и потенциальный автобусный фактор.

Где чаще всего чинят баги

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

Если файл часто появляется и здесь, и в списке самых изменяемых файлов — это один из главных источников технического долга.

Проект набирает темп или затухает

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

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

Как часто приходится тушить пожары

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

Откаты, хотфиксы и экстренные исправления многое говорят о качестве релизного процесса.

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

👉 @KodBlog

Вышел roadmap для SqlClient

https://github.com/dotnet/SqlClient/blob/main/roadmap.md

Стоит посмотреть, если тебе интересны:

- особенности работы пула соединений (connection pooling)
- сценарии аутентификации (Entra ID, MSI и другие)
- производительность и надёжность под высокой нагрузкой

На этом этапе обратная связь от сообщества ещё может повлиять на архитектурные и технические решения.

#dotnet #sqlserver

👉 @KodBlog

Создаём Базовый Компонент для Всех Компонентов в Blazor

При разработке Blazor-приложения может понадобиться пользовательский базовый компонент для всех остальных компонентов. Это полезно для совместного использования общих функций, таких как токены отмены, логирование или управление состоянием, во всех компонентах. Вместо добавления @inherits YourBaseComponent в каждый файл Razor, вы можете использовать файл _Imports.razor для глобальной установки базового компонента.

Создадим файл _Imports.razor в папке, к компонентам которой нужно применить базовый компонент. Все файлы Razor в этой папке и её подпапках будут наследовать указанный базовый компонент.

@inherits YourNamespace.CustomComponentBase

Файл _Imports.razor обрабатывается перед любым компонентом Razor в том же каталоге или его подкаталогах. Все компоненты затем автоматически наследуют от CustomComponentBase без необходимости объявлять @inherits в каждом файле.

Пример: CustomComponentBase с CancellationToken
Вот пример базового компонента, который предоставляет CancellationToken всем производным компонентам. Это полезно для отмены асинхронных операций при удалении компонента:

@* CustomComponentBase.razor (Razor) *@
@implements IDisposable

@code {
  private readonly CancellationTokenSource 
   _cts = new CancellationTokenSource();

  public CancellationToken 
   CancellationToken => _cts.Token;

  public void Dispose()
  {
    _cts.Cancel();
    _cts.Dispose();
  }
}

Теперь все наши компоненты могут получить доступ к свойству CancellationToken без какой-либо дополнительной настройки:

@* MyComponent.razor (Razor) *@
@* Не нужно использовать @inherits, т.к. _Imports.razor импортируется автоматически *@

<h3>Мой компонент</h3>

@code {
  protected override async Task OnInitializedAsync()
  {
    // Используем CancellationToken из базового компонента
    await LoadDataAsync(CancellationToken);
  }

  private async Task LoadDataAsync(CancellationToken ct)
  {
    // … асинхронный код …
    await Task.Delay(1000, ct);
  }
}

Переопределение базового компонента для конкретных компонентов
Если конкретному компоненту требуется другой базовый компонент или вообще никакой, вы можете объявить @inherits непосредственно в файле этого компонента. Явное объявление имеет приоритет над _Imports.razor:

@* MyComponent.razor (Razor) *@
@inherits ComponentBase

@* Этот компонент будет использовать ComponentBase вместо CustomComponentBase *@

Организация файлов _Imports.razor

Можно иметь несколько файлов _Imports.razor в разных папках, чтобы применять разные базовые компоненты к различным разделам приложения. Приоритет имеет ближайший файл _Imports.razor в иерархии каталогов. Например, /Components/_Imports.razor применяется ко всем компонентам в этой папке /Components/Admin/_Imports.razor применяется специально к компонентам папки Admin. Такой иерархический подход обеспечивает точный контроль над тем, какие компоненты наследуют от каких базовых классов.

👉 @KodBlog

Практическое применение архитектуры Vertical Slice в ASP.NET Core

https://www.telerik.com/blogs/practicing-vertical-slice-architecture-aspnet-core

Автор: Assis Zang

#aspnetcore

👉 @KodBlog

Перестаньте использовать исключения для управления логикой приложения

Вот почему 👇

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

Но есть проблема: исключения подходят далеко не для всех сценариев.

Работая архитектором ПО и .NET-разработчиком, я пришёл к простому выводу:

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

👉 Исключения нужны для обработки действительно нештатных ситуаций.

Но ими не стоит заменять обычную бизнес-логику и ожидаемые условия.

Основные недостатки такого подхода:

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

• Снижение читаемости — try/catch ломает линейный поток чтения кода

• Вложенность — отладка и навигация по коду становятся менее удобными

• Потери производительности — обработка исключений обходится дороже обычных проверок (даже с улучшениями в .NET 9)

Что использовать вместо этого?

✅ Result Pattern

Вместо выбрасывания исключений метод возвращает объект Result.

Так успех и ошибка становятся явной частью контракта метода.

📌 Обычно объект Result содержит:

1️⃣ IsSuccess / IsError — успешно ли выполнена операция

2️⃣ Value — результат выполнения при успехе

3️⃣ Error — информация об ошибке при неудаче

Плюсы такого подхода:

↳ Более предсказуемые API

↳ Более чистый поток выполнения

↳ Проще писать unit-тесты

↳ Лучше производительность

Для этого паттерна уже есть готовые библиотеки:

• FluentResults

• CSharpFunctionalExtensions

• Ardalis.Result

• ErrorOr

Но на практике сторонние пакеты вовсе не обязательны.

👉 @KodBlog

Как работает git?

На изображении схематично изображён процесс работы с Git — системой контроля версий.

Workspace: Рабочее пространство, где находятся файлы проекта (например, .git, src, index.html).
🟢Команда git add перемещает изменения в Stage (область индексации).
🟢Команда git reset отменяет индексацию изменений.

Stage: Область индексации, где изменения подготавливаются для фиксации.
🟢 Команда git commit сохраняет изменения в локальном репозитории.

Local Repository: Локальный репозиторий, где хранятся зафиксированные изменения.
🟢 Команда git push отправляет изменения в удалённый репозиторий.

Remote Repository: Удалённый репозиторий, например, на платформах GitLab, GitHub или Bitbucket.
🟢 Команда git fetch извлекает изменения с удалённого репозитория.
🟢 Команда git pull объединяет изменения удалённого и локального репозиториев (эквивалентно git fetch + git merge).

В нижней части схемы представлена последовательность действий при выполнении команды git pull. 😮

Эта схема полезна для понимания основных этапов работы с Git.

👉 @KodBlog

Сравнение, которое снова разожгло споры о лаконичности языков программирования.
На скриншоте один и тот же HTTP-сервер с маршрутом "/" и ответом "Hello world" реализован на Clojure и C#.

Вариант на C# использует минимальный API из ASP.NET Core и укладывается в несколько строк.
Реализация на Clojure выглядит заметно объёмнее: отдельное описание обработчика, заголовков ответа и запуск Jetty-сервера.

👉 @KodBlog

Большинство разработчиков изучают PostgreSQL в неправильном порядке.

Вот мой личный план изучения, разделённый на 7 уровней.

Не начинайте сразу с:

* тюнинга производительности
* индексов
* репликации
* партиционирования

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

1️⃣ Основы SQL

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

* SELECT
* WHERE
* ORDER BY
* GROUP BY
* агрегатные функции
* базовые JOIN'ы
* LIMIT и OFFSET
* DISTINCT

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

2️⃣ Моделирование данных

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

Сюда входят:

* таблицы
* схемы
* первичные ключи
* внешние ключи
* ограничения
* связи
* нормализация
* типы данных
* соглашения по именованию

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

3️⃣ Продвинутые запросы

На этом этапе вы переходите от простых запросов к более выразительным SQL-конструкциям:

* JOIN'ы
* подзапросы
* CTE
* оконные функции
* условные выражения
* продвинутые агрегации
* запросы к JSON и JSONB
* операции с массивами

Этот уровень позволяет решать сложные бизнес-задачи непосредственно внутри базы данных.

4️⃣ Индексы

Сначала вас волнует, работает ли запрос вообще.

Потом начинает волновать, работает ли он быстро.

Здесь в игру вступают индексы.

Нужно понимать:

* индексы B-tree
* индексы GIN
* индексы GiST
* частичные индексы
* составные индексы
* уникальные индексы
* обслуживание индексов
* когда индексы помогают
* когда индексы вредят

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

Цель — понимать, как ваше приложение читает данные.

5️⃣ Тюнинг производительности

На этом уровне вы учитесь анализировать, что база данных делает на самом деле.

Важные темы:

* EXPLAIN
* EXPLAIN ANALYZE
* планирование запросов
* анализ использования индексов
* VACUUM
* ANALYZE
* раздувание таблиц (table bloat)
* статистика
* логи медленных запросов
* настройки памяти и I/O
* настройка конфигурации

Тюнинг производительности — это не угадывание.

Это расследование.

6️⃣ Администрирование

PostgreSQL в продакшене — это не только написание запросов.

Её также нужно безопасно и надёжно эксплуатировать.

Этот уровень включает:

* роли и права доступа
* резервное копирование и восстановление
* репликацию
* мониторинг и оповещения
* пулинг соединений
* настройку безопасности
* миграции и обновления
* процессы обслуживания
* планирование аварийного восстановления

7️⃣ Масштабирование и экосистема

Масштабирование — это верхний уровень, а не отправная точка.

Сюда входят:

* партиционирование
* реплики для чтения
* высокая доступность
* логическая репликация
* шаблоны шардирования
* управляемые сервисы PostgreSQL
* инструменты наблюдаемости
* интеграции с экосистемой
* расширения вроде PostGIS, pg_trgm и TimescaleDB

Прочный фундамент — ключ к изучению чего угодно.

👉 @KodBlog

Воскресенский совет для .NET-разработчиков: перестаньте использовать DateTime.UtcNow напрямую в коде.
Используйте TimeProvider.

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

На примере:

public sealed class TrialService(TimeProvider clock)
{
    public bool IsExpired(DateTimeOffset startedAt) =>
        clock.GetUtcNow() >= startedAt.AddDays(14);
}

В тесте:

var clock = new FakeTimeProvider(startedAt);
var service = new TrialService(clock);

clock.Advance(TimeSpan.FromDays(15));

Assert.True(service.IsExpired(startedAt));

Никаких задержек, никаких сюрпризов от DateTime.UtcNow. Просто перематываете время вперёд в тестах и проверяете нужный сценарий.

https://learn.microsoft.com/ru-ru/dotnet/standard/datetime/timeprovider-overview

👉 @KodBlog

Нашёл интересный инструмент для поиска и устранения дублирующегося кода.

Называется Deslop. Написан на Rust, но работает не только с Rust-проектами — поддерживает Python, Dart и C#.
Инструмент анализирует кодовую базу, находит дубликаты и помогает избавиться от повторяющихся фрагментов. Автор предлагает просто установить его в VS Code или любой другой форк редактора и использовать прямо в процессе разработки.

Автор проекта также собрал отдельную подборку статей и исследований, которые легли в основу алгоритмов Deslop.

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

👉 @KodBlog

🚀 В .NET 11 Preview 6 появилась новая возможность из C# 15 — extension indexers.

Теперь индексаторы можно объявлять прямо внутри extension-блоков:

static class E
{
    extension(...)
    {
        int this[...] { get => ...; set => ...; }
    }
}

Это позволяет добавлять индексаторы к существующим типам без изменения их исходного кода, так же как сегодня работают extension methods.
Фича уже влита в C# 15 Preview и доступна в .NET 11 Preview 6. 🔥

https://github.com/dotnet/csharplang/blob/main/proposals/extension-indexers.md

👉 @KodBlog

Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:

COPY . .
RUN npm install

должно быть:

COPY package*.json ./
RUN npm install
COPY . .

почему это важно?

docker кэширует каждую инструкцию как отдельный слой
исходный код меняется с каждым коммитом
поэтому COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.

👉 @KodBlog

Ваш API тормозит в продакшене.

Вы открываете логи.

Сотни записей.

Что дальше?

Логи полезны, но в распределённом .NET-приложении они обычно показывают лишь отдельные фрагменты картины.

Один запрос может пройти через:

→ API
→ другой сервис
→ PostgreSQL
→ Redis
→ брокер сообщений

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

Здесь помогают OpenTelemetry и Grafana.

OpenTelemetry собирает телеметрию приложения:

→ трейсы для отслеживания пути запроса
→ логи с контекстом
→ метрики состояния системы

Grafana позволяет анализировать всё это в одном месте.

В результате можно быстро ответить на вопросы:

• Какой запрос был медленным?
• Где именно он потерял время?
• Какой SQL-запрос вызвал задержку?
• Какие логи относятся к этому конкретному запросу?

Вместо поиска иголки в стоге логов вы получаете полную картину происходящего — от входящего HTTP-запроса до последнего вызова базы данных.

👉 @KodBlog

Большинству разработчиков в 2026 году уже не обязательно платить за AI-инструменты.

Бесплатные тарифы стали настолько щедрыми, что ими можно закрыть почти весь рабочий процесс.

Мой стек за $0:

→ Rider — бесплатно для некоммерческого использования
→ Cursor Hobby — AI прямо в редакторе
→ NotebookLM — работа с документацией и RFC через RAG
→ Granola — конспекты встреч и action items
→ Grammarly — исправление английского на лету
→ Gamma — генерация презентаций за минуты
→ Excalidraw — архитектурные диаграммы без боли

Код, документация, встречи, презентации, диаграммы и AI-помощники.

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

👉 @KodBlog

Собрать 500 файлов без единой ошибки и всё равно не получить исполняемый файл. Звучит странно, но это чистая правда.

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

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

Собирать по кирпичикам, а не лепить кое-как. Есть статические линкеры и динамические, но об этом в другой раз.

👉 @KodBlog

Что нового в PostgreSQL 19?

PostgreSQL 19 продолжает одну важную тенденцию. Postgres превращается во что-то гораздо большее, чем просто реляционная база.

Самые интересные новинки:

Графовые запросы через SQL/PGQ
PostgreSQL 19 научился выполнять SQL Property Graph Queries. Теперь можно запрашивать связи прямо на SQL, без отдельной графовой базы. Пригодится для соцсетей, рекомендаций, поиска мошенничества и графов зависимостей.

GROUP BY ALL
Вместо того чтобы перечислять все колонки в GROUP BY, пишешь GROUP BY ALL. Postgres сам группирует по неагрегатным колонкам. Меньше шаблонного кода, меньше ошибок.

WAIT FOR LSN
Фича для приложений, которые используют реплики чтения. Позволяет подождать, пока реплика догонит основную базу, прежде чем читать данные. Полезно для консистентности «прочитал то, что написал».

Лучшая поддержка JSON
Postgres и дальше улучшает работу с полуструктурированными данными, не теряя при этом SQL, индексы, соединения и транзакции.

PostgreSQL 19 пока в бете. Детали могут поменяться к релизу. Но направление понятно. Postgres потихоньку становится одной платформой под всё: реляционные данные, документы, графы, аналитика и векторы для AI.

👉 @KodBlog

Мой племянник учится на втором курсе программной инженерии. Позвонил недавно, попросил помочь с поиском стажировки. И среди прочего спросил, где лучше разобраться с Git. Я удивился. На втором курсе студенты всё ещё обходят Git стороной. А потом это бьёт по ним на собеседованиях.

Я посоветовал ему отличный гайд от Beej.

Он перезвонил сегодня. Полный восторга. Делился впечатлениями. Так что вот, снова рекомендую. Для всех студентов и всех, кто только начинает знакомство с Git.

https://beej.us/guide/bggit/

👉 @KodBlog

20 законов разработки, которые должен знать каждый инженер

1. Закон Галла: Работающая сложная система вырастает из работающей простой.

2. KISS: Делай проще. Всё остальное — оверхеад.

3. Закон Конвея: Компании проектируют системы, которые повторяют структуру их коммуникаций.

4. Закон Хайрума: У достаточно большого API уже неважно, что ты обещал в контракте. Кто-нибудь уже зависит от каждого observable-поведения твоей системы.

5. CAP-теорема: Выбери два: консистентность, доступность, устойчивость к разделению.

6. Закон Завински: Любая программа разрастается до тех пор, пока не научится читать почту.

7. Закон Брукса: Добавление людей в опаздывающий проект делает его ещё более поздним.

8. Эффект Рингельмана: Производительность каждого участника группы падает с ростом группы.

9. Закон Прайса: Половину работы делают квадратный корень от всех людей.

10. Эффект Даннинга — Крюгера: Новички переоценивают свои способности, эксперты — недооценивают.

11. Закон Хофштадтера: Всё занимает больше времени, чем ты планируешь, даже с учётом этого закона.

12. Закон Паркинсона: Работа расширяется, чтобы заполнить всё отведённое на неё время.

13. Закон Гудхарта: Когда метрика становится целью, она перестаёт быть хорошей метрикой.

14. Закон Гилба: Измерять неточно лучше, чем не измерять вообще.

15. Принцип Кнута: Забудь о микрооптимизациях в 97% случаев. Преждевременная оптимизация — корень всех зол.

16. Закон Амдала: Ускорение одной части системы ограничено долей времени, которое эта часть реально используется.

17. Закон Мёрфи: Если что-то может пойти не так, оно пойдёт не так.

18. Закон Постела: Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь.

19. Закон Стерджена: 90% всего на свете — фигня.

20. Закон Каннингема: Лучший способ получить правильный ответ в интернете — не задать вопрос, а написать неправильный ответ.

👉 @KodBlog