редакции
Почему растущий интернет-магазин становится сложнее обновлять — и почему переписать всё с нуля обычно не выход
Нет десятков интеграций, написанных несколько лет назад. Нет модулей, работу которых нельзя внезапно изменить. Нет кастомных бизнес-процессов, к которым привыкли сотрудники. Нет миллионов товаров, которые должны пережить обновление без потерь.
По мере роста бизнеса ситуация меняется.
Функциональности становится больше, появляются интеграции с оплатой, доставкой, учетом и другими системами. Компания дорабатывает платформу под собственные процессы. И в какой-то момент задача «добавить новую возможность» превращается в другую: как изменить работающую систему и не сломать то, на чем уже зарабатывает бизнес?
Мы обсудили эту проблему с Иваном, менеджером продукта CS-Cart, который больше десяти лет наблюдает за развитием eCommerce-проектов и самой платформы.
Новую функцию иногда сделать проще, чем изменить старую
На первый взгляд кажется наоборот.
Если механизм уже существует, его остается немного доработать. Если его нет — придется создавать с нуля.
На практике у существующей функциональности появляется то, чего нет у новой: пользователи и данные, которые уже от нее зависят.
«Когда мы занимаемся уже существующими функциями, добавляется дополнительный пласт работ. Нужно предусмотреть миграцию, то есть переход со старого механизма на новый. Чтобы от пользователя после обновления функциональности не потребовалось каких-то дополнительных действий», — объясняет Иван.
Поэтому изменение затрагивает не только разработку.
Нужно понять:
- что произойдет с существующими данными;
- продолжат ли работать старые настройки;
- не изменится ли привычная бизнес-логика;
- что произойдет с модулями и кастомными доработками;
- смогут ли внешние системы продолжить обмениваться данными;
- потребуется ли пользователю что-то перенастраивать после обновления.
Чем дольше работает интернет-магазин, тем больше таких зависимостей может накопиться.
Обратная совместимость — невидимая часть стоимости развития
Пользователь обычно видит результат обновления: новый переключатель, настройку или сценарий работы.
Но значительная часть работы может быть связана не с самой новой возможностью, а с сохранением старых.
В CS-Cart, например, при развитии продукта стараются сохранять обратную совместимость, чтобы после очередной версии партнерам не приходилось полностью переделывать модули и темы, а владельцам магазинов — перестраивать существующие процессы.
Полностью исключить несовместимые изменения невозможно.
Если такое изменение все-таки необходимо, появляется дополнительный этап: разработчиков нужно предупредить заранее, изменения описать в документации, а существующим решениям дать время на адаптацию.
Для бизнеса из этого следует важный вывод.
Стоимость функции определяется не только тем, насколько сложно ее написать. Важно еще и то, сколько существующих процессов она затрагивает.
Именно поэтому две визуально похожие доработки могут отличаться по сложности в разы.
Чем больше магазин, тем важнее думать не о функциях, а о связях между ними
Эта проблема особенно заметна у проектов, которые значительно выросли относительно первоначальной версии.
За годы вокруг eCommerce-платформы может сформироваться целая инфраструктура:
ERP и учет, CRM, платежные системы, службы доставки, склад, собственные модули, обмен данными с партнерами, мобильные приложения.
При этом сами сценарии использования платформы тоже меняются.
За годы работы CS-Cart команда сталкивалась и с проектами с миллионами товаров, и с гораздо менее очевидными сценариями. Например, на базе eCommerce-платформы создавали систему для размещения контента, а тарифные планы маркетплейса использовали как механизм ее монетизации.
То есть платформа, которая первоначально решала один набор задач, постепенно может стать фундаментом совсем другой системы.
И тогда изменение одного механизма потенциально затрагивает то, что разработчики платформы изначально даже не могли предусмотреть.
Почему нельзя просто переписать всё с нуля
У больших программных продуктов периодически возникает соблазн решить проблему радикально.
Старый механизм сложный. В нем накопились ограничения. Разработчики уже знают, как можно было бы сделать лучше.
Почему бы не выбросить его и не написать новый?
«При работе над большим проектом иногда возникает соблазн какую-то часть или проект целиком переделать с нуля. Это проще, потому что не нужно иметь дело со всеми предыдущими наработками и понятны имеющиеся в них проблемы. Но не всегда подход „переделать иначе“ оказывается быстрее и правильнее», — говорит Иван.
Причина та же: программный продукт существует не сам по себе.
Вокруг старого механизма уже могли появиться процессы, интеграции и привычки пользователей. Переписывая его, команда одновременно получает более чистую архитектуру и создает новую проблему — необходимость перенести на нее существующий бизнес.
Поэтому вопрос обычно должен звучать не «можем ли мы сделать лучше?», а: даст ли изменение достаточно новой ценности, чтобы оправдать стоимость перехода?
Иногда правильнее улучшать систему по частям
Из этого не следует, что зрелую eCommerce-платформу нельзя существенно менять.
Можно.
Но большие изменения необязательно должны происходить одним релизом.
Если часть проблемы можно решить независимо, не затронув существующие сценарии, ее можно выпустить раньше. Более фундаментальную переработку — оставить до момента, когда накопится достаточно связанных задач и обратной связи.
Так развитие превращается не в последовательность «старое → выбросили → новое», а в постепенную перестройку работающей системы.
Для eCommerce это особенно важно: интернет-магазин нельзя регулярно останавливать ради архитектурной чистоты. Пока команда меняет платформу, бизнес продолжает принимать заказы.
Интеграции делают эту задачу еще сложнее
Есть и еще один слой — внешние системы.
Даже простая интеграция зависит не только от разработчиков магазина или платформы. Нужны API, документация, тестовая среда и предсказуемое поведение второй стороны.
Поэтому зрелость eCommerce-системы определяется не количеством логотипов интеграций на странице продукта.
Гораздо важнее, насколько легко подключить новый сервис, заменить старый и продолжить развивать систему, когда требования бизнеса изменятся.
По этой же причине фундамент платформы со временем становится важнее отдельных функций: доступ к коду, API и возможность расширения позволяют бизнесу добавлять сценарии, которые невозможно было предусмотреть при первоначальной разработке.
Что стоит учитывать бизнесу при выборе платформы
При запуске магазина платформы часто сравнивают по текущему набору возможностей.
Есть ли нужная платежная система? Можно ли настроить промоакцию? Поддерживается ли необходимый способ доставки?
Для старта это разумно.
Но у растущего бизнеса появляется второй набор вопросов:
Что произойдет через несколько лет, когда стандартных возможностей станет недостаточно?
Можно ли будет подключить собственную систему? Насколько глубоко разрешено менять бизнес-логику? Что произойдет с кастомизациями после обновления? Есть ли механизм миграции данных? Насколько платформа зависит от конкретных интеграций?
И наконец — можно ли развивать систему постепенно или очередной этап роста потребует полной миграции?
Именно здесь различие между «сайтом, который работает сегодня» и технологической основой для eCommerce становится особенно заметным.
Вместо вывода
У растущего интернет-магазина технический долг появляется не обязательно потому, что кто-то когда-то написал плохой код.
Часть сложности возникает естественно.
Бизнес растет. Появляются новые процессы. Подключаются сервисы. Создаются кастомизации. Меняется законодательство. То, что пять лет назад было отдельной функцией, сегодня может оказаться частью критически важной цепочки.
Поэтому развитие зрелой eCommerce-системы — это не постоянное добавление функций.
Это поиск баланса между тремя вещами: новыми возможностями, стабильностью существующего бизнеса и способностью платформы изменяться дальше.
И чем дольше интернет-магазин работает, тем важнее становится третья.