Разработчик пропал: как продолжить чужой проект
Жуков Сергей ·
Когда исполнитель перестаёт отвечать, первая задача — сохранить управление продуктом и данными. Решение о доработке или переписывании стоит принимать после проверки проекта. Даже работающий сайт может зависеть от аккаунтов и настроек, доступных только прежнему разработчику.
Соберите доступы и определите владельцев
Проверьте домен, хостинг, репозиторий, базу данных, почту, платёжный сервис и другие интеграции. Для мобильного приложения добавьте аккаунты магазинов и средства подписания сборок. Зафиксируйте владельца каждого аккаунта и способ восстановления доступа.
Предоставляйте новому исполнителю отдельные доступы с необходимыми правами. После передачи управления проверьте старые доступы и смените секреты в согласованном порядке: резкая замена ключа без обновления приложения может остановить работающую интеграцию.
Сохраните текущее состояние
До изменений подготовьте резервную копию данных и файлов, сохраните текущую версию кода и конфигурацию развёртывания. Наличие архива ещё не доказывает, что продукт можно восстановить: важна проверка восстановления на отдельном окружении.
Составьте список известных проблем и укажите, как их воспроизвести. Скриншот ошибки помогает, но последовательность действий, время возникновения и ожидаемый результат позволяют быстрее найти причину. Не передавайте пользовательские данные через публичные чаты.
Что должен дать первичный аудит
Аудит должен ответить, можно ли собрать и запустить проект, какие компоненты поддерживаются, где хранятся данные и как выпускаются обновления. Отдельно проверяются критические сценарии: вход, права доступа, оплата и работа с данными.
Полезный результат — список обнаруженных проблем с приоритетами, ограничения оценки и план ближайших работ. Если часть инфраструктуры недоступна, это нужно указать явно. Обещание точной стоимости исправлений без доступа к коду и окружению требует осторожности.
Продолжать или переписывать
Чужой код сам по себе не является причиной переписывания. Сначала оцените, можно ли исправить критические проблемы и развивать продукт небольшими изменениями. Полная замена требует переноса данных, повторной реализации сценариев и перехода пользователей на новую версию.
Переписывание может быть оправдано, когда ограничения архитектуры мешают обязательным функциям или стоимость изменений становится несоразмерной. Решение должно опираться на конкретные ограничения и сравнение вариантов, а не на предпочтение другого стека.
Как провести первые доработки
Начните с небольшого изменения, которое можно проверить на тестовом окружении. Договоритесь о резервной копии, критериях проверки и способе возврата предыдущей версии. Изменения базы данных требуют отдельного плана: возврат старого кода не всегда возвращает старую структуру данных.
В первую очередь устраните проблемы, влияющие на доступность, потерю данных и основной путь клиента. Косметические изменения и крупные новые функции можно планировать после стабилизации.
Как организовать дальнейшую работу
Доступ к репозиторию и ключевым аккаунтам должен оставаться у заказчика. Зафиксируйте порядок выпуска обновлений, хранения секретов, резервного копирования и передачи проекта. Документация должна позволять другому специалисту собрать и запустить продукт.
Для первичного обсуждения пришлите стек, описание проблем, перечень доступных материалов и срочные ограничения. Если нужен отдельный аудит, его объём и результат согласуются до начала исправлений.