Как проходит аудит чужого кода перед приёмом проекта

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

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

Сначала нужно понять границы проекта

Одна из первых ошибок — считать, что сам репозиторий и есть весь проект. На практике веб-система может зависеть от:

• базы данных;
• внешних API;
• 1С или ERP;
• CRM;
• очередей;
• отдельных микросервисов;
• файловых хранилищ;
• cron-задач;
• поискового движка;
• CDN;
• систем авторизации;
• инфраструктурных настроек;
• внешних платёжных и логистических сервисов.

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

Доступы — часть аудита

Перед техническим анализом нужно проверить, что у новой команды вообще есть доступ ко всем необходимым элементам проекта. Обычно речь идёт не только о Git. Нужно понять, доступны ли:

• репозитории;
• серверы;
• панели хостинга;
• базы данных;
• CI/CD;
• мониторинг;
• логи;
• облачные сервисы;
• DNS;
• CDN;
• внешние API;
• аккаунты сторонних сервисов;
• документация;
• тестовые окружения.

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

Проект должен воспроизводиться

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

Поэтому обычно проверяют:

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

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

Версии технологий могут быть важнее качества отдельных функций

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

Нужно понять:

• поддерживаются ли текущие версии;
• доступны ли обновления безопасности;
• совместимы ли новые библиотеки;
• можно ли обновлять компоненты постепенно;
• существуют ли критичные зависимости от устаревших пакетов.

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

Архитектура показывает, насколько легко менять систему

Даже аккуратный код может быть сложным для развития, если границы между модулями размыты. Например, логика формирования заказа может одновременно находиться в контроллере, шаблоне, SQL-запросе и обработчике интеграции. Любое изменение приходится проверять в нескольких местах.

При аудите полезно понять:

• есть ли понятные модули;
• насколько они связаны между собой;
• разделена ли бизнес-логика и представление;
• где находятся интеграции;
• есть ли дублирование;
• насколько предсказуемо проходит изменение одной функции.

Здесь не обязательно стремиться к архитектурному идеалу. Важнее понять, можно ли безопасно развивать систему в текущем виде.

Сложность кода важна там, где она создаёт риск

Сам по себе длинный файл или большой класс ещё не означает плохого проекта. Но есть признаки, которые обычно повышают стоимость изменений:

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

Аудит должен не просто перечислить такие места, а связать их с реальными последствиями. Например, изменение расчёта скидки затрагивает пять независимых участков кода и не покрыто автотестами. Любая доработка требует полной ручной проверки корзины и оформления заказа. Так вывод становится полезным для бизнеса.

База данных требует отдельного внимания

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

• структуру таблиц;
• ключи;
• индексы;
• связи;
• объём данных;
• самые тяжёлые запросы;
• дублирование;
• миграции;
• работу с историческими данными.

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

Интеграции нужно проверять отдельно

Чужой проект часто оказывается сложным именно из-за интеграций.

Нужно понять:

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

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

Особое внимание — критичным бизнес-сценариям

Не все части проекта одинаково важны. Для интернет-магазина наиболее критичны каталог, корзина, оформление заказа, оплата, остатки и передача заказа дальше. Для B2B-платформы добавятся персональные цены, роли, документы и интеграции с ERP. При аудите полезно выделить именно эти сценарии и пройти их отдельно.

Например: найти товар → добавить в корзину → оформить заказ → получить оплату → передать заказ в ERP.

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

Тесты показывают, насколько безопасно менять проект

Полное отсутствие автоматических тестов не означает, что система плохая. Но это сильно влияет на способ дальнейшей разработки.

Нужно понять:

• есть ли unit-тесты;
• интеграционные тесты;
• end-to-end сценарии;
• что именно ими покрыто;
• запускаются ли они автоматически;
• можно ли доверять их результатам.

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

CI/CD показывает зрелость процесса

Как код попадает на production? Если разработчик подключается к серверу по FTP и вручную копирует изменённые файлы, даже хороший код остаётся уязвимым к человеческим ошибкам.

При аудите стоит проверить:

• есть ли отдельные окружения;
• как проходят сборка и деплой;
• выполняются ли тесты;
• можно ли откатить релиз;
• где хранятся секреты;
• кто имеет доступ к production;
• фиксируется ли история развёртываний.

Не каждому проекту нужен сложный Kubernetes-конвейер. Но процесс должен быть воспроизводимым и понятным.

Логи и мониторинг определяют скорость расследования

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

Полезно проверить:

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

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

Безопасность нельзя оставить за рамками

Технический аудит перед приёмом проекта не обязательно заменяет полноценный security-аудит, но базовые риски стоит проверить.

Например:

• версии с известными уязвимостями;
• открытые административные панели;
• секреты в репозитории;
• слабая работа с правами;
• неправильное хранение токенов;
• отсутствие журналирования критичных действий;
• чрезмерные права сервисных аккаунтов.

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

Документация должна отражать реальность

Наличие папки docs ещё не означает, что проект документирован.

Нужно проверить актуальность:

• архитектурных схем;
• инструкций развёртывания;
• описаний интеграций;
• API;
• бизнес-правил;
• процедуры релиза;
• восстановления;
• контактов ответственных.

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

Нужно проверить резервное копирование и восстановление

Сам факт наличия backup недостаточен.

Важно знать:

• что именно резервируется;
• как часто;
• где хранятся копии;
• есть ли ограничения по сроку хранения;
• кто отвечает за процесс;
• проверялось ли восстановление.

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

Отдельно стоит проверить фоновые и регулярные процессы

В проектах с длительной историей часто есть задачи, которые работают «где-то по расписанию».

Например:

• импорт каталога;
• обновление остатков;
• выгрузка заказов;
• очистка временных данных;
• генерация файлов;
• отчёты;
• резервное копирование;
• индексация поиска.

Нужно собрать такие процессы в единый список и понять:

• где они настроены;
• когда запускаются;
• кто их контролирует;
• как выглядит ошибка;
• можно ли безопасно перезапустить задачу.

Иначе после переноса сервера или изменения окружения часть автоматизации может просто исчезнуть.

Полезно проверить реальные релизы

Хороший способ понять проект — посмотреть, как в нём недавно реализовывались изменения. Например, взять несколько последних задач и посмотреть:

• сколько файлов они затронули;
• насколько локально было изменение;
• возникали ли регрессии;
• как проходило тестирование;
• как выпускался релиз;
• сколько времени заняло исправление проблем.

Это помогает оценить не только состояние кода, но и стоимость реальной разработки. Иногда архитектура выглядит неидеально, но команда годами стабильно выпускает изменения. В другом проекте код формально аккуратный, но каждый релиз превращается в рискованный процесс.

Аудит не должен превращаться в список претензий

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

Полезнее разделять выводы по влиянию. Например:

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

Тогда становится понятно, что нужно делать сразу, а что спокойно оставить до подходящего момента.

Не весь технический долг нужно исправлять до приёма

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

Например:

• восстановить доступы;
• закрыть критичную уязвимость;
• настроить backup;
• документировать деплой;
• добавить мониторинг критичной интеграции;
• покрыть тестами процесс, который предстоит менять первым.

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

Иногда аудит заканчивается рекомендацией сначала ничего не менять

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

В таком случае полезнее зафиксировать ограничения и учитывать их при будущих задачах. Аудит нужен не для того, чтобы обязательно продать переделку системы, а для принятия обоснованного решения.

Что должно остаться после аудита

Хороший результат — не просто документ с комментариями к коду. После обследования новая команда должна понимать:

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

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

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