Содержание
Работа с легаси-кодом почти всегда начинается не с кода, а с передачи проекта: прошлая команда уходит, новая приходит, и в этот момент бизнес рискует потерять больше всего. Теряются доступы, бэкапы, знания о том, почему система устроена именно так. Большую часть этих потерь можно предотвратить чек-листом и правильным порядком приёмки.
Когда проект переходит к новой команде
Передача проекта случается в четырёх ситуациях, и в каждой свой главный риск.
- Подрядчик пропал. Перестал отвечать, закрыл студию, ушёл в другой проект. Главный риск: доступы оформлены на него, и забрать их можно только через регистратора и хостинг.
- Своя команда уходит. Компания сокращает разработку или выводит её на аутсорс. Риск: знания уходят вместе с людьми, а документации нет.
- Смена подрядчика по решению бизнеса. Есть время на нормальную передачу, но прошлый подрядчик не заинтересован в её качестве.
- Ключевой разработчик увольняется. Формально команда на месте, но систему целиком понимал один человек.
Во всех четырёх случаях новой команде достаётся легаси: работающая система, которую писали другие люди и которую никто из новых участников не знает. Что это значит и чем грозит, подробно разобрали в статье «Легаси: что это такое».
Чек-лист: что забрать у прошлой команды
Правило одно: всё, без чего система не работает, должно быть оформлено на компанию. Не на подрядчика, не на сотрудника, не на «нашего программиста Диму».
Частая проблема при передаче проекта: домен или хостинг зарегистрирован на физлицо, которое давно не работает с компанией. Пока всё работает, это незаметно. Когда домен не продлили, сайт пропадает, а восстановить права можно только через регистратора, с документами и неделями переписки.
Что передать, кроме доступов
Доступы дают возможность зайти в систему. Понять её помогают знания, которые обычно нигде не записаны. Попросите прошлую команду описать хотя бы это:
- Схему системы. Из каких частей она состоит, как они общаются между собой, какие внешние сервисы используются.
- Регулярные задачи. Что запускается по расписанию: выгрузки, обмен с 1С, рассылки, очистка. Про них забывают чаще всего, а ломаются они тихо.
- Известные проблемы. Что периодически падает и как это обычно чинят. Каждый такой обходной путь экономит новой команде дни поиска.
- Нестандартные бизнес-правила. Особые скидки, исключения для конкретных клиентов, ручные операции.
- Как выкладывать изменения. Есть ли автоматическая выкладка или файлы копируются руками, где тестовый стенд, как откатиться.
Если прошлая команда уже недоступна, эти знания восстанавливаются из кода, конфигураций и логов. Это дольше, но реально, и по ходу работы появляется документация, которой раньше не было.
Как новая команда принимает систему
Приёмка легаси-системы идёт в определённом порядке. Новая команда сначала страхует систему и только потом начинает её менять.
- Инвентаризация. Проверяем каждый доступ: работает ли он, на кого оформлен, когда истекает. Составляем таблицу сроков продления домена, сертификатов и подписок.
- Страховка. Делаем свежий бэкап и проверяем, что из него можно восстановиться. Включаем мониторинг, чтобы узнавать о сбоях раньше клиентов.
- Копия системы. Разворачиваем тестовый стенд, где можно экспериментировать, не трогая боевой сервер.
- Карта и риски. Описываем, как устроена система, где бизнес-правила, где единственные точки отказа. Этот шаг называют техническим аудитом.
- Первые задачи. Начинаем с мелких и обратимых доработок. Так команда знакомится с кодом, а бизнес видит, что работа идёт.
Ловушки, на которых теряют деньги
| Ловушка | Чем грозит | Как избежать |
|---|---|---|
| Домен на подрядчике | Сайт пропадёт, когда домен не продлят | Перенести домен на компанию до расставания |
| Код на сервере не совпадает с репозиторием | Первая же выкладка из репозитория откатит чьи-то правки | Сравнить код на сервере с репозиторием и зафиксировать разницу |
| Бэкап на том же сервере | При поломке сервера пропадут и данные, и копии | Хранить копии отдельно и проверять восстановление |
| Ключи API в коде и на личных аккаунтах | Утечка или отключение сервиса после ухода человека | Перевыпустить ключи на аккаунты компании |
| Забытые задачи по расписанию | Тихо перестаёт работать обмен с 1С или рассылки | Выписать все задачи и поставить их на мониторинг |
| Срочные доработки в первую неделю | Новая команда ломает то, чего ещё не понимает | Сначала страховка и карта, потом изменения |
Если прошлый подрядчик пропал
Когда передать проект некому, порядок действий меняется.
- Соберите всё, что есть у вас: договоры, счета, письма, доступы в личных кабинетах. Часто доступов у компании больше, чем кажется.
- Восстановите права на домен и хостинг через регистратора и хостинг-провайдера. Понадобятся документы, что компания пользуется ресурсом и оплачивает его.
- Не трогайте код, пока нет бэкапа. Первое действие на сервере: полная копия файлов и базы.
- Позовите команду, которая умеет разбираться в чужом коде. Без документации карта системы восстанавливается из кода, конфигураций и логов.
Как мы принимаем проекты
Мы в ИнТерраТех берём на поддержку системы, которые писали другие команды, и это наш основной формат. Начинаем с аудита: фиксируем, что есть, в каком оно состоянии и где риски. После аудита и получения доступов подключаемся к поддержке за 3-5 рабочих дней. Критичные инциденты берём в работу в течение 2 часов, сроки записаны в договоре.
Частые вопросы
Сколько времени занимает передача проекта?
Инвентаризация доступов и страховка занимают несколько дней. Полное понимание системы среднего размера приходит за 2-4 недели. Если прошлая команда помогает с передачей, быстрее.
Что делать, если прошлый подрядчик не отдаёт доступы?
Восстанавливать права через регистратора домена и хостинг-провайдера на основании договоров и платёжных документов. Код, если он лежит только у подрядчика, можно частично забрать с боевого сервера. Параллельно стоит подключить юриста.
Нужна ли документация, чтобы новая команда взяла проект?
Нет. С документацией быстрее, но большинство легаси-систем её не имеет. Опытная команда восстанавливает устройство системы из кода, конфигураций и логов и по ходу пишет документацию.
Можно ли сразу начать делать новые функции?
Мелкие и обратимые задачи можно с первых недель. Крупные изменения лучше начинать после карты системы и списка рисков, иначе новая команда рискует сломать то, чего ещё не понимает.
Чем поддержка легаси-кода отличается от обычной поддержки?
Больше времени уходит на понимание: прежде чем что-то чинить, нужно разобраться, почему оно устроено именно так. Поэтому поддержку легаси-систем начинают с аудита, а не с первой заявки.
