Ночной билд

Личный блог разработчика: бэкенд, инфраструктура и рабочие заметки без прикрас.

Пишу о бэкенде, инфраструктуре и о том, что остаётся за кадром в рабочих чатах: почему что-то не взлетело с первого раза и что я бы сделал иначе. Без хайпа и без «10 причин выучить новый фреймворк за выходные».

Последние записи

Руки печатают на клавиатуре крупным планом

Рефакторинг легаси: как не сломать то, что работает

19.06.2026

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

Первое правило: сначала понять, потом менять

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

Крупный план микросхем памяти

Кеш — это не магия: разбираемся на пальцах

10.02.2026

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

Зачем вообще нужен кеш

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

Ноутбук и чашка кофе на рабочем столе

Почему я вообще завёл этот блог

02.11.2025

Меня иногда спрашивают, зачем разработчику, который и так весь день пишет тексты — код, документацию, комментарии к пул-реквестам, — заводить ещё и блог. Отвечаю честно: изначально это была попытка навести порядок в собственной голове.

Записки для себя из прошлого

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

Монитор с графиками и дашбордами

Мониторинг без драмы: Prometheus и Grafana для одного разработчика

15.09.2025

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

Минимальный набор, который реально нужен

Мне не нужен полноценный observability-стек с распределённой трассировкой для проекта на одного человека. Нужны три вещи: метрики (Prometheus), визуализация (Grafana) и алерты в удобный канал — у меня это Telegram-бот.

Стол для переговоров в офисе

Собеседования глазами того, кто теперь их проводит

04.08.2025

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

Что я понял, оказавшись интервьюером

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

Крупный план серверного оборудования

PostgreSQL: пять привычек, которые сэкономили мне ночи

25.06.2025

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

1. Индекс на внешний ключ — не автоматический

В отличие от некоторых других СУБД, PostgreSQL не создаёт индекс на колонку внешнего ключа автоматически. Если у вас таблица orders с user_id, ссылающимся на users, и вы не добавили индекс вручную — удаление пользователя с большим числом заказов может заблокировать таблицу на неприятно долгое время. Я завёл себе правило: индекс на FK добавляется в той же миграции, что и сам внешний ключ, без исключений.

Все записи →