Блог
Все записи по порядку — от новых к старым.
19.06.2026
В прошлом году мне досталась задача, которую многие разработчики боятся больше, чем
писать код с нуля: привести в порядок модуль оплаты, которому было пять лет, без тестов и
с единственным человеком в компании, который хоть немного помнил, как он устроен — и этот
человек уже уволился. Вот к каким выводам я пришёл по итогам этой работы.
Первое правило: сначала понять, потом менять
Соблазн сразу начать переписывать код, который выглядит плохо, очень велик. Но за
уродливым на первый взгляд кодом почти всегда стоит история — часто это накопленные
исправления реальных багов и обработка граничных случаев, которые не видны из чтения кода
поверхностно. Прежде чем менять что-то, я потратил неделю просто на чтение: git blame по
ключевым файлам, старые тикеты, связанные с этим кодом, комментарии в коммитах.
10.02.2026
«Просто добавьте кеш» — одна из самых частых рекомендаций, которую дают, когда сервис
начинает тормозить. Проблема в том, что кеш — это не переключатель «быстро/медленно», а
отдельная область со своими собственными способами всё сломать. Разберём по порядку.
Зачем вообще нужен кеш
Кеш имеет смысл, когда вычисление или получение данных дороже, чем их повторное
использование. Классический пример — результат тяжёлого запроса к базе, который не
меняется каждую секунду: список категорий товаров, агрегированная статистика за день,
результат вызова внешнего API с лимитом запросов.
02.11.2025
Меня иногда спрашивают, зачем разработчику, который и так весь день пишет тексты — код,
документацию, комментарии к пул-реквестам, — заводить ещё и блог. Отвечаю честно: изначально
это была попытка навести порядок в собственной голове.
Записки для себя из прошлого
Первые несколько статей я писал вообще без мысли о читателях — просто фиксировал решение
конкретной проблемы, чтобы через полгода не разбираться с ней заново с нуля. Оказалось,
что процесс написания объяснения «для будущего себя» заставляет разобраться в теме
гораздо глубже, чем если бы я просто решил проблему и забыл о ней.
15.09.2025
Когда я в одиночку поддерживаю пет-проект или небольшой внутренний сервис, соблазн
пропустить мониторинг велик — кажется, что можно просто посмотреть логи, если что-то
сломается. На практике так и происходит: что-то ломается, а узнаёшь об этом от
пользователя, а не от системы. После пары таких случаев я всегда настраиваю минимальный
мониторинг ещё до того, как сервис уходит в прод.
Минимальный набор, который реально нужен
Мне не нужен полноценный observability-стек с распределённой трассировкой для проекта на
одного человека. Нужны три вещи: метрики (Prometheus), визуализация (Grafana) и алерты в
удобный канал — у меня это Telegram-бот.
04.08.2025
Последние два года я по очереди сижу по обе стороны стола: иногда прохожу собеседования
сам, иногда провожу их для нашей команды. Взгляд с обеих сторон сильно изменил моё
отношение к процессу.
Что я понял, оказавшись интервьюером
Самое неожиданное открытие — насколько сильно на решение влияет не то, что кандидат знает,
а то, как он рассуждает вслух, когда чего-то не знает. Кандидат, который честно говорит «я
не уверен, но предположу вот так, и вот как бы я это проверил», почти всегда производит
лучшее впечатление, чем тот, кто уверенно называет неверный ответ.