Неделя 121. Пересборка на ходу

82 коммита. Три репозитория. Двадцать семь молчат.

24 ноября 2025 года. Три недели назад я принял одно из самых тяжёлых решений за всё время существования Botseller: закрыть направление интеграций и перестроить продукт в платформу. Решение, от которого зависело вообще всё. Не «давайте попробуем». Не «запустим пилот». А жёсткое: мы больше не делаем то, что делали. Мы строим другое.

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

Развилка: накапливать долг или строить фундамент

Если вы читаете эту серию в обратном порядке, вы уже видели результат: неделю 122 с тремя кризисами одновременно, неделю 124 с утечками данных, неделю 125 с «Великим подключением». Всё это стало возможным только потому, что на неделе 121 мы перестроили фундамент.

К ноябрю 2025-го каждый сервис в Botseller напрямую обращался к базе данных. Нужен список клиентов? Сервис сам строит SQL-запрос, сам подключается, сам разбирает результат. Это работало, когда сервисов было мало. Но если строишь платформу, десятки компонентов начинают лезть в одну и ту же базу, каждый по-своему. Разные форматы запросов, разные допущения о структуре таблиц, разные версии работы с одной и той же сущностью.

Платформу нельзя строить на таком фундаменте. Любое изменение в базе ломает всех. А мы планировали менять базу постоянно.

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

Мы выбрали второй.

Архитектурный сдвиг: внедрение DataService

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

Реализация оказалась совсем не простой.

50 коммитов в одном ядре

Понедельник, 24 ноября. Двадцать коммитов. Все в бэкенде. Мы начали с аудита: каждый файл, который обращался к базе напрямую. 71 файл. Каждый нужно было переписать: убрать SQL-запрос, заменить на HTTP-вызов, обработать ошибки, убедиться, что результат остаётся в том же формате.

Я помню этот понедельник. Ты открываешь файл, видишь пять строчек SQL, которые работают, и начинаешь заменять их на десять строчек HTTP-вызова, обработки ошибок и валидации ответа. Каждый раз кажется, что усложняешь. Каждый раз нужно напоминать себе: ты не усложняешь, ты разделяешь ответственность.

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

Параллельно мы добавили межсервисную авторизацию. Раньше, когда всё работало напрямую с базой, она была не нужна. Теперь, когда сервисы общаются по HTTP, каждый запрос должен доказать: «я имею право запрашивать эти данные». JWT-токены с ограниченным сроком действия. Ещё один слой, без которого платформа не может быть платформой.

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

Один коммит. 447 юнит-тестов.

Во вторник произошло то, чем я горжусь до сих пор.

Один коммит. 447 юнит-тестов. Платежи, CRM, клиенты, лиды, переменные, дашборды, аутентификация, баланс, отправка файлов. Всё, что было переписано, получило свой набор проверок.

Тесты писались параллельно с миграцией. Не после, а одновременно. Переписал файл, написал тесты, убедился, что работает. Следующий файл. Коммитились одной пачкой, когда покрытие вышло на приемлемый уровень.

Я часто вижу, как команды откладывают тесты «на потом». Напишем фичу, потом покроем. Потом наступает через месяц, когда никто уже не помнит нюансов. Или не наступает вообще.

На неделе 121 у нас не было роскоши «потом». Мы перекладывали рельсы под движущимся поездом. Клиенты продолжали работать. Боты отвечали. Платежи проходили. Любая ошибка в миграции немедленно становилась багом в продакшене.

447 проверок были не перфекционизмом, а выживанием.

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

Параллельные рельсы: две недели в одну

Пока бэкенд перестраивался, фронтенд строил новый продукт.

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

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

Вторник: каркас. Компоненты этапов, переключатели, динамические заголовки. Перетаскиваемый badge статуса.

Среда: визуализатор с drag-and-drop. Этапы стали осязаемыми: взял, переставил, прикрепил файл из библиотеки.

Суббота: интеграция с CRM. Этапы воронки синхронизируются с пайплайнами внешних CRM-систем. Адаптер данных. Реструктуризация навигации.

Воскресенье: бэкенд закрыл API. Четыре коммита: реализация этапов, управление дожимами, синхронизация с CRM.

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

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

Когда интерфейс меняет восприятие

Внутри конструктора воронки появилась деталь, которая мне нравится до сих пор.

Дожимы (follow-ups) в Botseller работают по цепочке: клиент написал боту, но не завершил целевое действие. Через час система отправляет первое сообщение. Через два часа второе. Через день третье, с другим тоном. Это увеличивает конверсию в разы. Но настраивать цепочку дожимов раньше нужно было через список текстовых полей. Заполняешь 15 полей и надеешься, что всё правильно.

Теперь каждый дожим стал визуальным элементом с радиальным меню. Перетаскивание для изменения порядка. Визуализация задержек между шагами. Временное окно (не тревожить клиента ночью). Drag-and-drop файлов прямо в дожим: прайс-лист, каталог, презентация.

Разница между «списком полей» и «визуальным конструктором» кажется косметической. Но я видел, как пользователи реагируют. Список полей вызывает вопрос «а что сюда писать?». Визуальный конструктор вызывает «а, понятно». Интерфейс, который не требует инструкции, побеждает тот, у которого инструкция идеальная.

Тишина двадцати семи

27 репозиториев. Ноль коммитов. За всю неделю.

Ни CRM. Ни обработка сообщений. Ни вебхуки. Ни мониторинг. Ни документация. Ни один побочный проект. Полная тишина.

Это не случайность. Это дисциплина.

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

Контраст с соседними неделями показателен. Неделя 125: 314 коммитов, 13 репозиториев. Неделя 124: 190 коммитов, 6 репозиториев. Неделя 121: 82 коммита, 3 репозитория. Не потому что работали меньше. Потому что работали глубже.

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

Обслуживание пассажиров во время смены рельсов

При этом жизнь не остановилась. Четыре клиентские задачи прошли сквозь миграцию.

Персональная интеграция с платёжной системой. Выгрузка каталога по API. Расшифровка цен. Корректировка работы с внешней CRM.

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

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

Урок недели: три правила пересборки на ходу

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

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

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

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

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

Что дальше

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

Но это уже следующая история. А пока: три недели после самого тяжёлого решения, 82 коммита, и фундамент, который выдержит всё, что придёт дальше.

FAQ

Что такое DataService и зачем на него мигрировать?

DataService в Botseller выполняет роль единого промежуточного слоя между сервисами и базой данных. Вместо прямых SQL-запросов из каждого сервиса все обращения идут через стандартный HTTP-интерфейс. Это упрощает контроль доступа, позволяет менять структуру базы без переписывания каждого сервиса и обеспечивает единый формат данных для всех потребителей.

Почему миграция потребовала 50 коммитов за одну неделю?

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

Зачем писать 447 тестов параллельно с миграцией?

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

Как фронтенд может опережать бэкенд на четыре дня?

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

Что такое дожимы и зачем им визуальный конструктор?

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

Почему 27 из 30 репозиториев не имели ни одного коммита?

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