Ответ
Мой первый шаг — всесторонний анализ проекта, чтобы понять его текущее состояние и контекст.
- Изучение кодовой базы и архитектуры. Я просматриваю структуру каталогов, основные модули, точки входа и зависимости между компонентами. Важно понять выбранные архитектурные паттерны (например, слоистая архитектура, DDD, CQRS).
- Запуск и исследование. Я разворачиваю проект локально, проверяю README и документацию (если есть), запускаю тесты (
php artisan testили./vendor/bin/phpunit), чтобы оценить покрытие и стабильность. - Анализ инфраструктуры. Изучаю конфигурацию окружений (
.env-файлы), зависимости вcomposer.json, скрипты деплоя, настройки CI/CD (например, GitHub Actions или GitLab CI). - Знакомство с бизнес-логикой. Я ищу core-домены приложения, изучаю основные сущности и их взаимосвязи. Часто для этого помогает анализ миграций базы данных и ключевых моделей.
На основе этого анализа я составляю первоначальную карту рисков (технический долг, отсутствие тестов, сложные для понимания модули) и план действий на первые недели: от исправления критических багов до начала рефакторинга наиболее проблемных мест.
Ответ 18+ 🔞
Слушай, давай я тебе на пальцах объясню, как я обычно влезаю в новый проект, чтобы не облажаться сходу. Это как приходишь в чужую квартиру — первым делом смотришь, где тут сортир, а где холодильник, а то потом овердохуища проблем будет.
Первым делом, ёпта, я начинаю с тотального разведовательного шатания по коду. Открываю структуру папок и смотрю, как всё устроено. Где тут главные входы, какие модули друг на друга завязаны, какой архитектурный пиздец тут использовали — слои, DDD или ещё какую хитрожопую хуйню. Это чтобы сразу понять, с чем имею дело, а не как слепой щенок.
Дальше — запуск и обнюхивание. Разворачиваю всё это хозяйство у себя. Если есть README — читаю, но обычно там или пусто, или написано, будто на дворе 2002-й год. Запускаю тесты (php artisan test), смотрю, сколько их и проходят ли они вообще. Если тесты падают как подкошенные — это первый звоночек, что проект, возможно, накрылся медным тазом ещё до моего прихода.
Потом лезу в инфраструктуру. Смотрю .env-файлы, composer.json, как настроено развёртывание, какие скрипты CI/CD висят. Если вижу там дикие костыли, доверия ебать ноль сразу становится. Это как заглянуть под капот машины и увидеть, что там всё скреплено изолентой и надеждой.
Ну и наконец, пытаюсь въехать в саму суть, в бизнес-логику. Ищу, ради чего весь этот цирк затевался — ключевые модели, связи между ними, главные процессы. Часто самый честный рассказчик — это миграции базы данных. По ним видно, как менялись требования и сколько раз всё переделывали с хуя на винт.
И вот после всей этой экскурсии у меня в голове складывается картина. Я сразу вижу, где технический долг размером с Эверест, какие модули написаны так, что сам от себя охуел, а где тестов нет вообще, как совести у политика. И уже с этим багажом можно строить план: с чего начинать, что чинить в пожарном порядке, а что можно аккуратно рефакторить, не вызывая волнение ебать у всей команды.