Контракт лжет вам. Виноват ли DI?

Столкнулся с ситуацией, когда есть необходимость батчевого (пакетного) запроса данных из определенного сервиса.

Нашел подходящую RPC-ручку, которая принимает на вход список ID, и возвращает нужный ответ.

Тестирую со значением [123456789] — все отлично. Радуюсь.

Уже собрался идти в реализацию, но решил протестировать работу с несколькими ID, хотя казалось бы зачем, когда контракт однозначный?

Подаю на вход [123456789, 987654321] и получаю пустой ответ.

Вспоминаю, что у меня была фильтрация в запросе, начинаю думать, что проблема в ней и несколько значений обрабатывается как-то иначе, раз ответ не формируется (возможно, все отфильтровалось).

Убираю фильтрацию — результат такой же.

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

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

Ситуация не радует, задачку растягивать не хочется и я начинаю искать по ключевым словам что-то похожее в канале поддержки сервиса и вдруг нахожу ответ...

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

Под капотом сервиса зашит клиент, который обращается к шардированной БД. Номер шарда определяется по ID, вот так и получается, что при указании массива, вероятность, что значения окажутся на одном шарде, крайне мала.

В результате получили явное нарушение семантики контракта.

При этом за счет того, что соответствующий handler реализует DI, то, вероятно, раньше (N лет назад), все действительно нормально работало, когда не было шардов или клиент, обращающийся к БД, был другой.

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

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

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

За мощью абстракций также могут скрываться подобные сюрпризы. Учитывайте это при проектировании.

@time2code

Эффект бабочки

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

Кажется — это же основное правило цифрового бойскаута: "Оставь после себя код лучше, чем был до".

Но это работает не всегда. Особенно в Биг Техах.

Часто любое изменение (даже совершенно небольшое) влечет за собой множество проблем: от элементарной правки юнит-теста (или добавления нового) до полного регресс-тестирования основных сценариев или остановки прода.

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

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

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

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

Очень легко отвлечься мыслями и уйти в серьезный рефакторинг.

Тема плотно перекликается с атомарными ПР-ами, про которые рассуждал в другом посте.

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

1. Атомарные коммиты — в случае проблем это поможет сделать легкий реверт изменений.

2. Мониторинг метрик, ошибок, состояния и здоровья базы, если делаете что-то, что прямо или косвенно на них может повлиять.

3. Обсудить с командой: асинхронно или на грумминге, возможно есть ресурс на рефакторинг, который можно вынести за скобки текущих работ и заделиверить в спокойном ритме.

Интересно, как много кейсов, когда "минорные" правки приводили к чему-то серьезному и непредсказуемому?

@time2code

Default Mode Network: дар и проклятие

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

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

Default mode network

Кажется, что может быть проще, чем выключить компьютер и перестать думать про работу.

На практике же это работает иначе.

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

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

Из жизни

Однажды утром, занимаясь рутинным делом — сушкой собаки после прогулки, меня прострелило от озарения, что на 113 строчке обновленного go-файла в обработчике асинхронного события может возникнуть проблема, если не провалидируем данные определенным образом.

Мысль возникла из ниоткуда. Я не думал про задачу, не думал про работу, размышлял о чем-то отвлеченном.

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

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

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

Несмотря на то, что это может быть удобно, в фоновом режиме это медленно изматывает, если ничего не предпринимать.

Что делать?

Мне и многим IT-специалистам помогает медитация, физически изнуряющий спорт или хайкинг, так как позволяет на какое-то время утихомирить свой мозг, расслабиться и по-настоящему отвлечься.

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

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

В этом году решил сфокусироваться на построении прочной системы тренировок:

> Бассейн 1 раз в неделю (уже стало привычкой)
> Постепенно добавляю большой теннис в таком же количестве
> Несколько беговых тренировок, совмещенных с силовыми (целевая регулярность — минимум 3 раза в неделю)
> Медитация (пока в планах, но цель — от 5 минут в день)

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

@time2code

LLM и тесты

На днях Федя Борщёв написал пост про генерацию тестов при помощи LLM.

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

Львиная доля аудитории в комментариях, очевидно, встала на защиту LLM и тезиса, что, если у вас ничего не получается, значит, вы ее неправильно готовите :)

Когда это работает

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

Из опыта

В реальности же бывает по-разному. Часто в продуктовых инициативах (особенно в них) все начинается с какого-нибудь коленочного MVP/MLP, который после своего успеха может резко начать эволюционировать.

А так как запуск был срочный, что бывает часто в биг техах, то архитектура была продумана ровно для уровня MVP + может быть чуть за его пределами с каким-то запасом.

Аппетит приходит во время еды (или успешного результата запуска) и какой-то продуманный запас (=гибкость), заложенный на этапе согласования технического решения, довольно быстро исчерпывается, а бизнес делает резкое пике, приводя вас в такие бизнес-сценарии, которых вы и представить не могли еще совсем недавно.

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

Это начинает явно проявляться в тестах.

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

В какой-то момент мы решаем дописать новую функциональность и покрыть ее тестами. Мы хотим использовать LLM, так как знаем, что она не подведет и вот тут начинается самое интересное.

Оказывается, что на подготовку промта начинает уходить какое-то бесчисленное количество времени. Ведь, чтобы его подготовить:

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

Это растягивается на несколько итераций...

Польза ручного написания тестов

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

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

❗️ Да, LLM может тоже это все подсказать, если опять же подготовить хороший промт, но когнитивная нагрузка, затраченная на проверку всего сгенеренного окупит ли автоматизацию?

Еще один консерн у меня был как у ревьюера.

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

А вот если тесты есть, их много, но их сгенерировала LLM, то как их реально проверить? Попросить другую LLM это сделать?

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

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

Не исключаю, что это со временем поменяется, постоянно экспериментирую и даю второй (третий и т.д.) шанс, но пока так.

@time2code

Transactional outbox — опыт других

О паттерне

Разбирая 3 главу книги "Микросервисы", уже упоминал этот паттерн.

Описание от Криса Ричардсона здесь.

Паттерн довольно распространенный. В Авито, например, используется самописный коннектор для решения этой проблемы.

Для PostgreSQL можно использовать pgq.

Что использует финтех

Вчера сходил на первый митап, проводимый Т-банком в их новом "ИТ-хабе" в Петербурге.

Рассказали две темы: как готовить контроллеры для K8S и про свою реализацию Transactional Outbox.

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

Доклад про Outbox вышел неплохим. Реальный опыт, итерационная разработка с несколькими реализациями паттерна и множество шишок с последствиями для пользователей.

В сухом остатке предлагаю посмотреть на схему БД, к которой пришли ребята, и производительный (по их бенчмаркам) запрос из таблички "outbox", который выполняется за 20ms+-.

Таблица outbox:

CREATE TABLE kafka_outbox (
    "offset" BIGSERIAL,
    transaction_id XID8 NOT NULL,
    event_id UUID NOT NULL,
    topic TEXT NOT NULL,
    key TEXT NOT NULL,
    payload JSONB NOT NULL,
    headers JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    
    PRIMARY KEY (transaction_id, "offset", created_at)
)  PARTITION BY RANGE (created_at);

Выборка из outbox:

SELECT * FROM (

    SELECT "offset", transaction_id, key, topic, payload, headers FROM kafka_outbox
    WHERE transaction_id = $1 AND "offset" > $2
    AND transaction_id < pg_snapshot_xmin(pg_current_snapshot())

    UNION ALL

    SELECT "offset", transaction_id, key, topic, payload, headers FROM kafka_outbox
    WHERE transaction_id > $1
    AND transaction_id < pg_snapshot_xmin(pg_current_snapshot())

) AS messages

ORDER BY transaction_id, "offset"
LIMIT $3;

Из интересного в последнем запросе — использование UNION'а. Такой подход предложил собственный AI. До этого использовался один SELECT со сложными условиями, который выполнялся очень долго (порядка 12 секунд).

Наверняка, что-то еще здесь можно оптимизировать, но перепробовав 3-4 варианта, в конечном итоге остановились на этом.

Переход от одного варианта к другому сопровождался неприятной в поддержке миграцией. Учитывайте это при проектировании.

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

@time2code

Сентябрь 2025:

ключевые события

✔️ Полноправно вступил в должность «Старшего инженера».

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

✔️ Записался на курс “Системный дизайн высоконагруженных проектов” и уже приступил к нему. Позже будет пост сравнение с курсом «Анализ систем», который проходил в прошлом году.

✔️ Принял участие в командной Гонке Героев URBAN. Крутой формат, где совместная работа важнее индивидуальных достижений.

✔️ Количество внешних запросов на менторство выросло (самый популярный — составление ИПР), настало время делиться опытом, чувствую, что могу быть полезным. В этом году больше не набираю, если вдруг у вас есть запрос, то напишите в лс, попробую асинхронно что-то предложить или записать на следующий год.

посты

⭐️ Transactional outbox — опыт других -> читать

🔖 LLM и тесты -> читать

🔖 Default Mode Network: дар и проклятие -> читать

🔖 Загружаем ключевые идеи V5 -> читать

🔖 Контракт лжет вам. Виноват ли DI? -> читать

🔖 Эффект бабочки -> читать

#дайджест

@time2code

Боль при переезде на новое железо осталась в прошлом?

Всегда пугал переезд: на новый ноутбук, ОС, телефон и т.д.

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

Но сейчас про бытовое.

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

Возможно, если бы 5 лет назад не пересел бы на MacOS, то пост вышел бы другим, но здесь оказалось все тривиально: есть ассистент миграции, который поможет все перенести на новую машину AS IS.

Можно просто подключить старый ноут к новому или выбрать одну WiFi-сеть, и ассистент миграции все сделает сам.

Мне же потребовалось чуть больше приседаний, так как решил пойти через бэкап на HDD и дальнейшее восстановление из него.

Все прошло гладко, но по времени это заняло порядка 5 часов (400GB данных):
- бэкап на HDD занял несколько часов;
- восстановление из HDD еще несколько часов.

Возможно, при использовании хорошего SSD с подключением через type-c заняло бы гораздо меньше времени (я использовал простой советский HDD с usb 3.0 и адаптером под type-c), но это для меня было и не так важно.

Из приятного

1. Миграция прошла успешно. Восстановление из бэкапа не доставило проблем — оставил на ночь, а на утро ждало приятное сообщение об окончании переноса данных.

2. Переезд прошел бесшовно (даже многие браузерные сессии не были сброшены), поэтому ощущение было, что просто произошло штатное обновление системы.

Что могло быть лучше?

Со времен прожига двухстороннего вербатима для Xbox360 остались неприятные воспоминания, что многочасовое ожидание записи данных легко может быть прервано на 99%.

Это означало, что диск идет в утиль и все предстоит проделывать заново. Поэтому успешный перенос данных уже расцениваю как ультимативный успех.

Конечно, хотелось бы, чтобы подобные миграции происходили в пределах 10-15 минут, но, вероятно, тут упираемся в производительность железа.

Так или иначе, но что у Apple хорошо — это бесшовный переезд со старых устройств на новые. Это крайне ценный UX.

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

@time2code

Лучшее, чем можно заняться в отпуске*

*Конечно, кроме полноценного отдыха.

Давно не было нормального отпуска, чтобы дней на 14, и можно было бы ни о чем не думать, по крайней мере, первые дня два.

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

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

Как?

Я придумал простой алгоритм, который на удивление, во многом совпадает с популярным Getting Things Done, поэтому почему бы не использовать оригинальный GTD, раз ему уже больше 20 лет (смотреть диаграмму).

Базово это выглядит так:

1️⃣ Очищаем голову и наполняем INBOX

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

2️⃣ Сортируем

Действие требует менее 2-х минут? — Делаем сразу. Иначе размечаем и организуем по другим категориям.

3️⃣ Выполняем

Делаем задачи в порядке приоритетов и срочности.

4️⃣ Обзор

Еженедельно сверяемся с текущими задачами и проектами.

Инструменты

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

Думаю, начну наполнять INBOX в Obsidian + медитативный фон и 2 таймера по 50 минут с перерывом 10.

Посмотрим, что из этого выйдет.

@time2code

Собираем требования

На курсе по System Design, про который писал ранее, первым заданием стал выбор проекта, который будет держать 100M DAU (daily active users).

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

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

Но иногда учебный проект — это всего лишь проект и нужно быть проще :)

Так или иначе, я смог определиться с темой, которая мне потенциально интересна, только спустя несколько недель.

И это: сервис по поиску событий и активностей, с календарем, новостями и общением!

Определившись, мне теперь предстоит проработать его "предизайн", как на реальной секции SD:

1. Продумать базовые сценарии и роли.
2. Собрать вместе функциональные и нефункциональные требования.
3. Оценить необходимые ресурсы для обслуживания 100M DAU.
4. Презентовать.

Планирую сделать серию постов про ход проекта. Если вдруг тема откликнется, постараюсь делать это подробнее.

@time2code

Highload. Инструкция по выживанию

Прошло 2 года с посещения конференции для разработчиков высоконагруженных систем Highload++ 2023, которая для меня стала первой в статусе Go-разработчика.

Уже описывал достоинства и недостатки подобных мероприятий. С того времени мало что изменилось за исключением цены, которая выросла в 1.5 раза.

Ценник для личного участия я бы назвал заградительным,(убежден, что есть более полезное приложение для 100K), поэтому основная аудитория — корпорации, для которых не составит никакого труда отправить вас на конференцию за счет бюджета на обучение или как выступающего с докладом.

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

Выбрать цель

Без цели на конференции можно легко праздно провести время.

Полезными могут быть:

- новые знания (лучшие практики), которые можно внедрить в процессы компании;
- поиск возможных решений проблемы/задачи;
- нетворкинг или поиск новых клиентов;
- поиск работы — многие передовые компании будут представлены со стендами, но лучше, конечно, идти через нетворкинг напрямую;
- поиск идеи/темы для исследования.

Самая полезная конференция (и первая в карьере) случилась в 2017 году, у меня было 2 цели:

1. Поиск возможного решения по использованию информационного моделирования в эксплуатации (задача компании).
2. Материал для написания магистерской диссертации (+поиск наставника).

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

В этом году я еду с комбинированной целью: прощупать пульс IT-индустрии, найти новые практики, которые можно внедрить в процессы компании, и нетворкинг.

Спланировать

Планирую план посещения конференции формировать с учетом описанных целей выше. Лучше подготовиться заранее, накануне, чтобы не пытаться планировать в центре многотысячной толпы (пробовал, неудобно).

Активно участвовать

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

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

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

А вы видите пользу от профильных конференций? Принимаете очное участие или онлайн?

> Если тоже будете на Хайлоаде 6-7 ноября и готовы встретиться, то пишите — попьем кофе.

@time2code

Октябрь 2025:

ключевые события

✔️ Потушил пожар на проде: сервис стал "захлебываться" из-за возникших блокировок у PG, очередь новых сообщений ощутимо стала расти вместе с лагом на сохранение... Хорошо, что лучшие практики не подвели (была и внутренняя очередь с ретраями, был и fallback при деградации сервиса), поэтому на пользователях это не отразилось.

✔️ Изучил основные характеристики хорошего кода: законченноть, понятность, эволюционность. Попрактиковался находить их в своих проектах.

✔️ Рассмотрел как можно улучшать функции, применяя SRP с точки зрения ФП.

✔️ Долгожданные 14 дней почти беспрерывного отпуска, за которые удалось собрать внушительный INBOX задач и проектов, создающих серьезное фоновое напряжение (большую часть за время отпуска закрыл).

✔️ Очередные 21K уже не стали чем-то необычным, но приятно, что удается за 1:50 их пробегать.

✔️ На курсе по SD выбрал проект и описал FR + NFR (отдельно поделюсь изысканиями).

посты

⭐️ Собираем требования -> читать

🔖 Боль при переезде на новое железо осталась в прошлом? -> читать

🔖 Лучшее, чем можно заняться в отпуске* -> читать

🔖 Темная сторона Биг Теха -> читать

#дайджест

@time2code

Хайлайты Highload

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

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

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

Общее впечатление

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

Удалось неформально пообщаться с коллегами из других Биг Техов, узнал как жизнь у них, и по итогу понял, что все большие компании +- живут одинаково, как с точки зрения процессов, так и каких-то бенефитов.

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

5 лайков и выложу топ 10 рекомендаций по работе с БД от сразу двух лекторов из самой большой аудитории. Несмотря на то, что зал на эту презентацию был битком, многие критиковали уровень доклада.

Итог

Достиг ли я поставленных целей? — Еще бы.

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

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

@time2code

Топ 10 рекомендаций по работе с БД с Хайлоада

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

↘️ https://novikov-ai.github.io/ru/posts/database-tips/

Если нет времени читать блог или вчитываться в слайд и делать какие-то выводы, то вот самая суть — фактически готовый рецепт по работе с БД:

1. Ограничивайте пул коннектов, ставьте PgBouncer если нужно.
2. Транзакция = один коннект; держите транзакции короткими.
3. Не держите коннект в простое и не делайте внешние вызовы внутри транзакции.
4. Вынесите HTTP в outbox/после commit.
5. Аналитика и тяжёлые запросы — на реплику или в DWH.
6. Индексы — подумайте перед созданием; composite > набор отдельных.
7. Переписывайте OR/NOT/IS NULL в эквивалент, чтобы сохранить индекс.
8. Планируйте keyset pagination заранее.
9. JSON — удобно, но не для часто фильтруемых полей.
10. Профилируйте, измеряйте, затем применяйте «нетипичные» архитектурные приёмы.

Если знаете другие рецепты по работе с БД, проверенные временем и продом, пожалуйста, делитесь ⤵️

@time2code

Почему я стал писать еще меньше кода?

И нет, AI меня пока не заменил.

2.5 года назад уже было мое ворчание по этому вопросу, и я решил его продолжить.

Не всем может быть очевидно (я из прошлого точно бы не поверил), но синьор-разработчики пишут в разы меньше года, чем мидлы.

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

Но я работаю в продукте и сейчас пишу про него.

Хлеб синьора

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

Бесконечные обсуждения работы нового домена и прочие коммуникации — хлеб старших инженеров в команде.

Про дофамин

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

Код написан, ревью пройдено, продакшн не упал — вы великолепны 🙂

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

Что делать?

Осознать, что с эволюцией в карьере меняются также и задачи.

Применять новые подходы и по-другому оценивать результат своей работы.

И, конечно, научиться получать удовольствие от нового, если это целиком не противоречит вашей конституции.

@time2code

Ноябрь 2025:

ключевые события

✔️ Познакомился с базой по ассемблеру x86/x64, написал простенькую консольную игру (код).

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

✔️ Продолжаю активную работу с менти. Двум человекам уже удалось закрыть запросы, которые были сформированы на менторство 3 и 6 месяцев назад, сейчас формируем следующую цели.

✔️ Провел десятки код-ревью пул-реквестов и написал комментариев больше, чем строк кода.

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

🪫 Случился классический перегруз под конец года: времени, энергии и мотивации перестало хватать, поэтому по курсу по SD просрочил все DL на сдачу проектов и договорился перенестись на следующий поток.

посты

⭐️ Хайлайты Highload -> читать

🔖 Топ 10 рекомендаций по работе с БД с Хайлоада -> читать

🔖 Почему я стал писать еще меньше кода? -> читать

#дайджест

@time2code

🗣️ Самое сложное в разработке

Неочевидно, но самое сложное в любой сфере (программная инженерия не исключение) — это коммуникации.

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

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

. . .

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

Зафиксировали зону ответственности каждого и ожидания.

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

Это был явно не MVP и совсем не то, о чем мы изначально договорились.

Причины могли быть разные: от обыкновенного недопонимания до политической игры, где под видом одной договоренности команда решила закрыть какие-то свои потребности.

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

Потребовалось почти 2 месяца, чтобы найти понимание.

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

Могло ли это произойти раньше?

— Со своей стороны мне сложно ответить, так как не обладаю всем контекстом и ответственный только за технику.

Пусть этот вопрос останется открытым.

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

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

@time2code

Замедлиться

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

Восхищаюсь такими людьми. Как вам удается?

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

Возможно, стоило лучше планировать отпуск или «работать не усерднее, а умнее».

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

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

Это недостаток работы в IT.

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

Поэтому я плавно последние месяцы стараюсь переходить в энергосберегающий режим.

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

@time2code