Каковы ваши первые шаги при вхождении в существующий проект?

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

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

План действий, или как не облажаться сразу

1. Контекст — это всё, ёпта. Сначала читаю всё, что шевелится. Документацию, если она есть (ахаха, смешно, но вдруг). Архитектурные решения (ADR) — чтобы понять, почему тут такой пиздец, а не красота. И доску задач (Jира, ЮТрек — неважно). Смотрю, чем народ сейчас мается, какие баги всех ебут, и что в бэклоге висит как дамоклов меч. И процессы команды — как они тут мержи делают, в какую ветку хуярить, кто ревьювит. Чтобы не прийти с «ой, а можно я сразу в мастер?».

2. Поднять локально и запустить. Беру проект, пытаюсь собрать. mvn clean install или gradle build. Если всё прошло с первого раза — подозрительно, блядь. Значит, окружение у них не кривое. Потом запускаю ВСЕ тесты. Если они все зелёные — ну, просто праздник какой-то. Если половина красная — вот это уже реалистичнее. Запускаю само приложение. Если оно взлетело и не сожрало всю оперативку — уже хорошо. Если на localhost:8080 хоть что-то отвечает — вообще красота.

3. Ковыряемся в коде, как в носу. Ищу точку входа. Ну, этот самый main-метод, откуда всё начинается. Обычно это какой-нибудь класс с @SpringBootApplication.

   // Вот эта штука, которая всё и запускает. С неё и начинаем копать.
   @SpringBootApplication
   public class Application {
       public static void main(String[] args) {
           SpringApplication.run(Application.class, args); // Магия начинается тут
       }
   }

   Потом смотрю, как всё устроено: где контроллеры, где сервисы, где репозитории. Ищу конфиги, особенно всякие application.yml — там часто вся соль и спрятана. Смотрю на стиль кода: как называют переменные, как форматируют. Чтобы не написать потом mySuperVariable, когда все вокруг пишут user_dto, и не получить в ревью комментарий «чё за хуйня?».

4. Первая задача — не геройствовать. Выбираю самую мелкую, нестрашную задачку. Поправить опечатку в логе, добавить одно поле в ответ API, пофиксить очевидный баг, который уже описан. Не лезу сразу в ядро, не пытаюсь переписать их любимый legacy-сервис. И самое главное — задаю вопросы. Не сижу три дня, уставившись в монитор, как идиот. Лучше выглядеть немного тупым, но спросить, чем быть уверенным мудаком и наворотить делов.

5. Когда немного вьехал — можно и своё говно добавить. После пары успешных коммитов, когда перестал путать, где что лежит, можно предлагать улучшения. Но не «всё переписать на Реакт»! А по-нормальному: «Я тут заметил, что у этого метода нет тестов, давайте я напишу», или «Документация к этому API устарела, обновлю», или «Метод на 300 строк, может, разобьём?».

Главный принцип, блядь: Сначала пойми, как тут живут, и встройся в их танец с бубном. Не лезь со своим уставом в чужой монастырь. А когда уже стал своим — тогда можно аккуратно предлагать, как сделать танец чуть менее идиотским, но с аргументами, а не просто потому что «мне так нравится».