Главная on Ночной билд

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

Fri, 19 Jun 2026 00:00:00 +0000

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

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

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

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

Tue, 10 Feb 2026 00:00:00 +0000

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

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

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

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

Sun, 02 Nov 2025 00:00:00 +0000

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

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

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

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

Mon, 15 Sep 2025 00:00:00 +0000

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

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

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

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

Mon, 04 Aug 2025 00:00:00 +0000

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

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

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

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

Wed, 25 Jun 2025 00:00:00 +0000

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

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

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

Что я узнал, читая чужой код по вечерам

Fri, 30 May 2025 00:00:00 +0000

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

Почему не хватало кода с работы

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

Docker Compose вместо Kubernetes: когда простота выигрывает

Tue, 22 Apr 2025 00:00:00 +0000

Когда я рассказываю коллегам, что в одном из рабочих проектов мы сознательно не стали переезжать на Kubernetes и остались на Docker Compose, реакция обычно одна и та же: удивлённо поднятые брови. Постараюсь объяснить логику этого решения.

Контекст проекта

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

Логи, которые не врут: заметки о структурированном логировании

Tue, 18 Mar 2025 00:00:00 +0000

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

Как выглядела проблема

Классическая строка лога вида log.Printf("user %s created order %d", userID, orderID) прекрасно читается в консоли во время разработки. Но когда нужно найти все ошибки по конкретному пользователю за последний час среди миллионов строк в централизованном хранилище логов, текстовый поиск по подстроке — это очень медленный и ненадёжный способ.

Почему я отказался от микросервисов в пет-проекте

Thu, 20 Feb 2025 00:00:00 +0000

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

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

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

Мой домашний сервер: три года экспериментов

Thu, 09 Jan 2025 00:00:00 +0000

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

С чего началось

Первая версия была наивной: один Raspberry Pi, на котором крутился Pi-hole для блокировки рекламы на весь дом. Через месяц я добавил второй Pi под домашний DNS-резолвер, а ещё через два — списанный ноутбук, на котором поднял Docker и начал пробовать всё, что было интересно, но страшно тащить в рабочий контур: новые версии баз данных, необычные конфигурации reverse-proxy, экспериментальные инструменты мониторинга.

Как я перестал бояться очередей сообщений

Thu, 14 Nov 2024 00:00:00 +0000

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

С чего всё началось

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

Выступления

Mon, 01 Jan 0001 00:00:00 +0000

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

«Почему очередь не резиновая», локальный бэкенд-митап, 2025

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

«Логи для человека, а не для машины», DevOps-встреча, 2025

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

Контакты

Mon, 01 Jan 0001 00:00:00 +0000

Проще всего написать по почте — отвечаю не мгновенно, но отвечаю всегда.

Почта: dmitry@nochnoj-bild.cc
Город: Нижний Новгород, Россия
Часовой пояс: UTC+3

Если пишете по поводу статьи — укажите, о какой именно идёт речь, так быстрее найду контекст.

Обо мне

Mon, 01 Jan 0001 00:00:00 +0000

Меня зовут Дмитрий Ласточкин, я пишу бэкенд уже больше десяти лет: начинал с PHP-скриптов для интернет-магазинов, потом перешёл на Java, а последние годы почти всё время провожу в Go и Python — в зависимости от того, что просит проект.

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

Проекты

Mon, 01 Jan 0001 00:00:00 +0000

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

Ночной сторож

Маленький демон на Go, который раз в минуту проверяет доступность моих домашних сервисов и шлёт уведомление в мессенджер, если что-то легло. Написан за один вечер, живёт на Raspberry Pi уже третий год и ни разу не подвёл.

Заметки → RSS

Скрипт на Python, который превращает папку с markdown-заметками в RSS-ленту. Использую его сам, чтобы читать собственные черновики в том же ридере, что и остальные блоги.