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

Я работаю в онлайн-банке N26 два с половиной года. Должность — tech lead. Работаю в команде Identity, занимаюсь реализацией различных методов аутентификации.

Изначально я backend-разработчик, в основном использую java и kotlin. Половина моих проектов – это функционал, который видит конечный пользователь, а другая половина – это решения, которые используют другие backend-команды. Раньше я 90% времени писал код, а сейчас больше занимаюсь архитектурой.

Сложно было разбираться в проекте?

Было непросто. На тот момент компания была намного меньше, и стандарты были другие. Это был скорее стартап. Люди меньше думали о том, что впоследствии множество других разработчиков будет читать их код. Кроме того, в стартапе зачастую важна скорость – она в приоритете над документацией.

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

У нас в компании такой процесс, что при создании нового или значительном изменении текущего функционала, команда сперва подготавливает документ, описывающий проблему и её решение – RFC. Далее документ открывается для комментариев другим командам. Зачастую инженеры из других команд, которые уже сталкивались с подобными проблемами или решениями, дают полезные советы и указывают на слабые стороны. В итоге это помогает улучшить проект ещё на этапе проектирования. Обычно я начинаю изучать новый проект именно с RFC.

Как разбирался в коде проекта, когда пришёл?

Применял "ленивый разбор кода". Допустим, мне нужно реализовать какой-то функционал. Я погружаюсь в проект настолько, чтобы решить конкретную текущую задачу, и не стараюсь объять всё и сразу. Как правило, новые инженеры начинают с небольших задач, и постепенно переходят к более объёмным и комплексным. Как говорил мой заведующий кафедрой, “слона нужно есть по частям”.

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

Если случилась ошибка, ты смотришь в логи, или сразу начинаешь дебажить?

Предупреждения о том, что что-то сломалось, базируется на метриках. Например метрика 500 статус, или latency на каком-то endpoint'е. Я сразу иду в логи и смотрю, какой именно endpoint валится. Обычно ошибки возникают из-за изменений, которые были добавлены недавно. Смотрю что изменилось, смотрю сервисные логи, exception'ы. В большинстве случаев rollback решает проблему.

Как у вас организован код-ревью?

У нас pull request'ы обычно ограничены до 20 файлов. Хотя это довольно много, идеальный pull request — это 5-10 файлов, ведь человеку сложнее обрабатывать большие объёмы информации, это занимает много времени – и ревью откладывают. Я бы не сказал, что этот лимит сильно ограничивает — он скорее заставляет задуматься о том, как можно сделать задачу итеративно. Понятно, что проект большой, и при реализации нового функционала ты часто изменяешь более 20 файлов. Но когда это делается итеративно, то шанс ошибки намного меньше, и смотреть такие pull request'ы проще.

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

В каждом сервисе есть code owners – доменные эксперты. Например, моя команда ответственна за 4 сервиса. Микросервисы упрощают разделение обязанностей, это их большой плюс. И когда ты смотришь pull request, то знаешь, что это за сервис, и что он делает. Обычно начинаю с чтения описания. Описание не всегда развёрнутое, но порой достаточно даже хорошего названия pull request'а — и у тебя есть контекст.

В каком порядке смотришь pull request?

Обычно я сперва бегло просматриваю содержание, чтобы понять контекст и общую картину изменений, а потом иду просто по порядку, который есть в GitHub. В pull request'е смотрю всё. Стараюсь смотреть глубоко, досконально его изучить и понять. Если я смотрю pull request, то этот код мне скорее всего предстоит поддерживать, а значит мне нужно знать функционал. Смотрю класс, что он делает, как его протестировали, как код работает в нормальном сценарии, как код работает в corner case'ах, как бы я это реализовал. Сложно недооценить тесты, так как сразу после merge код заливается в live, и отсутствует шаг мануального тестирования.

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

Пользуюсь классной функцией в GitHub, когда можно отмечать просмотренные файлы. Я обычно начинаю с классов с наименьшим количеством зависимостей, поэтому у меня нет проблем с поиском использований. В среднем на ревью трачу 15-30 минут.

Как смотришь pull request в незнакомой части кода?

Процесс организован так, что я в основном смотрю pull request'ы в своих сервисах. Там редко встречаю незнакомый код. Когда работаешь с одними и теми же сервисами, то процесс ревью проходит быстрее и качественнее.

Клонируешь pull request?

Для тестирования не клонирую. Совсем изредка скачиваю ветку и смотрю её в IDE, чтобы проследить последовательность вызовов. Но учитывая, что размер pull request’ов не такой большой, нужды в этом как правило не возникает.

Что делаешь, если не понимаешь pull request?

Я – сторонник того, чтобы сначала попытаться разобраться самому. Если мне что-то кажется странным, нелогичным или неправильно работающим, то я пишу комментарии в pull request, и почти никогда не обсуждаю pull request’ы лично. Это отвлекает, и в конечном итоге просто тратит времени. Я за асинхронное взаимодействие :) Я считаю, что это очень важный атрибут продуктивной работы инженера.

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

Что не нравится во время просмотра pull request'а?

Когда люди пишут что-то неоднозначное, и при этом не оставляют объяснений. Но ничего критичного: это код, и во всем можно разобраться.

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

А что нравится?

Нравится, когда создатель pull request’а заботится о коллегах, которые будут его просматривать – добавляет описание, оставляет релевантные ссылки. Как правило, от этого выиграют обе стороны – такие pull request’ы просматриваются быстрее и эффективнее.

Разбираешь open source проекты?

Иногда приходится, так как мы активно используем open source фреймворки и библиотеки. Но так как мы – банк, то нельзя просто подключить случайную библиотеку из интернета, сперва она должна пройти определённую проверку.

С чего начинаешь смотреть open source код?

Прежде всего начинаю с документации. В идеальном случае мне не нужно идти в код. Если всё-таки идти в код приходится, то начинаю изучение с тех классов, которые непосредственно используются в проекте. Смотрю на точку входа, на метод создания класса, на внутренности, на зависимости. Если возникла проблема с open source инструментом, то я обычно начинаю с поиска по issues на GitHub, а так же смотрю changelog.

Какие диаграммы используете для документирования?

UML, наиболее часто используем диаграмму последовательностей. Еще мы используем классный тул plantuml – диаграммы в виде кода. Также используем C4 model.

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

В целом документация помогает изучению проекта. Возможно, избыток документации – это так же плохо, как и недостаток, но с избытком я пока не сталкивался :) Зачастую причина в том, что поддержка документации – это серьёзная статья расходов времени. Чем больше документации, тем больше времени занимает её поддержка.

Чего тебе не хватает при чтении кода?

Иногда не хватает фокуса. Я вовлечен во многие обсуждения и технические процессы, поэтому меня довольно часто дёргают в slack. Приходится как-то "изолироваться". Например у нас в команде есть договоренность, что первая половина дня полностью свободна от митингов. Кроме того, slack я стараюсь проверять не чаще, чем раз в полчаса.

Что тебе больше нравится — читать или писать код?

Писать. Полагаю, большинство инженеров предпочитает писать код, нежели читать. Но читать код и разбираться в нём – это такая же часть работы, и как минимум не менее ценный навык. Я стараюсь в этом постоянно совершенствоваться. С практикой скорость чтения увеличивается.

Какие у тебя есть рекомендации?

Быть требовательным в первую очередь к себе, с уважением относиться к коллегам, быть прагматичным, стараться реально оценивать текущие потребности проекта и потенциальный рост; понимать, на какой scale ты пишешь код, и не пытаться слепо копировать все новомодные практики больших компаний, если у тебя сейчас 20 пользователей; никогда не унывать. И не забывать общаться с коллегами, ведь наш “вид спорта” определённо командный :)