Владимир Пенязьков — Full-stack developer @ Colada

Привет, Вова! Расскажи немного о себе и о текущем проекте

Привет! Я Full-stack developer, работаю в основном с JavaScript и Java. Сейчас работаю в Colada, делаем проект в сфере event management.  Стек технологий такой: фронтенд — react+typescript. На бэкенде — java, kotlin, vertx, микросервисы.

С чего ты начинал разбор последнего проекта?

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

Начал с фронтенда, потому что было больше опыта с ним. Так как представлял, как работают проекты на React, то было проще разобраться. Было просто разбираться из-за понятной структуры проекта. Пока не наткнешься на generic шутку, которая по каким-нибудь динамическим схемам строит таблицы — там ад. В таких случаях находишь отправную точку, например контейнер, и начинаешь разворачивать — что он там делает, какие компоненты использует. Так как обычно в таких случаях ищешь проблему, то начинаешь поиск как раз с нее — находишь какой-то handler и дальше пытаешься разобраться и дебажишь. Но обычно по коду все понимаешь как оно себя ведет.

Потом уже новая фича. Когда реализовываешь с нуля почти фичу, то проще влиться. Как-то так само получилось, что я во много определил подходы на фронте. Я начал как раз тогда, когда в React появились хуки. И было решено, что мы будем писать на них, хотя старые компоненты остаются по-старому. Поэтому и разобраться было проще — не было большой базы кода и common-компонентов.

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

Когда разбираюсь с кодом, то обычно я сам смотрю код, а у коллег спрашиваю когда прямо вообще нет идей. Задаю вопросы по непонятным или узким частям кода — например как-то было непонятно, как реализован кодек (сериализация) на MongoDB.

Обучение написания в стиле проекта еще проходило по пул-реквестам. Я что-то делаю, а потом в пул-реквесте коллеги говорят что так и что не так. До этого я использовал немного другой подход организации кода и пришлось учиться писать иначе — где писать бизнес-логику, как делать структуру классов и слои абстракции.

Понятная структура у проекта?

Так как код спроектирован однообразно, то я один раз разобрался, и дальше довольно просто дальше писать и читать. Но это хороший проект. До этого тоже были проекты с понятной структурой, например с трехслойной структурой доступа к базе. Но были и проекты без структуры, тогда при чтении нужно было уделять больше внимания — тут большую роль играет команда и люди, которые его поддерживали. Сейчас у нас микросервисы, и на каждом мы придерживаемся одинаковой структуры. Как минимум в каждом из них три первых папки всегда одинаковы — application, domain, infrastructure.

В какой момент ты понял, что разобрался в проекте?

Сложно определить эту точку. На фронте и на бэкенде получилось по-разному. Так как большой готовой базы на фронте не было, то получилось быстро - больше писал сам, чем разбирался. А на бэкенде когда написал парочку фич и endpoint'ов с разной функциональностью. Но не очень быстро, около полугода, наверное, до "полного" понимания.

В целом разбор нового проекта идет так — багфиксы, потом какие-то новые фичи по аналогии с существующим.

А как сейчас смотришь влияние отдельного компонента остальные части системы?

В основном просто поиском использования. Прохожу просто по всем местам. Так же очень помогает типизация. Плюс иногда тесты — это своеобразная документация, но смотрю тесты на самом деле редко. Возможно потому что у нас не TDD и тесты не так информативны 🤷‍♂️.

Так же есть описание REST API, и есть async API.  Есть изменения, которые влияют на API, и которые не влияют. Если влияют, то зависимости можно смотреть по использованию enpoint'а в случае REST API, или эвента, на которые подписываются сервисы, в случае async API. Сами интерфейсы эвентов мы редко меняем, поэтому все довольно просто.

Как ты смотришь пул-реквесты?

Самое главное — это его заголовок :) По названию и репозиторию ты понимаешь в большинстве случаев о чем идет речь. Так же смотрю на лейблы - мы ими помечаем то, какие пакеты в проекте затрагивает пул-реквест. И обычно этого хватает для понимания того, что будет в коде. У нас не принято делать описание для пул-реквеста, и если не понятно из названия о чем он, то смотрю задачу.

Дальше все зависит от настроения и размера пул-реквеста. Стараюсь по порядку (как представлено в GitHub) смотреть файлы. Если возникают вопросы организации методов и аргументов — то начинаю смотреть использование. Активно пользуюсь фичей пометки просмотренных файлов в GitHub.

Просмотр файлов зависит от того, что за классы в нем. Смотрю внимательней, если код или домен знакомый. На что стоит обратить внимание понимаю по содержимому файла.

Пометки при код-ревью не делаю. Если есть вопросы — обычно оставляю комментарии, или сразу спрашиваю у человека.

Как смотришь те части кода, в которых не разбираешься?

Обычно логически понимаю в зависимости от кода и места использования. Если нет — начинаю разбираться по репозиториям проекта.

Например когда смотрю пул-реквест на фронте, а связанные с ним изменения на бэке до этого не видел, то чаще всего понимаю код и без знания бэка. У нас стандартизированная структура API, поэтому из названия понятно. Плюс структура данных все равно описана на фронте — на typescript написаны интерфейсы.

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

Ориентируешься ли на документацию?

Документацию мы пишем очень редко, поэтому в проекте скорее нет. Мы как-то пробовали внедрить ADR. Для некоторых фич это делали, но пока не обширно.

Так же в проекте есть несколько диаграмм, и недавно снова начали добавлять новые, работаем в этом направлении :) Но на них смотрю редко, так как они покрывают другую часть проекта, которой я редко занимаюсь.

Расскажи о том, как смотришь open-source проекты

Open source проекты нечасто разбираю. Код обычно смотрю на GitHub. Смотрю папки, как организованно всё.

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

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

Так же влияет гибкость пакета и простота. Например, если я ищу пакет для React, а сам пакет написан прежде всего для jQuery и с React плохо работает — то лучше не брать. Качество API и кастомизация — важно. Но в репозиторий почти не захожу, чтобы прямо код смотреть. Документация влияет и примеры.

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

Используешь ли диаграммы?

UML изредка пользуюсь, например недавно делал sequence diagram. Но стандарту не следую, просто принцип использовали. Еще использовали графовые диаграммы для Neo4j, было удобно смотреть для понимания.

Что бы ты хотел посоветовать людям?

Я за маленькие pull-request'ы. Делайте маленькие PR! Еще стоит не для галочки PR ревьюить, а осмысленно их смотреть – там могут быть баги :) Особенно если ты code-owner этой части.