Как я научился делать мир лучше в HeadHunter
До того, как я пришел в HeadHunter, я не знал, что такое code review. Я знал, что такое code approval — так было в одной американской компании, где я начинал свою карьеру, и где весь код в проекте проходил перед мудрыми глазами профессора Фортрана за столиком в глубине офиса. Он с отеческой улыбкой смотрел на мои первые шаги в разработке и говорил: «Вот тут поправь, пожалуйста, и можешь выпускать».
Еще я знал, что такое «благословение тимлида» — так было на следующем моем месте работы, уже в российском стартапе, где качество кода контролировал серый кардинал, тайно посещавший мои ветки в репозитории и вносивший туда свои корректировочные коммиты. Иногда он не удалял мои строчки, а комментировал их, оставляя рядом пометки вроде «Кто это писал — никогда больше так не делайте» или «Сделал проще», которые четко указывали мне мое место в корпоративной иерархии и вдобавок вызывали у меня жгучий стыд, как у подростка, забывшего стереть историю браузера на семейном компьютере.
Все это закончилось, как дурной сон, когда я устроился работать в HeadHunter.
— У нас есть код ревью, — сказал мне на собеседовании руководитель фронтенд-группы.
— Вау, круто! — ответил я, помня, что никогда нельзя показывать, что какой-то термин тебе не знаком.
Code review — это практика, позволяющая поддерживать качество кода в проекте при помощи его вычитки другими разработчиками перед выпуском задачи. Это значит, что каждый программист, закончив кодить, говорит коллегам: «Ребята, я тут сделал то-то и то-то — пожалуйста, посмотрите, проверьте, что все в порядке, и я нигде не ошибся». Коллеги пробегают глазами его код, отмечают опечатки, семантические, логические и технологические неточности, предлагают их исправить, предлагают более эффективные варианты решения; разработчик соглашается или не соглашается с ними, они находят компромисс, кто-то один назначается ответственным ревьюером, после чего чистый (насколько это возможно) код отправляется в production.
Ревью — увлекательный и сложный процесс, почти как разработка. В зависимости от качеств задачи (сложность, интересность, потенциал для холиваров и взаимного троллинга, собственно код) в дискуссии могут принимать участие от двух до нескольких десятков разработчиков, а длиться она может от пары минут («Привет, есть задачка…» — «Reviewed») до недель («Re: Re: Re: Re: Переменные в глобальной области вид… [23:40]»).
Есть много способов ревьюить код. Кто-то предпочитает вариант парного программирования, когда коррективы вносятся непосредственно во время обсуждения. Это может быть полезно, когда задача нетривиальная, и, прежде чем обсуждать детали, нужно вникнуть в суть происходящего. Но обычно удобнее работать асинхронно и вести дискуссию в комментариях к коду, параллельно занимаясь другими делами. Среди фронтендеров hh.ru гораздо большей популярностью пользуется второй вариант. Во-первых, потому что это красиво.
Во-вторых, потому что всегда можно обратиться к другим разработчикам и совместными усилиями разрешить спор.
В-третьих, потому что таким способом мы убиваем двух зайцев: сохраняем чистоту кода и пишем документацию, которая поможет в будущем понять, зачем были добавлены те или иные строчки.
Найти автора.
Понять его.
У ревью, несомненно, есть и минусы. Основной — увеличение времени разработки. Если вы работаете над прототипом или MVP, и вам нужно сделать «быстро и чтобы работало», то ревью с его соблазнами придраться к мелочам может только все испортить. Именно семантические придирки являются самыми распространенными и одновременно самыми раздражающими. Как вампир, впервые попробовавший человеческую кровь, я моментально вошел во вкус после первого попавшегося мне лишнего пробела. Через неделю я уже был беспощадным граммар-наци, не пропускавшим ни одного случайного переноса — только PEP 8, только 79 символов в строке.
Еще один существенный минус — субъективность. Есть алгоритмы, модели, технологии, а есть привычки, странности и простая вкусовщина: коллега может считать, что твой подход — неверный, неэффективный, некрасивый, и на него не будут действовать никакие аргументы. Здесь очень хорошо помогает правило, согласно которому последнее слово в семантических спорах остается за автором.
В целом, при всех побочных эффектах, ревью — очень полезный инструмент, особенно в крупных компаниях с многолетней кодовой базой и большим штатом разработчиков.
Если вы хотите внедрить эту практику в своем проекте, то хорошим началом будет знакомство со специально придуманными для этого инструментами (например, Stash или Upsource) — чтобы не изобретать велосипед и в конечном счете не скатиться обратно к подходу «я там у тебя поправил». Также, если вы используете GitHub, можете попробовать создавать pull request для каждой новой ветки: это может быть простое описание задачи в двух словах или мини-документация в формате «проблема — причина — решение» и скриншотами вида «было — стало» (особенно если речь идет о верстке). На первых порах это можно сделать опцией, а потом включить в стандартный workflow, как это сделано у нас: если есть задача, обязательно должен быть соответствующий ей pull request.
А когда в команде станет слишком много перфекционистов и охотников за пробелами, на помощь вам придут утилиты и плагины для IDE, следящие за форматированием и синтаксисом еще на стадии разработки. Главное, как во всем, что касается разработки, — не увлечься и не съехать в overengineering — и тогда, несомненно, у вас появится шанс сделать мир еще немного лучше.
@dude Нет, давай лучше напишем «еще немного ближе к идеалу».@vanowski Нет, это отстой, так не говорят. Просто — «лучше» и все.@dude Ладно, кавычки и тире поправь, пожалуйста, и точки над ё —
(Титры.)
