# Приёмка чужого проекта: что проверять в первую очередь

> Версии, версионный контроль, безопасность. Порядок проверок, который находит неприятное раньше, чем оно найдёт вас.

30 марта 2026 · Заря · 6 минут

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

## Сначала — версии, а не код

Первое, что стоит сравнить: версии PHP, базы и самой платформы на боевом сервере и на тестовом. Расхождение здесь обесценивает любую проверку на деве.

Реальный случай: прод жил на PHP 8.0, дев — на 8.2. Формулировка «работает на деве» в такой связке не значит ничего, и это стоит зафиксировать письменно до начала работ.

## Что в версионном контроле, а что мимо

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

- Есть ли git вообще и совпадает ли его содержимое с тем, что на проде
- Не исключены ли из него правилами игнорирования нужные файлы
- Как устроена выкатка и что она перезаписывает
- Есть ли миграции структуры базы или её правят руками

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

## Безопасность: три места, куда смотреть первыми

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

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

## Как оформить результат

Список из восьмидесяти замечаний, где отсутствие alt у иконки стоит рядом с открытой наружу базой, бесполезен: по нему не начнут работу. Сортируйте по правилу «сначала то, что чинит потери, потом то, что даёт рост».

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

## Принимаете проект

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

[Посмотреть услугу: аудит и приёмка](https://it-zarya.ru/services/audit/) [Обсудить задачу](https://it-zarya.ru/contacts/)

---

Источник: https://it-zarya.ru/blog/project-handover/ · IT-агентство «Заря» · itzarya@mail.ru
Markdown-версия любой страницы сайта — тот же адрес с `.md` на конце. Индекс для ассистентов: https://it-zarya.ru/llms.txt