«Нам нужно поменять одну кнопку и добавить поле в форму. Это ведь на полчаса?» Если сайт делали мы — возможно. Если сайт делала другая команда пять лет назад, потом его дорабатывали два фрилансера, а документации нет, — полчаса уйдут только на то, чтобы найти, в каком из трёх шаблонов эта кнопка выводится.
Доработка чужих проектов — значительная часть нашей работы. Мы привыкли к тому, что каждый такой сайт — немного детектив. В этой статье расскажем, как мы выстраиваем работу с незнакомым кодом, чтобы правки не ломали то, что работало, и чтобы заказчик понимал, за что платит.
Почему чужой сайт — это всегда риск
Код сайта — это не только то, что видно в файлах. Это решения, которые принимали разработчики, их привычки, компромиссы и временные заплатки, ставшие постоянными. Когда команда уходит, всё это знание уходит вместе с ней.
Что мы обычно встречаем на унаследованных проектах:
- правки, сделанные прямо в ядре CMS, из-за чего движок невозможно обновить без потери изменений;
- несколько версий одного шаблона, из которых используется только одна, но никто не помнит какая;
- закомментированные куски кода с пометками вроде «не трогать, иначе сломается каталог»;
- интеграции с внешними сервисами, ключи от которых записаны прямо в коде;
- отсутствие тестового окружения: все правки делались сразу на рабочем сайте;
- нет системы контроля версий, а значит, нет истории изменений.
Ничего из этого не означает, что сайт плохой. Он может годами приносить заявки. Но вносить в него изменения без подготовки — всё равно что ремонтировать проводку в доме без схемы.
Подготовка: доступы, копия и стенд
Собираем все доступы
Звучит банально, но именно здесь проект может застрять на недели. Нам нужны:
- Доступ к хостингу или серверу — панель управления и SSH.
- Доступ к базе данных.
- Административный доступ к CMS.
- Доступ к регистратору домена и управлению DNS.
- Доступы к подключённым сервисам: CRM, платёжная система, почтовые рассылки, аналитика.
- Репозиторий с кодом, если он существует.
Часто выясняется, что владелец сайта не знает половины этих доступов. Хостинг оформлен на прежнего подрядчика, домен — на бывшего сотрудника, а пароль от админки есть только у менеджера, который уволился. Мы помогаем восстановить доступы через провайдеров и регистраторов, и сразу переоформляем всё на компанию заказчика. Это первое, что делает проект управляемым.
Делаем копию и разворачиваем стенд
Прежде чем что-то менять, мы делаем полную резервную копию: файлы и база данных. Затем разворачиваем копию сайта на тестовом сервере. Это наша песочница, где можно экспериментировать, ничего не ломая.
Сразу же кладём код в систему контроля версий. Даже если раньше её не было, с этого момента каждое изменение будет зафиксировано: кто, когда и зачем поменял. Если что-то пойдёт не так, всегда можно вернуться к рабочему состоянию.
Уже на этом этапе часто всплывают сюрпризы. Сайт не разворачивается на чистом сервере, потому что зависит от какой-то нестандартной настройки, о которой никто не помнит. Или в базе обнаруживаются таблицы от давно удалённых модулей, которые весят больше, чем весь полезный контент. Всё это мы фиксируем.
Аудит: что здесь вообще происходит
Это самый важный этап, и мы никогда его не пропускаем. Цель — понять, как устроен сайт, и составить карту рисков. Мы смотрим на несколько уровней.
Платформа и окружение
Какая CMS и какой версии, какая версия PHP или другого языка, какие модули и плагины установлены и когда обновлялись. Есть ли известные уязвимости в используемых версиях. Это сразу показывает, насколько сайт устарел и насколько безопасен.
Структура кода
Где лежат шаблоны, где бизнес-логика, где кастомные модули. Вносились ли изменения в ядро. Насколько код соответствует стандартам платформы. Мы ищем точки входа: откуда начинается обработка запроса, как формируется страница каталога, как обрабатывается форма.
Интеграции и фоновые задачи
С чем сайт обменивается данными, по какому расписанию запускаются задачи: выгрузка товаров, отправка писем, обновление курсов. Это та часть, которая чаще всего ломается незаметно — сайт открывается, а цены перестали обновляться неделю назад.
Производительность и безопасность
Сколько времени генерируются ключевые страницы, какие запросы к базе самые тяжёлые. Есть ли следы взлома, посторонние файлы, подозрительные пользователи в админке.
По итогам аудита заказчик получает отчёт: что в порядке, что вызывает опасения, что требует срочного вмешательства. Такой документ полезен и сам по себе, даже если дальнейшие работы не планируются. Подробнее о формате — на странице аудита сайта.
Как мы читаем незнакомый код
Расскажем немного о технической кухне, потому что заказчики часто спрашивают, почему разобраться в коде занимает время.
Идём от поведения к коду. Не пытаемся прочитать весь проект целиком — это бессмысленно. Берём конкретную функцию, например оформление заказа, и прослеживаем её путь: какой шаблон выводит кнопку, какой обработчик получает данные, что происходит дальше. Так постепенно складывается картина.
Ищем по уникальным строкам. Текст на кнопке, название поля, CSS-класс — поиск по проекту быстро показывает, где это используется. Если строка находится в пяти местах, значит, есть дубли, и это повод разобраться, какой вариант актуален.
Включаем логирование и отладку на стенде. Смотрим, какие файлы реально подключаются при загрузке страницы, какие запросы уходят в базу. Это отсекает мёртвый код, который лежит в проекте, но не используется.
Пишем документацию по ходу. Каждое открытие — где лежит логика скидок, как устроен обмен с учётной системой — мы записываем. Через месяц работы у проекта появляется то, чего у него никогда не было: описание.
Первые правки: начинаем с малого
После аудита велико желание сразу взяться за большие задачи. Мы так не делаем. Первые правки — небольшие и безопасные: исправить очевидный баг, поменять текст, добавить поле в форму. Это позволяет проверить, как работает процесс выкатки изменений, и не наткнуться ли на неожиданные зависимости.
Каждая правка проходит одинаковый путь:
- Изменение делается на тестовом стенде.
- Проверяется не только сама правка, но и связанные функции: если меняли форму, проверяем, что заявки по-прежнему доходят в CRM.
- Изменение согласуется с заказчиком.
- Делается резервная копия рабочего сайта.
- Изменение выкатывается на рабочий сайт.
- Проводится повторная проверка.
Да, это дольше, чем поправить файл прямо на сервере. Но это гарантирует, что в пятницу вечером не перестанут приходить заказы.
Когда лучше не дорабатывать, а переделать
Иногда аудит показывает, что сайт проще сделать заново, чем развивать. Признаки такой ситуации:
- CMS настолько устарела, что её обновление равносильно переписыванию всех модулей;
- код настолько запутан, что каждая правка ломает что-то в другом месте;
- архитектура не позволяет реализовать то, что нужно бизнесу: например, мультирегиональность или личный кабинет;
- стоимость планируемых доработок сопоставима со стоимостью нового сайта.
Мы честно говорим об этом заказчику, приводя расчёты. Но и не спешим с таким выводом: в большинстве случаев сайт можно привести в порядок поэтапно, без остановки бизнеса. Если же решение о новом сайте принято, накопленные при аудите знания очень помогают — мы точно знаем, какие функции важны и какие данные нужно перенести.
Как выстроить работу дальше
Когда первичный разбор закончен, у проекта появляется нормальная инфраструктура: репозиторий, тестовый стенд, документация, регулярные бэкапы. Дальше работа идёт как с любым сайтом на поддержке — задачи ставятся, оцениваются, выполняются.
Мы рекомендуем параллельно с текущими задачами постепенно гасить технический долг: обновлять модули, выносить правки из ядра, удалять мёртвый код. Не нужно делать это одним большим проектом — достаточно выделять на это часть времени каждый месяц. Через полгода сайт становится заметно стабильнее и дешевле в обслуживании. Узнать, как мы работаем с такими проектами, можно на странице доработки сайтов.
Вывод
Доработка чужого сайта начинается не с правок, а с подготовки: сбор доступов, резервная копия, тестовый стенд, система контроля версий и аудит. Только после этого можно уверенно вносить изменения, не боясь сломать то, что работает. Первая неделя на унаследованном проекте может показаться заказчику «бесполезной» — ведь видимых изменений нет. Но именно она определяет, будет ли дальнейшая работа предсказуемой или превратится в бесконечное тушение пожаров.
