Продвинутая работа с БД. Нужна ли она вам?

В начале мая задался вопросом: как лучше работать с БД?

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

Опыт

Изучая системы по управлению базами данных, за этот месяц попробовал две: Dbeaver и DataGrip.

Dbeaver выглядит интересно, но оказалось, что в Community Edition версии нет Redis, поэтому с задачей по управлению NoSQL и SQL из бесплатной коробки не справился.

Цена за платную версию начинается от 110$ и доходит до 500$.

А если нужно платить, то можно уже и в сторону решений от JetBrains посмотреть с его DataGrip за 229$.

Лайфхак: в большинстве IDE от JetBrains есть плагин, позволяющий получить все функции по работе с БД, которые предоставляет DataGrip.

Так, если вы пишите на Go, то покупаете Goland за 249$ и получаете все в одном инструменте.

Цена указана за 1 год использования.

Опыт других

Обсудив вопрос с коллегами, все единогласно проголосовали за Goland со встроенным DataGrip, отмечают элементарное удобство.

Из альтернатив еще советовали TablePlus, но я его не стал тестировать, так как все выводы для себя уже сделал.

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

Есть те, кому удобнее работать с простым psql, а также те, кто кроме удобной IDE ничего не принимает.

Выводы

1. Продвинутые инструменты для работы с БД, а именно отдельная IDE нужна тем, кто ежедневно с ними работает (проектирует базу или поддерживает текущую).

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

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

Что в итоге?

Продолжаю использовать CLI для работы с БД и простенький плагин на VS Code (для PG и для официальный Redis for VS Code), но для серьезной работы держу наготове продвинутый тулинг.

@time2code

🆎 Запуск крупного AB

Вчера состоялся долгожданный запуск AB-эксперимента, к которому я готовился последние несколько месяцев, из-за чего даже мой work-life balance пошатнулся 😅

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

Разрабатываемая функциональность вобрала в себя:

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

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

🚀 Но как и при старте ракеты, так и при запуске эксперимента спокойный и штатный старт во многом является залогом успеха.

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

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

Приятное ощущение. Вероятно, ради него и работаю.

@time2code

Май 2025:

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

✔️ Месяц, когда написал очень много кода (тысячи строк), чтобы запуск эксперимента стал возможным.

✔️ Организовал и провел 2 совершенно разных типа тестирования: нагрузочное тестирование, чтобы снять риск отказа БД при высокой нагрузке, и chaos-тестирование.

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

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

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

✔️ Посмотрел как Дефункционализация и CPS (Continuation Passing Style) могут работать вместе, потренировавшись на примерах.

посты

⭐️ Еще одна важная вещь -> читать

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

🔖 Chaos Engineering -> читать

🔖 Продвинутая работа с БД. Нужна ли она вам? -> читать


#дайджест

@time2code

Жизнеспособная архитектура

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

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

Кто-то придерживается чистой архитектуры, кто-то лучшим практикам, а кто-то реализует Big Ball of Mud.

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

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

И это ни хорошо и ни плохо.

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

И это нормально, если система соответствует SLA, а команда работает эффективно.

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

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

Minimal Viable Architecture (MVA)

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

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

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

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

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

Фактически на своем опыте я открыл идеи MVA, которые существуют десятки лет 😅

Интересно будет углубиться и дополнительно рассказать про это. Базово с подходом можно ознакомиться здесь.

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

@time2code

Июнь 2025:

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

✔️ Этому каналу исполнилось 5 лет! 🎈

✔️ Написал 6-ой селф-ревью в компании. Пора уже организовать ультимативный гайд в продолжение поста.

✔️ Завершил курс по работе и поддержке Легаси систем.

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

✔️ Важная для меня веха - пробежал первый трейл: 23.3 км, +900м - за 3 часа.

✔️ Сходил в недельный отпуск - понравилось.

посты

⭐️ Запуск крупного AB -> читать

🔖 Жизнеспособная архитектура -> читать

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

#дайджест

@time2code

Атомарные изменения лучше

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

Что случилось?

На днях опытный разработчик добавлял локализацию для вертикальной библиотеки.

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

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

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

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

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

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

При помощи 2 разработчиков и 2 QA, созданием кастомного деплоя удалось установить проблему: при рефакторинге констант, заодно зарефакторили и ключ конфигурации в одном из виджетов.

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

А что тесты?

Тесты были, но и они были изменены соответствующим образом, чтобы код с багом проходил :)

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

Мораль

Делать как можно более мелкие и локальные изменения в одном ПР-е. Это не всегда возможно, но к этому следует стремиться.

За / против:

+ ощутимо снижается когнитивная нагрузка у ревьюеров, которые смотрят ПР (что внимательнее человек посмотрит 50 измененных строк кода или 1000?);
+ легкий деплой - при небольших изменения вы можете значительно снизить скоуп наблюдаемых метрик при раскатке;
+ автономный откат - чем меньше изменяемых файлов, тем более точно можно откатывать свои изменения без аффекта на то, что работает штатно;

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

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

@time2code

Документация лжет вам? Можно ли сохранить свежесть? 🥖

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

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

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

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

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

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

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

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

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

Совет:

- Если у вас есть важная инициатива, реализацию которой вы планируете, опираясь исключительно на документацию или что-то еще, то, как и в журналистике, лучше заручиться несколькими источниками информации. Не всегда можно сразу проверить работу системы, поэтому прием: "прочитал в документации, что X=Y, уточните, пожалуйста, так ли это?" - отлично работает в большинстве ситуаций.

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

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

@time2code

Сколько нужно людей, чтобы поменять лампочку в Биг Техе?

It depends ...

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

Гротеск? -Отчасти.

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

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

Кейс из практики

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

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

Напишите в комментариях и сверьтесь с ответом под спойлером.
.
.
.
.
.
.
.
.
.
.
-> 30 дней

За которые:

1. PM определит концепцию сообщения, правильный тайминг и согласует с поддержкой изменения регламентов.
2. Аналитик выгрузит список пользователей, на которых нужно сделать рассылку.
3. Редактор напишет текст, который пойдет в рассылку.
4. Юрист вычитает текст редактора с точки зрения рисков.
5. Разработчик проведет ресеч по настройке шаблонов для рассылки и настроит.
6. CRM-менеджер вычитает настроенный шаблон письма с текстом и необходимыми параметрами.
7. Разработчик сделает скрипт в сервисе, чтобы отправка стала возможной, так как существует огромная очередь на отправку готовых шаблонов, если это делается силами команды CRM.
8. QA проконтролирует по трейсам, что все хорошо и пользователям сообщение доставили.
9. Тимлид всех скоординирует и проследит, чтобы задача была сделана в срок.

Стартап же справится с этой задачей менее чем за час (фаундер самостоятельно может всех точечно уведомить).

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

И это нормально. Важно это учитывать.

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

Серьезный и системный подход к решению любой проблемы - истинное отражение инженерной культуры.

@time2code

Июль 2025:

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

✔️ Успешно прошел 6-ой перф-ревью в компании. За последние 6 месяцев много перформил и устал - сейчас это ощущается. Но получил отличный результат и фидбек от коллег. Отдельно планирую порефлексировать на этот счет и подробнее рассказать про прошедшее ревью.

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

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

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

✔️ Не могу не отметить очередной забег (на этот раз айтишный) на 10 км по 30-градусной жаре. Почти уложился в 50'... Подобные события серьезно помогают восстанавливаться после работы. Ментальная усталость замещается физической.

посты

⭐️ Сколько нужно людей, чтобы поменять лампочку в Биг Техе -> читать

🔖 Документация лжет вам. Можно ли сохранить свежесть? -> читать

🔖 Атомарные изменения лучше -> читать

#дайджест

@time2code

⏳ Сколько времени нужно, чтобы стать Senior? — Соединяю точки.

В декабре 2022 я предположил, что мне потребуется около трех лет, чтобы дорасти до 5-го грейда (senior по меркам Авито).

Прошло 2.5 года и вот я здесь...

Для меня это очень крупная веха. Возможно, самая крупная на этом карьерном треке.

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

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

Знаменитая цитата очередной раз обрела смысл:

You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

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

Был ли я уверен, что смогу ей соответствовать? — Отнюдь. Слишком много переменных, но очень хотелось.

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

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

Что дальше?

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

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

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

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

Также важно пересмотреть долгосрочные планы на 2-3 года и, конечно, навалиться на последние 4 месяца 2025-го, чтобы постараться закрыть поставленные цели.

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

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

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

@time2code

Цель, которая работает на вас: умная практика для инженера и менеджера

В качестве ментора провожу регулярные встречи с менти.

Работаем с запросом: "составить структурированный индивидуальный план развития (ИПР) и получить понимание о том, как развивать сильные стороны".

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

Если декомпозировать запрос, то на выходе получаем два фокуса:

1. Составить ИПР
2. Получить новое знание

И, если с ИПР относительно все понятно, так как нет ничего более конкретного чем наличие материального артефакта или его отсутствие (за исключением: какой ИПР нам нужен, для чего и когда), то с получением знаний всегда есть сложность, так как это очень абстрактная история.

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

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

Наводящие вопросы:

- Является ли составленный ИПР конечной точкой при работе с ментором или это лишь одна из составляющей чего-то большего?
- С какой целью мы хотим получить новые знания или развить сильные стороны?

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

Вероятно, самый популярный фреймворк для этого - SMART.

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

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

Например, переформулируем составление ИПР:

Конкретная (Specific): Разработать индивидуальный план развития (ИПР) для собственного профессионального роста в текущей должности.

Измеримая (Measurable): ИПР должен включать как минимум 3 конкретные цели развития (например, "пройти курс X", "освоить навык Y до уровня Z", "реализовать проект А"), 2 ключевых показателя успеха (KPI) для оценки прогресса по каждой цели и список необходимых ресурсов/действий.

Достижимая (Achievable): Цели в ИПР должны быть реалистичными с учетом текущей нагрузки и доступных ресурсов (время, бюджет на обучение).

Актуальная (Relevant): Разработка ИПР напрямую связана с повышением моей эффективности в текущей роли и подготовкой к будущим задачам/продвижению.

Ограниченная по времени (Time-bound): Завершить разработку и согласовать ИПР с моим руководителем к, например, 28 августа 2025 года.

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

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

@time2code

Вы знаете, где живет ваш код?

Мы живем в мире высоких технологий и скоростного интернета.

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

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

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

Немало детей разбирают (или просто ломают) свои игрушки с этой же целью.

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

Сюда отлично ляжет шутка: “Backend / Frontend”...

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

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

Идея

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

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

Стоит ли говорить, что порядка ста коллег тоже захотели принять участие? Это показатель неудовлетворенного спроса.

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

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

Выводы

— Инженерам важно видеть всю "внутрянку" системы, с которой они работают.

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

Обращение к менеджерам (знаю, что меня читают): давайте возможность своим инженерам время от времени погружаться в такие истории — это идет на пользу.

Что еще быстрый поиск предлагает почитать по теме:

- Авито Тех в 2022-м рассказал для чего нужны датацентры и где у них хранится железо.

- 2013 год, видимо, задавал тренд на экскурсии по DC, поэтому нашел сразу от двух компаний: VK и Yandex (с реальными фотографиями, несмотря на режимность объектов).

А вы были в датацентре? Было бы интересно посмотреть, где работает ваш код?

@time2code

Ваш главный инструмент в отладке

Есть множество разных техник как отлаживать свой код. Я всегда был сторонником двух подходов: метод пристального взгляда (МПВ) и использование дебагера.

МПВ

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

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

Дебагер

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

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

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

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

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

Умные точки останова

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

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

Debug Console

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

На этой вкладке можно производить элементарные операции с переменными:

- вывести состояние в консоль;
- произвести преобразование типа;
- получить значение по ключу из словаря и пр.

Значение переменой получается через простой ввод, например:

x

При этом можно получать доступ к приватным полям структуры:

x.private

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

Например, если обращаемся к интерфейсу, у которого есть метод получения имени:

call in.Name()

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

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

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

@time2code

Что выведет программа?

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

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

Итак, задача:

package main

import "fmt"

func main() {
  fmt.Println(len(IntArray()))
}

func IntArray() []int64 {
  return []int64{
    2302481, // one
    2302482, // two
    2302483: // three
    2302484, // four
  }
}

Попробуйте дать 2 ответа: первый, который придет сразу в голову (проголосуйте в опросе ниже) и второй, который будет обдуман и обоснован (можно прямо в реплаи).

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

@time2code

Август 2025:

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

✔️ Закрыл P0 ОКР на текущий год!

✔️ Решил, что пора делиться опытом, поэтому продолжаю менторить коллегу из другой команды, а также запланировал принять участие во внутренней программе развития инженеров в качестве ментора (год назад принимал участие в программе, как участник).

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

✔️ Принял участие в двух забегах: на 10K и 21K. Уложился в 50 мин и 2 часа соответственно.

посты

⭐️ Сколько времени нужно, чтобы стать Senior? — Соединяю точки -> читать

🔖 Цель, которая работает на вас: умная практика для инженера и менеджера -> читать

🔖 Вы знаете, где живет ваш код? -> читать

🔖 Ваш главный инструмент в отладке -> читать

#дайджест

@time2code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@time2code