Что мы смотрим в чужом коде за первые два дня

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

Порядок важен: эти проверки быстрые и дают понимание состояния проекта раньше, чем мы вообще откроем бизнес-логику.

1. Запускается ли проект локально

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

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

2. Есть ли история в git и как она выглядит

Смотрим журнал коммитов. Нас интересует не аккуратность сообщений, а другое: сколько людей работало, были ли длинные периоды без изменений, нет ли коммитов вида «fix» по сорок файлов. Последнее обычно означает правки прямо на сервере с последующей заливкой.

3. Лежат ли секреты в репозитории

Проверяем историю на пароли, ключи API и строки подключения к базе. Находим чаще, чем хотелось бы. Если нашли — ключи нужно менять, потому что история git есть у всех, кто когда-либо клонировал проект, включая уволившихся.

4. Состояние зависимостей

Сколько пакетов и насколько они устарели. Нас беспокоят не минорные отставания, а два случая: мажорные версии старше трёх лет и пакеты, которые автор удалил или бросил. Второе опаснее — обновить не получится, придётся переписывать.

5. Есть ли бэкапы и проверялись ли они

Главный вопрос не «есть ли бэкапы», а «восстанавливались ли они когда-нибудь». Бэкап, который никто не пробовал развернуть, — это не бэкап, а предположение. Мы пробуем развернуть в первые дни.

6. Куда уходят ошибки

Если нет Sentry или аналога, значит, об ошибках узнают от пользователей. Это первое, что мы ставим, причём до любых правок: нужно увидеть реальную картину, а не ту, которую описал заказчик.

На одном проекте так выяснилось, что оплата падала у 4 % пользователей уже восемь месяцев. Заказчик об этом не знал: люди просто уходили.

7. Схема базы данных

Выгружаем схему и смотрим на неё до кода. Понятная структура таблиц почти всегда означает, что и код окажется разумным. Таблица с 80 колонками и названиями вроде field1, field2 — сигнал, что бизнес-логика будет такой же.

8. Миграции

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

9. Как происходит деплой

Автоматический деплой из репозитория — хорошо. Загрузка файлов по FTP руками — плохо, но поправимо. Хуже всего вариант «деплой делал только Серёжа, он больше не работает».

Что получается в итоге

После двух дней у нас есть ответ на главный вопрос заказчика: это чинится или дешевле переписать. Важно, что ответ «переписать» мы даём редко — примерно в одном случае из шести. Чаще проект в рабочем состоянии, просто за ним никто не следил.