Систематизирование процесса изучения чужого кода
middle_java#software #development
Поменял работу. Работаю теперь в заказной разработке в компании Innovative People.
Новая команда, новые проекты, вникаю в существующий код.
Хочу поделиться своими подходами, которые помогают систематизировать процесс изучения чужого кода:
0. Делаем так, чтобы приложение компилировалось. Устраняем конфликты с репозиториями зависимостей (например переключить с локальных репо на Maven Central, предоставить аутентификационные данные для подключения к локальным репо), устанавливаем нужные версии JDK, фреймворков и библиотек.
1. Чекаутим самые первые коммиты, смотрим с чего все начиналось. Если сервис писался с нуля, то в первых коммитах обычно мало кода и представлены в основном контракты методов, код не перегружен деталями реализации и обработкой corner-кейсов. Легко понять задумку автора и структуру приложения.
2. Изучаем коммиты в привязке к аналитике. Сопоставляем реализацию с изначальными требованиями из аналитики: Как реализовано? В каких классах? Как конфигурируется? На этом этапе также используем историю редактирования страниц аналитики, в Confluence например есть функционал перемещения по истории редактирования страницы: можно увидеть связь между изменениями требований и изменениями в коде.
3. Находим точку входа в приложение. Ищем аннотации и методы указывающие на старт приклада и его начальное конфигурирование: @SpringBootApplication, @RestController, @ComponentScan, @ServletComponentScan и др. Найдя точку входа, двигаемся по потоку исполнения, раскручивая цепочку. Например нашли аннотацию @RestController, внутри нашли @RequestMapping, внутри перешли в сервис, там валидация, трансформация, дальше в DAO и обратно.
4. Изучаем конфигурационные файлы, из них мы поймем функционал сервиса и его техстек. Например, увидим, что приложение использует IBM MQ, Kafka, MongoDB и т.п. На этом этапе для нас интересны аннотации @EnableAutoConfiguration, @Configuration, @PropertySource. Также смотрим какие enabler'ы используются в Spring Boot приложении: @EnableKafka, @EnableJms, @EnableWebMvc, @EnableScheduling, @EnableTransactionManagement и др. На этом этапе можно попробовать локально запустить код, если не нужно много времени тратить на интеграционную обвязку.
5. Составляем таблицу используемости методов и классов. Чем больше количество usage – тем приоритетней сущность для ознакомления.
6. С чужими комментариями в коде надо быть осторожнее - они быстро устаревают и за их актуальностью обычно не следят. Однако, они расскажут, что задумывалось *когда-то*, что несомненно вам поможет.
7. В процессе анализа расставляем прямо в коде свои комментарии и вопросы (только не коммитьте их, это чисто инструмент для вашего понимания)
8. Открываем бэклог и закрытые спринты и изучаем тикеты на разработку и на багфиксы – в хронологическом порядке. Сопоставляем с теми изменениями которые были сделаны в коде в рамках выполнения этих тикетов.
9. Рисуем архитектуру на большом листе, чтобы всё было перед глазами – распутываем клубок от точки входа, от внешних интерфейсов, от листенеров Kafka, JMS и т.п. до формирования и отправки ответов, сохранения в БД, передачи данных в инструменты логирования, мониторинга, трейсинга и др.
Другими словами, выделяем компоненты и рисуем связи между ними.
Компоненты можно разделять по-разному:
-- по назначению (API для фронта, межсервисный интерфейс и тп)
-- по слоям приложения (дао, сервисы, утилиты, конфиги, модель и тп)
-- по длине одного блока: длинный непонятный метод разбить на несколько более мелких. Это уже элемент рефакторинга, не только чтения кода.
10. Чисто для себя можно зарефакторить части кода: например, если не понятны аргументы ссылки на метод, то можно раскрыть его в лямбду, а то и вообще до анонимного класса (но оставлять так не следует).
11. Активно пользуемся инструментами Git и IDEA. В частности щелкнуть правой кнопкой мыши (ПКМ) на номерах строк в редакторе кода и выбрать пункт Annotate - чтобы узнать давность коммита и автора фрагмента кода. Теперь мы знаем кому задать вопрос по конкретному блоку.
12. Также полезны следующие инструменты IDEA:
-- ПКМ на сущности (например методе) -> Analyze -> Data Flow To Here / From Here,
-- UML sequence diagram plugin,
-- Иерархия типа: ctrl+H,
-- UML иерархия (ctrl+alt+U),
-- Все виды поиска в Идее: ctrl+shift+F, ctrl+shift+N, ctrl+shift+C
13. Изучаем работу тестов: как изолируются компоненты, как подготавливаются исходные данные, как создаются и инициализируются компоненты, usecases использования методов и т.п.
Прошу вас поделиться своим опытом в изучении чужого кода, потому что, как мне кажется, тема актуальная и я многое мог упустить.
t.me/middle_java @middle_java