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

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

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

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

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

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

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

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

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

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

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

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

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

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