Разобраться с кодовой базой

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

Вот несколько шагов, которые помогли мне:

knowledge sharing по архитектуре
Смысл в том, что разработчик, который несколько знаком с сервисом, верхнеуровнево рассказывает о его процессах, об основных абстракциях, о потоках данных и преобразованиях с ними.
Плюсы таких встреч:
+ Рассказчик во время подготовки и объяснения улучшает свое понимание, обращает внимания на разные нюансы кода.
+ Слушатели узнают про архитектуру незнакомого микросервиса.
+ Тот, кто знаком близко с кодом данного сервиса, может внести правки или подсветить нетривиальные моменты.
В нашей команде была проведена серия таких встреч, и для меня это было чрезвычайно полезно.
Помимо рассказа, коллеги поделились диаграммами и схемами, которые тоже очень сильно помогают продвинуться в понимании .

Вопросы аналитикам
У нас ведется документация, но мне как разработчику часто не хватает полного видения.
Например, начиная разработку, я читаю в спецификации, что микросервис X должен отсылать сообщение в таком-то формате микросервису Y.
Если отправка прошла успешно, то сделать то-то, если вернулась ошибка, то другое.
Я могу просто написать такой код, но я буду знать о нем?
- Буду ли я понимать, для чего нужны сервисы X и Y?
- Что за процесс, для которого требуется отправка сообщения?
- Если мы получили положительный ответ, какие процессы начнутся в сервисе Y?
- Гарантирует ли положительный ответ то, что процессы в Y завершились успешно или лишь успешную доставку сообщения в Y? А почему?
Но найти ответы на эти вопросы в документации зачастую нетривиально. Они могут быть раскидана по разным разделам и страницам.
А поговорив с аналитиком, можно быстро получить информацию.

Конспект
После того, как получаю ответы на свои вопросы, стараюсь по возможности оформить их как конспект и сохранить в документации.
Плюсы такого подхода:
+ Информация лучше закрепляется
+ При необходимости легко вернуться и вспомнить что-то
+ Может быть полезно другим членам команды, особенно при онбординге
+ Сильно сокращает время ознакомления с информацией, т.к. часовое видео можно иногда уместить на пару страниц.

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