Привет, Андрей! Расскажи пару слов о себе
Я Full-stack Ruby on Rails разработчик. Код пишу уже 8 лет, начинал с .NET, потом перешел на Ruby. Сейчас я работаю в CleverLabs, над проектом в сфере медицинского страхования США. На проекте уже чуть больше двух лет. С технической стороны используем Ruby on Rails на бэкенде и React на фронте.
С чего начинал, когда пришел на проект?
Самое важное для нового человека на проекте — это в первую очередь взять коллегу, который уже работает и разбирается. Чтобы он нарисовал схемки, объяснил что где, какие где конфиги смотреть, архитектуру, бизнес-идею. Потому что одному разбираться намного менее эффективно, чем если коллега тебе взял и рассказал. Важно рассказать главные вещи, а в подмодулях человек уже сам может разобраться.
Начинать нужно именно с такой беседы. А потом нужно взять мануал/ридми по тому, как настроить проект. Он реально облегчает жизнь человека в 1-2 день.
С чего начинаешь смотреть код?
Порядок такой:
- Gemfile — за несколько лет опыта работы половину гемов в новом Gemfile я уже точно знаю;
- Конфиги, initializer'ы;
- Схему БД можно просто проскролить, там слишком много всего;
- Модельки, их неймспейсы, какие-то общие детали.
В сервисы вообще в начале не залажу. Открываешь папку сервисов, а там куча файлов — непонятно что смотреть, непонятно что будет нужно при работе.
Насколько сложно было понимать код?
Нормально было. Мозолила глаза немного стилистика. Например, ограничение длины строк, которого в этом проекте не было, или какие-то непривычные правила 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'ы — всегда удобнее смотреть маленький комит в истории. Надо заботиться друг о друге :)
А еще лучше общайтесь голосом — переписка это всегда медленно. Этого нельзя стесняться.