Первые признаки необходимости переписывания сайта
Ниже приведу несколько примеров из жизни, которые явно указывают на, что сайт находится в зоне риска и требует переписывания с нуля.
В одном месте починили — в двух других отвалилось
При оформлении заказа некорректно применялся промокод «ВЕСНА2025». Завели баг, разработчик нашел проблему, пофиксил, выкатил фикс — промокод заработал, все довольны.
Через час прилетает сообщение из бухгалтерии: в новых заказах несоответствие между ценой на товар и оплаченной суммой. Параллельно в CRM — неверно рассчиталась скидка.
Идем к разработчику — он обнаруживает странный «костыль» в логике, влияющий на работу промокодов, и убирает его. Промокоды «восстановлены», но вместе с этим ломается расчет стоимости с учетом скидок — потому что вся логика «держалась» на этом самом костыле.
В итоге: нужно фиксить 2 новых бага, и не факт, что в следующей итерации не будет еще больше ошибок.
Неоправданно дорогие доработки сайта
«Добавьте пожалуйста в поп‑апе авторизации капчу» — просит заказчик, так как на сайте большинство юзеров — боты. Вместо ожидаемых 2–3 часов трудоресурсов, команда тратит целый день на доработку.
Причина: на сайте много разных мест, где можно авторизоваться, и в каждом месте свой экземпляр поп‑апа и свой метод авторизации. Рефакторить — дорого, поэтому добавляем капчу в каждый из поп‑апов и в каждый из методов авторизации, допуская многократный перерасход трудоресурсов.
Отказ от проекта при поиске новых подрядчиков
Текущая команда постоянно сталкивается с проблемами, описанными выше, — а что, если проблема в команде? Решение: сменить команду, проверить гипотезу!
Нашли нового подрядчика, который, как и следует любому добропорядочному исполнителю, перед стартом работ запрашивает проведение аудита программного кода. По результатам аудита — приговор: «за проект в текущем виде не возьмемся». Причина в нескончаемом количестве «костылей» и нечитаемом коде, в который лезть «себе дороже». Невозможно даже оценить трудозатраты на любую доработку сайта, а, следовательно, и брать ответственность за качество и стабильность работы проекта после вмешательства. Как согласовывать работы с неизвестной стоимостью? Мало кто согласится на такую авантюру — и правильно сделает!
Медленная работа сайта и высокая серверная нагрузка при небольшой посещаемости
Вроде и реклама на паузе, и сезон «низкий», а все равно сайт подтормаживает, при этом мониторинг показывает ощутимую нагрузку на процессор. Как только включается реклама либо возрастает органический трафик — сайт виснет и «падает».
Из предлагаемых решений — повысить и так уже завышенную процессорную мощность, либо надстраивать систему дополнительным элементом кеширования страниц (отдельный микросервис). При этом команда разработки сообщает, что оптимизировать сам сайт является нецелесообразным решением по соотношению стоимость/профит. На лицо явный признак «тупиковой» ситуации с быстродействием сайта, которую можно исправить «в моменте» только дополнительными внешними средствами, что только нивелирует симптомы заболевания, но никак не решит истинные причины проблемы.
Почему и как пришли к этой проблеме?
Жесткая экономия на старте проекта
Запуск нового проекта, особенно стартапа, особенно с версии MVP, часто планируется при минимальном бюджете, чтобы не терять много денег в случае если проект «не взлетит». Минимизация бюджета часто достигается в том числе и поиском самого дешевого исполнителя.
В результате проект разрабатывают специалисты уровня Junior, в лучшем случае Middle. На выходе мы получаем кое‑как работающее ПО, которое невозможно развивать и дорабатывать, так как программный код написан настолько неграмотно, что исправлять его в разы дольше, чем написать заново.
Вышедший из-под контроля техдолг
Предположим, что все‑таки нашли более профессиональную команду, чем описанную мной в пункте выше, и она уже включает в себя архитектора и разработчика уровня Senior. Но в ходе разработки проекта, для ускорения запуска или в условиях неопределенности, постоянно копится технический долг. От итерации к итерации, он начинает накапливаться во всех частях проекта. Хорошо, если он фиксируется в беклоге проекта, либо в документации — так его можно не потерять.
Плохо, если он фиксируется только в голове ведущего разработчика, или не фиксируется вовсе. Именно в последнем случае рано или поздно техдолг выходит из‑под контроля. А если еще и сменить команду разработки в какой‑то момент, и не провести перед стартом полный аудит всего кода (от чего иногда отказываются по причинам экономии бюджета) — техдолг просто теряется.
В итоге получаем крайне нестабильный проект, при любой модификации которого вылезают непонятные баги. И работать с таким проектом дальше — дороже на дистанции, чем сделать «с чистого листа».
Устаревшая технологическая база
Первая версия сайта иногда разрабатывается либо на «самописных», либо на непопулярных фреймворках/CMS, но с которыми привычнее всего работать изначальной команде разработчиков.
Проблема такого решения — в какой‑то момент данные фреймворки перестают поддерживаться, вендор перестает выпускать обновления ядра под новые версии языков программирования, на которых разработан проект.
Помимо этого случая, бывают ситуации, при которых разработчики начинают бесконтрольную модификацию самого ядра системы, вместо разработки кастомных модулей, использующих инструментарий ядра. В результате ядро становится не обновляемым.
И в том и в другом случае мы лишаемся поддержки вендора по обновлению программного кода сайта, которые он периодически выпускает. Новые версии программных пакетов, новые версии языков программирования, новые версии операционных систем — именно для поддержки актуальных и современных программных средств вендоры выпускают обновления своих фреймворков, на которых построены наши проекты.
Обновления выпускаются по различным причинам: найдена уязвимость, которую необходимо «закрыть»; расширяется функционал, доступный разработчикам; решаются проблемы и баги предыдущих версий; внедряется поддержка новых hardware‑решений; и прочее..
Так вот, лишаясь возможности штатной установки подобных обновлений, все вышеперечисленные улучшения необходимо на сайте производить программистам самостоятельно, фактически повторяя ту же самую работу, которую уже произвели разработчики вендоров. И подобная работа может в какой‑то момент стать настолько объемной, что ее проведение признается нецелесообразной. Единственный возможный вариант решения проблемы — опять же, «переписать» все заново.
С чего начать и какие решения возможны
Аудит как нулевой этап
Перед началом разработки обязательно нужно понимать, какой функционал предстоит «повторить» — должна быть документация, описывающая всю логику работы вашего сайта.
Помимо логических блок‑схем, описывающих пользовательские сценарии, обязательно должны быть описаны все интеграции сайта с внешними системами. Фактически, должно быть восстановлено полное и подробное ТЗ на вашу разработку. Не стоит рассчитывать на то, что программисты смогут постоянно «подглядывать» в старый код и копировать его части в новый проект — при таком подходе будут «скопированы» и все проблемы вместе с техдолгом, которые были в старой версии.
Другими словами, старый код нужен только для того, чтобы провести аудит, реверс‑инжениринг и разработать полноценную документацию для создания нового сайта. После старта работ — про старый код забываем, он содержит в себе проблемы, которые не должны переехать в свежую и «чистую» версию.
Frontend и backend как 2 отдельных проекта
Современные программные решения позволяют разделить сайт на две основные части — Frontend и Backend. Обе части являются самостоятельными проектами, которые взаимодействуют между собой по API.
Команды разработки при этом также разделены и условно независимы друг от друга: выпускать обновления можно как в рамках общих релизов, так и в виде отдельных хотфиксов от одной из команд.
Как можно это использовать при переработке сайта с нуля? Появляется возможность разделить всю работу на два последовательных этапа: отдельно обновление фронтенда и отдельно бекенда. Это позволит распределить трудозатраты и бюджет данной истории по времени. Другими словами, вы тратите не полный бюджет, а только половину, при этом закрываете наиболее важные проблемы в той части (фронт или бек), где они превалируют.
Какие полезные задачи можно решить вместе с переписыванием сайта?
Редизайн
Брать старые макеты за основу и выпускать новую версию сайта со старым визуалом — звучит странно. При разработке нового фронтенда логичнее брать за основу и новый дизайн, или хотя бы обновленный, ведь экономии ни на верстке ни на программировании при работе со старым дизайном не будет! Новый фронтенд и новый дизайн — обязательно совмещайте эти две истории!
Избавление от старых болей
Если в логике или бизнес‑процессах вашего старого сайта изначально были архитектурные недостатки — отличный повод их переработать и оставить в прошлом. У вас появляется возможность исправить ошибки старой версии, и спроектировать заново «криво» работающий ранее функционал.
Переезд на более качественную инфраструктуру
Если вас постоянно преследовали низкоуровневые технические проблемы с вашими серверами, либо хостер предоставлял некачественные услуги или неполноценный функицонал управления, приурочьте запуск нового проекта к решению технических проблем с серверами или хостингом. Отдельно эта история будет стоить дороже, нежели ее реализация в рамках разработки и запуска нового сайта.
Ограничения и предостережения
Интеграции
Минимизируйте риск проблем при запуске нового проекта — старайтесь переиспользовать уже проверенные и отлаженные интеграции на старте. Если вы хотите глобально обновить систему, перейти со старых интеграций на другие решения — делайте это на следующих этапах, ведь каждая новая интеграция тянет за собой периоды отладки, где вы будете сталкиваться с «подводными камнями» и адаптировать под них вашу систему.
Запускайтесь на существующих интеграциях, и уже после запуска переходите на новые (в случае необходимости). К тому же, на этапе перехода от старого сайта к новому, будет накладно одновременно поддерживать и старые интеграции и новые.
Пользовательский функционал
Подобно интеграциям, чем больше нового пользовательского функционала вы планируется на запуск (по сравнению с существующим), тем выше риск отсрочки запуска.
Каждая новая пользовательская история требует полноценного цикла жизни: аналитика, задание, оценка рисков и планирование, реализация, тестирование и отладка. Если на любом из этапов упало качество, вы можете «вывалиться» из плановых сроков запусков нового проекта.
Разумеется, это не означает, что новых фич не должно быть вообще. Наоборот, будет здорово, если они будут. Ключевое здесь — соблюсти баланс своих возможностей и своих желаний. А то, на что ресурсов может не хватить на первом этапе, лучше отложить на последующие этапы развития.
Как безболезненно перейти со старой версии на новую, если сайт постоянно используется
Если мы говорим про «переписывание» сайта, это означает что уже есть сайт, работу которого нельзя прерывать. Также нужно понимать, что ввод в эксплуатацию нового решения требует этапности, так как запускать на широкую аудиторию свежеиспеченный проект означает сразу огрести огромную кучу жалоб и обращений с проблемами от целевой аудитории.
На любом новом проекте могут быть баги и недоработки, которые не всегда возможно выявить на этапе тестирования и отладки. Ниже поделюсь опытом нашей компании DDPlanet в организации понятной этапности перехода от старой версии к новой, которая позволит не просто снизить поток обращений по недостаткам и ошибкам, но и управлять интенсивностью этого потока, контролируя загруженность своей команды разработчиков.
1 этап. Ссылка на новый сайт
На сайте в малозаметном месте размещается ссылка перехода на новый сайт. Она может быть как в шапке, так и в подвале. Те, кто ее увидит и заинтересуется, будут переходить на новую версию сайта и «пробовать ее на вкус». Посетитель осознанно делает этот шаг, и интуитивно готов к каким‑то небольшим багам, с которыми может столкнуться, и сообщить вам о них без большого негатива. Поток посетителей вы можете уменьшать, показывая не всем данную ссылку, а только, например, при каждом втором или десятом открытии главной страницы.
Заметка
Если пользователь уже увидел ссылку на новый сайт, сохраняйте в куки это событие и всегда отображайте ее для него в последующем. Пропавшая ссылка наведет на подозрения!
2 этап. Модальное окно-приглашение на новый сайт
Когда вы обработали первую волну обращений пользователей по ошибкам на сайте, увеличивайте поток новых клиентов на новый сайт — зовите их туда более заметно, с помощью модального окна‑приглашения! Опять же, если обнаружите критический недостаток, либо количество обращений по багам превысит производительность вашей команды, снижайте частоту отображения модального окна‑приглашения, либо возвращайтесь на первый этап.
Заметка
Не забудьте учесть: если окно закрыли (отказались), показывать его в ближайшее время снова не стоит!
3 этап. Принудительный редирект на новый сайт
Вы готовы к значительному притоку трафика на новый сайт? Перенаправляйте пользователя принудительно. Процент аудитории также регулируйте в реальном времени. Но учтите: если юзера перекинуло на новую версию без его согласия, он будет оценивать ее по всей строгости своего восприятия. Каждый баг уже серьезно будет сказываться на впечатлении о новом программном продукте.
4 этап. Публикация нового сайта на основном домене
Наступил момент, когда вы перенаправляете 100% аудитории на новую версию уже в течение продолжительного времени (например, 2 недели). Прилетающие баги являются минорными и незначительными по охвату аудитории. Это значит, что вы готовы к запуску нового сайта на основном домене!
Делаем рокировку: старый сайт переносим на дополнительный домен (в качестве «горячего резерва»), новый — на основной. Принимайте поздравления, вы вышли в полноценную «промышленную эксплуатацию»!
5 Этап. Отключение старой версии сайта
Прошел уже месяц (или два) с момента переключения новой версии сайта на основной домен, не было ни одного «отката» до предыдущего этапа, работа новой версии стабильна? Уже можно «тушить» сервер со старым сайтом, удалять dns‑запись на старую версию и убирать ссылку с нового сайта на старый. Еще через пару месяцев можно расформировать сервер. Снепшот машины, дамп БД и репозиторий — в музей архив проекта!
Технические детали и SEO
Домены
В течение вышеописанного «переходного периода» вам необходимо обеспечить параллельную работу двух сайтов. Удобнее всего это сделать, организовав дополнительный домен, например:
Этапы 1–3: старый сайт — www.(ваш домен).ru, новый сайт — new.(ваш домен).ru
Этап 4: старый сайт — old.(ваш домен).ru, новый сайт — www.(ваш домен).ru
Последняя версия использования
Запоминайте (храните в куке), на какой версии сайта пользователь был последний раз, на эту версию и нужно делать редирект при последующих посещениях.
Синхронизация баз данных
Если пользователи и/или заказы и/или любые другие данные храняться независимо друг от друга в БД сайтов (а не во внешних сервисах), необходимо обеспечить синхронизацию данных между двумя сайтами. Решение зависит от конкретной ситуации: например, если структура БД идентична, можно настроить двустороннюю репликацию; если структуры БД отличаются, возможен вариант разработки программных триггеров для событий создания/редактирования/удаления таких данных в двух версиях сайта.
С контентом проще: его дешевле наполнять и модифицировать вручную на двух версиях параллельно.
Заметка
Ситуация значительно упростится, если вышеописанные данные хранятся в самостоятельных сервисах интеграции, а не в БД сайта.
Интеграции
Если в ваших интеграциях есть сервисы, которые обращаются к сайту самостоятельно по API, решения также могут быть разными. Например:
Организовать ретрансляцию данных с одного сайта на другой (как описано в предыдущем разделе статьи);
Организовать программную ретрансляцию запроса на стороне изначальной точки входа — пересылать его на второй сайт.
Организовать дополнительную точку входа в качестве ретранслятора запросов, который будет отправлять внешний запрос на обе версии сайта параллельно;
Заметка
Для определенного типа данных из всех решений может работать только одно. Если данные будут «ходить» по нескольким веткам сразу, данные начнут дублироваться или уходить в бесконечный цикл.
SEO
Поисковые роботы по конечно же не должны видеть обе версии сайта одновременно. До момента включения нового сайта на основном домене, закройте его полностью от индексации простыми инструкциями в файле robots.txt.
После публикации новой версии на основном домене, аналогичным образом закрывайте старую версию от роботов. Действие простое, но если его упустить, поисковые машины запомнят вашу ошибку надолго!
Помимо прочего, новая версия сайта до момента публикации на основном домене должна пройти полностью валидацию вашей SEO‑команды.
Заключение
Ниже приведу чек‑лист, состоящий из пунктов, которые могут быть «не видны» владельцу проекта, но обязательны для контроля с привлечением команды разработки.
Чек-лист для проверки вашего проекта, чтобы история не повторилась заново
Сайт работает на современной и поддерживаемой вендором платформе;
В команде разработки/техподдержки есть Senior‑архитектор, который контролирует все новые доработки сайта;
Ведется и постоянно поддерживается в актуальном состоянии документация по проекту;
Постоянная работа с контролем технического долга: где‑то можем поднакопить, но где‑то обязательно сокращаем;
Периодически (раз в полгода) проводятся pen‑тесты и закрываются замечания;
Поддерживайте здоровье и привлекательность вашего сайта, вовремя обновляйте его backend и внешний вид. Процесс «старения» после определенного момента становится необратимым. Не доводите до такого состояния ваш проект! Если данная статья и пригодится вам на практике, то, надеюсь, только единожды :-)
