Приёмка чужого кода вместе с сервером: что смотреть в первый день

MAATRIX

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

Почему код — это отдельная приёмка, а не продолжение осмотра сервера

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

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

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

История версий: что расскажет git log за пять минут

Первое, что стоит открыть, — не файлы кода, а его историю. История коммитов — это не формальность для галочки, а прямой след того, как проект разрабатывался: постепенно и осмысленно, или рывками, без ревью, без возможности понять, что и зачем менялось.

# сколько всего коммитов и когда был первый
git log --oneline | wc -l
git log --reverse --format="%ad %s" --date=short | head -5

# распределение активности по времени
git log --format="%ad" --date=format:"%Y-%m" | sort | uniq -c

# кто и сколько коммитил
git shortlog -sn --all

Есть несколько сигналов, на которые стоит обратить внимание сразу:

• Один гигантский коммит вместо истории. Если git log показывает единственный коммит «initial commit» с тысячами изменённых строк, а дальше почти ничего — значит, история либо не велась изначально (код писали вне git и залили одним архивом), либо репозиторий специально «схлопнули» перед передачей. В обоих случаях git blame вам не поможет — все строки окажутся привязаны к одному коммиту, и вы теряете возможность понять, почему код выглядит именно так.
• Сообщения коммитов без содержания. Строки вида fix, wip, правки на протяжении сотен коммитов — не катастрофа сама по себе, но признак того, что решения принимались быстро, без обсуждения и привычки объяснять, зачем сделано именно так.
• Ветки и незавершённая работа. git branch -a покажет, остались ли забытые ветки с недоделанными фичами — иногда там лежит код, который объясняет странные заготовки в основной ветке.
• Резкие провалы активности. Месяцы без единого коммита, за которыми следует всплеск, обычно означают смену исполнителя или паузу — полезно понимать, где проходят эти границы, потому что стиль кода до и после такого разрыва часто заметно отличается.

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

Зависимости: возраст, открытые уязвимости и цена будущего обновления

Дальше стоит посмотреть, на чём вообще держится проект — какие библиотеки и какой версии, и когда их обновляли в последний раз.

# Node.js
npm outdated
npm audit

# Python
pip list --outdated
pip-audit          # если установлен

# PHP / Composer
composer outdated
composer audit

# Ruby
bundle outdated
bundle audit

Здесь важна не столько абсолютная свежесть каждого пакета — вечно актуальный package-lock.json не бывает и не обязателен, — сколько два конкретных сигнала.

Разрыв в мажорных версиях. Если фреймворк или язык отстаёт от актуальной ветки на несколько мажорных релизов, вас ждёт не «обновить одной командой», а отдельный проект миграции: breaking changes копятся от версии к версии, и чем больше разрыв, тем дороже переход. Оценивать точный объём работ в первый день не нужно — достаточно зафиксировать сам факт разрыва и держать его в уме при планировании.

Открытые уязвимости в зависимостях. npm audit и его аналоги покажут известные CVE в используемых версиях пакетов — не все критичны на практике, но игнорировать список целиком нельзя, особенно если находки высокой критичности касаются пакетов, работающих с пользовательским вводом или сетью. Отдельная опасность здесь — не только устаревшие пакеты, но и слепое доверие свежим: обновление зависимости само по себе иногда оказывается источником проблемы, если апдейт подтягивался автоматически без проверки диффа. Использование latest вместо зафиксированных версий или диапазонов без lock-файла в репозитории — тоже находка: воспроизводимость сборки под вопросом.

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

Тесты: есть ли они и что реально покрывают

Наличие тестов — один из самых быстрых индикаторов того, насколько безопасно вносить изменения в проект. Разница между «тестов нет вообще» и «есть хотя бы базовое покрытие ключевых сценариев» — это разница между «любое изменение — это прыжок в темноту» и «я хотя бы узнаю сразу, если что-то очевидное сломалось».

Проверка занимает несколько минут:

# есть ли вообще каталог с тестами и команда для их запуска
find . -type d -iname "*test*" -not -path "*/node_modules/*" -not -path "*/vendor/*"
cat package.json | grep -A3 '"scripts"'   # ищите "test"

# запустить и посмотреть, что реально проходит
npm test
pytest
composer test

Важные нюансы, которые быстрый взгляд легко упускает:

• Тесты есть, но не запускаются. Такое случается чаще, чем кажется: тестовый набор писался под старую версию зависимости или под окружение, которого уже нет. Формально в репозитории «есть тесты», по факту пользы от них никакой — стоит один раз убедиться, что команда npm test действительно завершается, а не падает на этапе настройки окружения.
• Тесты проходят, но покрывают не то. Сотня тестов на утилитарные функции при полном отсутствии проверок критичной бизнес-логики (расчёт цены, обработка платежа, права доступа) даёт ложное чувство защищённости. Беглый просмотр названий файлов в каталоге тестов за пару минут покажет, какие модули вообще упоминаются, а какие обойдены стороной.
• Полное отсутствие тестов — не приговор, а вводная для планирования. Многие рабочие проекты годами живут без единого теста, и это не всегда ошибка — если сложность приложения невелика, а изменения проверяются вручную перед деплоем. Проблема начинается, когда отсутствие тестов сочетается с высокой частотой изменений и множеством людей, работающих с одним кодом: тогда каждое изменение рискует незаметно сломать что-то в другом месте.

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

Структура и читаемость: сколько времени уйдёт на расшифровку логики

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

Смотреть стоит на несколько конкретных вещей:

• Есть ли вообще понятная структура каталогов. Разделение на слои (контроллеры, модели, сервисы) или по фичам — не так важно, какой именно подход выбран, важно, что он вообще прослеживается и одинаково применяется по всему проекту, а не меняется от модуля к модулю.
• Насколько длинные функции и файлы. Один файл на несколько тысяч строк, где вперемешку лежат обработка запросов, работа с базой и бизнес-логика, — почти гарантированно будет тяжело менять безопасно: любое изменение рискует задеть что-то в стороне, не связанное с задачей на первый взгляд.
• Названия говорят о содержимом или нет. Функции handle2, doStuff, temp_fix_final_v3 — не просто эстетическая проблема. Они означают, что вам придётся читать реализацию каждый раз, когда нужно понять, что вызывать, вместо того чтобы ориентироваться по имени.
• Дублирование одной и той же логики в нескольких местах. Одна и та же проверка прав или формула расчёта, скопированная в разных файлах с небольшими отличиями, — частый след того, что рефакторинг откладывали раз за разом: исправление бага в одном месте не гарантирует исправления во всех остальных.

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

Первый день — это не аудит: на чём сосредоточиться, а что отложить

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

Более рабочий подход — сфокусироваться на нескольких сигналах, каждый из которых дёшево проверить и который сразу задаёт направление:

1. История версий — есть ли она вообще, и что она говорит о темпе и стиле прошлой разработки.
2. Зависимости — насколько велик разрыв с актуальными версиями и есть ли открытые уязвимости.
3. Тесты — есть ли они, запускаются ли, что покрывают.
4. Один пройденный сценарий — вместо чтения всего кода целиком.

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

Полезно сразу завести файл с находками — конкретные факты, а не общие впечатления. «В проекте нет тестов для модуля оплаты», «зависимость X не обновлялась несколько лет, в issues есть открытые уязвимости», «история коммитов начинается с одного коммита без даты» — такие записи пригодятся и вам, и тем, кому вы будете объяснять текущее состояние проекта.

Честный разговор о плохом коде: как и когда об этом сообщать

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

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

Правильный момент для разговора — сразу после того, как собраны конкретные факты, а не после того, как накопится усталость и раздражение. Важно оформить это как факты с последствиями, а не как жалобу:

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

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

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

Частые вопросы