Разработчик ушёл: что будет с вашей программой?

Однажды разработчик перестаёт отвечать на письма. Или агентство сообщает, что закрывается. Или единственный человек, который понимал систему, уходит на пенсию или в другую компанию. Приложение пока работает — счета выставляются, заказы принимаются, — но никто уже не знает, как оно устроено внутри и что будет, если что-то сломается.

Такое случается чаще, чем принято думать, и обычно это не катастрофа. Катастрофой это становится, когда в первые недели принимаются неверные решения. Ниже — порядок действий, который я советую в такой ситуации.

Шаг первый: закрепите доступы

Главный риск не в том, что код плохой. Главный риск в том, что вы его не контролируете. Прежде всего составьте список и проверьте, что из этого у вас в руках:

• Репозиторий кода (GitHub, GitLab, Bitbucket или другой) — на чьём аккаунте он и есть ли у вас права владельца или администратора?
• Сервер или хостинг — на кого оформлен договор, кто оплачивает счета, есть ли у вас доступ по SSH или к панели управления?
• Домен — на кого он зарегистрирован и когда истекает? Истёкший домен — самый быстрый способ остановить сервис.
• База данных — где она находится и есть ли у вас логин и пароль?
• Внешние сервисы — отправка почты, платёжное решение, облачное хранилище, API-ключи. Многие из них зарегистрированы на личную почту разработчика.

Если связь с разработчиком ещё есть, попросите передать все доступы сразу, а не «когда будет время». Если связи нет, начните с того, что оформлено на вашу фирму: регистратор домена и хостинг-провайдер обычно восстанавливают доступ владельцу, если он может подтвердить право собственности.

Шаг второй: сделайте резервную копию, прежде чем что-то трогать

Получив доступ, сделайте полную копию: код, база данных, загруженные файлы и настройки сервера. Не потому, что сейчас что-то сломано, а потому, что в ближайшие недели кто-то начнёт работать внутри системы — и нужно будет знать, какой она была до этого.

Проверьте также, делаются ли автоматические копии вообще и куда. Нередко выясняется, что копии уходили на компьютер разработчика или тихо перестали создаваться несколько месяцев назад.

Шаг третий: не переписывайте систему в панике

Первая реакция часто такая: «Перепишем всё с нуля, тогда хотя бы всё будет под нашим контролем». Почти всегда это неверный первый шаг.

Работающая система содержит накопленные за годы бизнес-правила, исключения и исправления, которые не описаны ни в одной спецификации. Переписать — значит заново всё это обнаружить, обычно уже после того, как что-то пошло не так. А старая система тем временем должна работать дальше без присмотра.

Разумнее другой порядок: сначала сделать существующую систему стабильной и понятной, а потом решать, развивать её дальше или заменять по частям.

Как я принимаю незнакомый код

Я занимаюсь веб-проектами с 2014 года и восстанавливал в государственном и частном секторе приложения старше десяти лет, чьи авторы давно ушли. Работа всегда идёт в одном порядке.

1. Аудит. Разбираю, из чего состоит система: язык и фреймворки, их версии, база данных, настройки сервера, внешние зависимости. Выясняю, что устарело, что представляет угрозу безопасности, а что работает хорошо.

2. Документирование. Описываю, как устроена система, как её запустить и где что находится. Этот документ остаётся у вас — в следующий раз никому не придётся начинать с нуля.

3. Запуск в отдельной среде. Прежде чем что-то менять, я запускаю систему в отдельной среде, которая не затрагивает реальных пользователей. Только так можно безопасно проверять изменения.

4. Сначала маленькие и безопасные исправления. Первые изменения намеренно небольшие: обновления безопасности, самые срочные ошибки, наведение порядка с резервным копированием. Каждое изменение отслеживается и при необходимости откатывается.

5. Только потом крупные шаги. Когда система стабильна и понятна, можно говорить о переводе компонентов на новые версии и о новой функциональности. В прежних проектах именно такой порядок позволил полностью сохранить бизнес-функциональность и затем развивать систему дальше.

Если приложение работает на Linux-сервере, я могу взять на себя и администрирование сервера — настройки сервера часто задокументированы так же плохо, как и код. Если сервер нужно сменить, об этом отдельная статья: перенос сервера без простоя.

Тревожные признаки: когда тянуть нельзя

Иногда ждать нельзя. Срочно покажите систему специалисту, если:

• операционная система сервера или фреймворк больше не поддерживаются и обновления безопасности не выходят;
• срок действия домена или сертификата истекает в ближайшие недели;
• резервных копий нет или восстановление из них ни разу не проверялось;
• система начала тормозить или иногда останавливается «сама»;
• никто не знает, где исходный код, — есть только версия, работающая на сервере.

Последний случай сложнее, но выход есть и из него. Об опасностях устаревших компонентов подробнее в статье опасности необновляемого WordPress — принцип одинаков для любой платформы.

Как избежать этого в будущем

Когда система снова под контролем, стоит закрепить три вещи: все доступы оформлены на компанию, а не на человека; код хранится в репозитории, к которому есть доступ хотя бы у двоих; и есть короткий документ о том, как запустить и восстановить систему. Это стоит недорого, и следующая смена разработчика уже не будет кризисом.

Напишите мне

Если ваш разработчик пропал, а система ещё работает, но никто не решается её трогать, опишите ситуацию в паре предложений здесь — я отвечу в течение одного рабочего дня и честно скажу, смогу ли помочь и как. Соглашение о конфиденциальности для меня обычное дело, так что код и данные можно показывать спокойно. Если удобнее просто поговорить, другие способы связи есть на странице контактов.

Можно ли принять систему, если исходного кода нет?

Часто да, но это зависит от технологии. Некоторые приложения (например, на PHP) работают на сервере в виде исходного кода, так что код фактически есть. С компилированными приложениями работы больше. Я проверяю это во время аудита.

Нужно ли сразу решать, переписывать ли систему?

Нет. Сначала систему нужно сделать стабильной и понятной. Выбирать между развитием и заменой гораздо проще, когда известно, что внутри.