Как вы читаете чужой код? (legacy)

Вкатываюсь в легаси путем закрытия задач: фиксенья багов и имплементации новых фич. Постепенно понимаешь то в одном, то в другом месте, как что где работает. Иными словами, через практику. Проверено на разных стеках, разных размерах, как и коммерческие, так и OSS. Просто так чтение кода лично для меня не работает в качестве вкатывания в проект/легаси. Но при этом могу и ногда "полистать" чужой код на гитхабе, чтобы посмотреть, как другие пишут, подметить какие-то фишки, стиль.

😱 Комментарий удален его автором...

Примерно в таком порядке:

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

Для меня самая боль — это легаси код с кучей абстракций. От людей, которые обчитались всякого про DRY и SRP, но поняли это все так странно, что вся логика размазана мелкими мазками по всему проекту и никак не складывается в логичную историю. По сравнению с этим код в процедурном стиле с методами по несколько тысяч строк читается легко и запросто рефакторится.

Нередко приходится читать код сквозь слёзы…

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

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

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

старт -> получение данных из Х (тут список полей) -> условие - получение данных из У (список полей) -> завершение; иначе -> модификация -> возврат данных.

без каких-либо конвенций типа UML, просто как мне удобно.

С трудом :D

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

Сначала можно почитать https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Она слегка opinionated, но все равно, есть что оттуда надергать из подходов.

Во-вторых, читать надо активно. То есть либо строить схемы какие-то (что как с чем соотносится) либо рисовать какие-то code flow, чтобы понимать как идёт исполнение. В итоге у меня на новых проектах обычно есть пачка каких-то схем, от разных точек входа (например, отдельно для запросов юзера, отдельно для старта приложения и тд и тп)

В-третьих, я стараюсь плюс-минус активно ломать свои догадки. То есть вижу и думаю что-то "ага, я думаю что аргумент XXX тут для того, чтобы потом вот здесь использоваться как YYY". После этого либо меняю код в ХХХ так, чтобы он сломался в YYY, либо пишу маленький кусок рядом, чтобы посмотреть и тд.

В целом я стараюсь избегать начинать знакомство с проектом с чтения кода в пользу большей практики:

• осознаю для себя, какую задачу решает этот проект, и какие задачи он не решает
• разбираюсь как деплоить проект
• настраиваю IDE/редактор для разработки/отладки, нахожду точку входа, иду с нее по шагам, или беру какое-нибудь пользовательское действие, нахожу код, который за него отвечает, ставлю breakpoint и прохожу несколько шагов, чтобы посмотреть, что в этом участвует
• читаю документацию, дописываю документацию о том, что я узнал про задачи и деплоймент (как правило то что есть уже слегка устарело)
• понимаю, как запускать тесты, запускаю, и, если это не выглядит неподьемным, пытаюсь починить те тесты, которые фейлятся
• пишу какую нибудь небольшую фичу/чиню баг чтобы начать разбираться в проекте
• участвую в митингах, связанных с проектом, и задаю глупые вопросы

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

Что работает

• Что в фундаменте. Ни один код не пишется целиком с нуля за редким исключением.
• Если фреймворк самописный спросите новых коллег у кого про него спросить или где почитать.
• После этого уже приступайте к изучению.

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

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

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

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

Потому иду итерациями

• работает? хорошо если да
• работает как должно?
• тесты есть?
• работают как должны?
• пошли разбирать код по исполнению с записями
• рефакторим/меняем
• добавляем комменты
• повторяем сначала

Если читать код просто чтобы ознакомиться с проектом, то я предпочитаю начинать с точки входа (main функция/метод или что там еще в других языках)
Помогает понять из каких компонентов все состоит, как они конфигурируются и т.д.

Ну как бы для чего именно мне надо читать это легаси?

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

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