Я работаю в онлайн-банке 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 пользователей; никогда не унывать. И не забывать общаться с коллегами, ведь наш “вид спорта” определённо командный :)

Я инженер-программист, работаю в CleverLabs. В основном пишу на руби, но в целом писал но почти всех актуальных языках программирования. Мне нравится ковырять вещи :)

На каком ты сейчас проекте работаешь?

Работаю над приложением для рынка почтовых пересылок. Агрегатор провайдеров, где провайдер на выбор предоставляется пользователю. И трекер посылок, который позволяет видеть жизненный цикл посылки почти-в-реальном-времени. Полгода уже работаю над ним.

Проект состоит из двух ruby приложений и одного мобильного приложения. API — входная точка без базы, на grape. Там находятся зависимости от внешних сервисов. Второе приложение — бэкэнд на rails, построенный на Engines, изолированных друг от друга. Два фронтенда - web и mobile. Vue.js и Flutter для IOS и Android.

Как ты начинал в нем разбираться?

На рельсовой части обычно я сразу смотрю контроллеры, но здесь их нет :) Потому что все находится в отдельных engines, смотрел уже их. Рельсовые модели у нас супер-легкие, без валидаций, только со связями. Для того, чтобы использовать модель, от нее нужно наследоваться и расширять для своих нужд. Соответственно все наследуемые модели лежат в подпапках в моделях. Это наша реализация DDD — не совсем честно DDD, но похоже на то. Получается, что доменные области мы моделируем на основе базы.

А так рельсовые проекты довольно одинаковые. Прежде всего смотрю на контроллеры, затем модели. Еще мне нравится смотреть в папку lib/, где, как правило, хранятся полу-хаки. Такие прикольные штуковины, которые в проекте придумали, и они распространяются на всё остальное. То есть там можно увидеть, что в проекте есть такого нестандартного. Как правило, все расширения стандартного фреймворка уходят в lib/ — вроде переопределений или money-patching. Потом уже смотрю JS, какие-то детали ещё.

Ты стараешься сам разбираться в проекте, или узнаешь у людей?

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

Когда понял, что знаешь проект?

Он довольно маленький, так что когда прочитал весь ruby код.

Есть ли документация в проекте?

Техническая документация только базовая — что используем, что поддерживаем, пару UML-диаграмм. Сам я этим не особо пользуюсь. Оно классно, когда приходишь на проект, а когда проект знаешь — то не сильно полезно.

Что главное при code-review? На что смотришь?

На противоречия. Насколько содержание кода соответствует тому, что в нем написано. И насколько написанное совпадает с тем, как оно работает.

Например, у тебя есть юзеры. Ты делаешь users.map(&:emails), и получились user emails. И часто бывает, что имя результата не то, неправильно описывает результат. Такое бывает на уровне методов, классов, больших конструкций. Чем сложнее структура данных, тем тщательней я смотрю на имена, которые получаются в результате работы с этой структурой.

Вот еще пример: есть юзеры активные, есть удаленные. Если делаешь .filter(&:active), это должно быть active_users, а не filters, или там not_inactive_something. Потому что потом это название может идти дальше вглубь, и будут несовпадения. Или ты передаешь в метод count_users массив employees — что-то явно не так, не совпадает назначение метода, и что ты туда передаешь. И так бывает со всем.

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

Второе это потенциальные проблемы. То есть смотришь на вещи, которые уже сталкивался кучу раз, очевидные для тебя. Например Null safety.

Еще важно смотреть наличие сидов. Чтобы можно было запустить у себя таску и проверить.

Как разбираешься с кодом в pull request'е?

Начинаю со входной точки. Смотрю как данные перетекают, и их весь путь. То есть в контроллер пришли данные, потом в какой-то сервис, там перемололись, отформатировались, ушли обратно.

В быстром код-ревью по порядку быстро просматриваю файлы. Pull request'а посерьёзнее смотрю более детально, использую поиск использований классов на странице. Когда большой pull request, то клонирую код и смотрю у себя

Если я могу вместить код у себя в голове, то можно посмотреть быстро. То есть "считал" pull request, увидел там три файла, то значит смотрю быстро.

Делаешь ли пометки по pull request'у?

Все пометки пишу в pull request. Если есть какой-то вопрос, то пишу сразу комментарий. Но пишу так, чтобы человека не обидеть. Пытаюсь узнать, какие у него были намерения. Например: "Возможно в этом месте нужно сделать create!, потому что дальше мы нигде не делаем проверку на создание". Это нормально работает, люди отвечают. Если что-то сложное, то окей, пойдем обсудим. Но, как правило, хватает комментариев.

Фичей "просмотрено" в GitHub не пользуюсь. Мне кажется, что она бесполезная. Можно, конечно, скрыть какой-нибудь css-файл, чтобы он не мозолил глаза. Но для всего остального не пользуюсь. Не могу скрыть файл, потому что часто ищу использования классов, и со скрытием поиск по странице не работает.

Смотришь ли на задачу?

Зависит от pull request'а. Если он маленький, то не смотрю. Но если в нем файлов 10 и больше, то смотрю. Есть определенная граница, по которой я отсекаю простые ПР, на доверии автору. В маленькой задаче не в чем ошибиться, в большой уже больше деталей, и нужно смотреть.

Есть прикольная практика, когда разработчики записывают видео результата. "Вот такая задача, вот так она была сделана". То есть тебе не нужно идти на UI и париться, работает ли это вообще концептуально.

Насколько часто ты клонируешь код pull request'а?

Где-то 15% pull request'ов клонирую. Как правило, задачи — это эпик, который разбит на таски. Сами задачи маленькие, и смотреть код по ним просто. Но задачу, которая объединяет компоненты, точно нужно клонировать, даже если смотрел код до этого. Потому что бывает проблемы интеграции разных частей кода, какие-то данные не перетекают куда нужно, например.

Очень важны в ревью пробелы :). Чем больше отступы — тем больше вложенность. Есть такая шутка, что людям нравится писать вложенный код, потому что есть врожденная любовь к пейзажам гор :)

Что используешь для чтения кода?

В основном читаю код только в Sublime text. В нём есть классный поиск, который стабильно работает.

У гита есть глобальный конфиг, и глобальный .gitignore. У меня в таком глобальном .gitignore прописана папка _knowledge_base, в которой я храню всякую информацию по проекту. Такая папка у меня есть в каждом проекте. В неё уходит вся инфа, которая не вошла в readme или wiki, и которая потом может пригодиться.

Как смотришь Open source проекты?

Первым делом readme. Затем скорее всего вики. Есть два типа OS — заматеревшие, у них читаю официальные и иногда даже независимые вики. Вторые - молодые, с нестабильным API. В них читаю документацию. Но когда этого не хватает — то уже лезу в код.

Бывает такое, что в readme описывает базовые примеры, а вики описывает уже частные случаи. Например во flutter в каждом проекте есть папка examples, и в ней описаны готовые базовые использования этой библиотеки.

А как читаешь код Open source проектов?

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

Иногда в проекте есть публичный API, а есть "хитрый" публичный, не задокументированный. Он как бы есть, но может в любой момент отвалиться. И всегда тут нужно решать: "а могу ли я использовать?".

Для кода самое простое — склонировать репозиторий. Клонирую, и начинаю идти "вверх" от того, что мне нужно.  А потом оттуда снова иду "вниз". "Вверх" — это во входную точку. Чтобы понять, где начинается выполнение кода, и какие данные наслаиваются к конечному моменту. Чтобы увидеть весь граф зависимостей как бы от информации.

Рисуешь что-нибудь на бумажке?

Постоянно. Если вложенность больше, например, пяти. На свежий могу держать в уме больше абстракций, но в конце дня нужно уже чаще записывать на бумагу для нормального понимания. Самое классное, это когда я пишу какие классы со входными данными. Но бывает, что хватает просто цепочки вызовов функций. И иногда приходится писать зависимости, например для Dependency Injection.

Как выбираешь NPM-пакет или Gem

Прежде всего я смотрю, могу ли я его не использовать.

На этапе прототипирования (для MVP например) - беру пакет ближайший, который попался и работает. По мере развития уже смотрю, насколько я этому пакету доверяю.

На доверие влияет дата последнего комита, но не всегда — иногда пакет один раз сделали, и он работает, на удивление без изменений. Это редко, но бывает. Смотрю так же открытые issue, pull request'ы. Смотрю на сам код, насколько он банально "опрятный". Если в библиотеке подключен хотя бы какой-нибудь code linter, то это уже классно. Значит создатели немного заботятся о том, что происходит, хотя в идеале должен быть работающий CI. Если все соблюдается — значит это нормальный пакет.

Иногда я могу почитать, и быть несогласным с архитектурой библиотеки. Но это окей, если сам по себе код чистый.

Насколько часто смотришь на чистоту библиотеки?

Есть пакеты маленькие, типо GitHub клиента octokit. А есть большие, например devise. Весь devise я не посмотрю, хотя впоследствии я уже знаю, что он так себе. Но т.к. это де-факто стандарт, все его знают, и он быстро добавляется в проект, то я его использую. А если библиотека какая-то небольшая, то его можно посмотреть уже саму.

Иногда я просто создаю main.rb файл, пишу inline bundle (таким образом гемы ставятся в папку проекта), пытаюсь что-нибудь накидать. Смотрю как это смотрится в плане моего взаимодействия с библиотекой, насколько мне комфортно. Бывает такое, что у тебя есть какой-то гем, он норм работает, но у него ужасный интерфейс. Например метод возвращает результат в виде "error23", и ты вообще не понимаешь, что это за ошибка, и почему 23.

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

Чего тебе сейчас не нравится в чтении кода?

Когда коменты на китайском :) В проекте мало чего не нравится, потому что есть rubocop, он более или менее стандартизирует. Иногда не хватает описания предположений, которым придерживались люди, ушедшие из проекта. Бывает такое, что ты не понимаешь, почему какие-то решения на каких основаниях были сделаны. Этого не хватает.

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

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

Мне нравится, чтобы в итоге получался такой код, при виде которого я понимаю, почему он так написан.

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

Есть интересная идея от Shopify. У них таски не слишком большие, и когда человек пишет код, первый раз реализовывает, потом делает git reset --hard, и пишет её с нуля. То есть с контекстом ты смотришь на реализацию более аккуратно. Иногда я так тоже делаю.

Я Full-stack Ruby on Rails разработчик. Код пишу уже 8 лет, начинал с .NET, потом перешел на Ruby. Сейчас я работаю в CleverLabs, над проектом в сфере медицинского страхования США. На проекте уже чуть больше двух лет. С технической стороны используем Ruby on Rails на бэкенде и React на фронте.

С чего начинал, когда пришел на проект?

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

Начинать нужно именно с такой беседы. А потом нужно взять мануал/ридми по тому, как настроить проект. Он реально облегчает жизнь человека в 1-2 день.

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

Порядок такой:

1. Gemfile — за несколько лет опыта работы половину гемов в новом Gemfile я уже точно знаю;
2. Конфиги, initializer'ы;
3. Схему БД можно просто проскролить, там слишком много всего;
4. Модельки, их неймспейсы, какие-то общие детали.

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

Насколько сложно было понимать код?

Нормально было. Мозолила глаза немного стилистика. Например, ограничение длины строк, которого в этом проекте не было, или какие-то непривычные правила rubocop. А в бизнес-логике нормально — пришел, посмотрел, понял.

У тебя есть понимание того, что ты знаешь весь проект?

Нет, но я могу сказать, что субъективно знаю половину проекта. Есть части, в которых я вообще не шарю. Но если мне нужно в них разобраться, то я прежде всего разговариваю с людьми, узнаю у них информацию о коде и логике работы. Если нет людей, которые знакомы с кодом, то все равно есть те, кто знаком с бизнес-логикой — product-owner'ы, менеджеры. А тем более тестировщики — они обычно очень хорошо знают логику работы продукта.

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

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

Как смотришь pull request'ы?

Если максимальный уровень внимания, с пристрастием, то начинаю с изменений в базе. Потом в модельках — они должны совпадать. Затем сервис, в котором вообще никакой другой сервис не используется, то есть самый вложенный. Посмотрел его, посмотрел на него тесты, свернул. Потом посмотрел, где сервис используется, посмотрел на это спеки, свернул. Получается снизу вверх посмотрел все сервисы. Обожаю сворачивать просмотренное в GitHub. А чтобы его сделать, то нужно быть уверенным, что посмотрел все вложенности. Потом смотрю вьюхи, потом JavaScript. В JavaScript тоже с самого вложенного удобнее смотреть.

У нас сейчас такое количество ПР, что ты либо выборочно смотришь, либо поверхностно. Так, чтобы код скачать — это единичные случаи. Если какой-то pull request затрагивает незнакомый модуль, то могу посмотреть общие вещи, стилистику, и влияние на то, что я знаю. Например, есть ли изменения на глобальные сущности. Мне нравится такой подход, что если ты смотришь pull request — то ты смотришь код, а тестировать должен QA. Это время.

Насчет спеков: смотрю их вместе с сервисами только если хочу спеки посмотреть. Чаще я просто проверяю, что в спеках было протестировано то, что написано. И чтобы не было лишних create'ов в базу — производительность :)

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

Смотришь ли на таску при ревью?

Таску смотрю нечасто, но бывает. Иногда понятно и так, а иногда непонятно написано описание ПР, название, или название комита. В день где-то 8-10 pull request'ов, и как минимум один раз при просмотре таску открываю.

Во время code review нормальная тема подойти к человеку и спросить, что здесь происходит. Мне приятнее пойти спросить, если я что-то не понимаю, чем написать комментарий. Особенно если в комментариях начинается диалог большой, то лучше брать и созваниваться. Переписка в комментариях очень плохо работает.

Рисуешь что-нибудь при просмотре?

Нет, обычно всё в голове удается держать. Только очень редко при проектировании — последний раз рисовал месяц назад. Это были временные схемы, нужно было смотреть перекрытие по датам биллингов, всякие временные интервалы. А так редко рисую.

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

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

Еще нравится смотреть pull request на maintenance. Это вообще все должны смотреть, потому что там всякие фишечки появляются, которые всех касаются. Это полезно, можно иногда прокачаться.

Еще нравится в pull request находить интересные приёмчики, которые потом сам начинаешь использовать. Последний раз вау-эффект был, когда узнал, что в в руби в блоке можно использовать нумерованные аргументы. Я этого раньше не знал, и узнал благодаря просмотру одного pull request'а.

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

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

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

Open source

OS можно сказать, что не смотрю. Только смотрю, если оно используется в проекте, и это касается моей таски.

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

С чего начинаешь просмотр гема?

Если я дебажу, то я просто залажу туда, куда меня отправляет входная точка. А если мне просто нужно посмотреть гем, то все начинается с gemspec. Потом входной файлик в lib/название_гема.rb. И там уже список require, его можно уже смотреть дальше.

Когда ищешь новый гем, как ты выбираешь?

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

На качество кода внутри плевать, главное чтобы он нормально работал. Это как инкапсуляция — тебе без разницы что внутри. Если он супер неоптимизированный и поэтому медленный, тогда ты его не будешь использовать. Но если там просто тысяча строк в одном файле — ну пацанам удобно наверное так, окей. Что тут сделать.

Если разница между подключением npm пакета или ruby gem'а?

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

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

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

А еще лучше общайтесь голосом — переписка это всегда медленно. Этого нельзя стесняться.

Привет! Я 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 этой части.

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

Возможно дело в том, что это довольно сложно формулировать. В основном люди читают интуитивно, начиная с той части, где появилась ошибка, либо со входной точки. Как-то не особо интересно, да? Но явно есть те, у кого выстроена система чтения, с порядком, приоритезацией, своими фишечками и инструментами. Возможно кто-то забивает и вообще не читает чужой код 🤷‍♂️.

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

• разбор новых рабочих проектов;
• чтение пул реквестов;
• разбор open source;

Если тебе тоже интересно узнать, насколько серьезно другие люди смотрят пул реквесты, какие фишечки используют при чтении, и как быстро вливаются в новый проект - welcome! В ближайшее время начну публиковать интервью с разработчиками. Stay tuned!