КОД-РЕВЬЮ

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

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

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

Тональность ревью

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

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

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

Запрос изменений до утверждения

Опытные ревьюеры не утверждают изменения, пока остаются какие-либо нерешенные вопросы. Но они всегда указывают, если какие-то недочеты являются некритичными, называя их мелочами (nitpicks), а одобряют изменения фразами вроде LGTM (looks good to me — «все в порядке»). Кроме того, они четко указывают на необходимость дополнительных действий, используя для этого специальные инструменты или командные соглашения.

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

Общение вживую

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

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

Мелкие замечания

Мелкие замечания (nitpicks) касаются незначительных изменений, которые не оказывают существенного влияния на общее качество пул-реквеста, например: предложение другого имени переменной или функции, требование расставить объявления переменных в алфавитном порядке или поправить отступы.

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

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

Новые сотрудники и код-ревью

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

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

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

Ревью в условиях разных офисов и часовых поясов

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

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

Дополнительные рекомендации по проведению качественных код-ревью можно найти в:

• Руководстве по код-ревью от Google;

• Руководстве по код-ревью от GitLab.

ПАРНАЯ РАБОТА

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

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

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

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

Когда может быть полезна парная работа

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

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

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

• Отладка сложного бага. Иногда может быть непонятно, по какой причине что-то не работает, даже после нескольких попыток отладки. В таких случаях может быть полезно привлечь к вашей работе другого специалиста, причем он даже не обязательно должен быть более опытным. Во многих случаях можно продвинуться вперед, просто объяснив коллеге свои предположения и перечислив испробованные способы решения.

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

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

• Понимание работы системы. При работе с новой системой, сервисом или компонентом, сложным для понимания, гораздо быстрее и эффективнее работать в паре с экспертом в этой области — или даже разработчиком этой системы.

• «Подсмотреть», как работают другие. Значительное преимущество парной работы заключается в том, что вы можете наблюдать, как работают другие. Вы общаетесь с ними, узнаете их ход мысли, видите их IDE, используемые ими горячие клавиши, как они пишут и тестируют код и т. п. Часто работа в паре с кем-то была для меня настоящим откровением, и впоследствии я заимствовал инструменты и подходы, которые мне понравились.

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

Если вы более опытный напарник

Если в паре вы более опытны, есть несколько способов сделать вашу совместную работу эффективной:

• Обозначьте проблему. Попросите своего коллегу объяснить проблему, которую он хочет решить. Иногда разработчик обращается за помощью, но не совсем ясно, в чем именно ему нужно помочь. Работа будет более эффективной, если сначала уточнить ее цели. Это задача по запуску базовой реализации функциональности или нужно помочь разобраться в структуре компонента? Добейтесь конкретики и не принимайтесь за дело, пока не проясните все детали.

• Оцените срочность. Есть огромная разница между тем, когда кто-то хочет поработать в паре, чтобы скорее устранить сбой, влияющий на тысячи пользователей каждую минуту, и обсуждением вопроса, не имеющего никаких временных ограничений.

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

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

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

• Позвольте напарнику поработать самому. Поскольку вы более опытны, скорее всего, вы можете решить проблему быстрее. Но не забывайте, что ваша цель — научить. Поэтому дайте своему напарнику возможность выразить свои мысли, а если вы начали писать код сами, уступите ему клавиатуру и позвольте завершить задачу.

• Старайтесь чему-то научиться у своего напарника. Когда вы более опытны, чем ваш коллега, то можете подумать, что весь рабочий процесс вы будете только учить и ничего нового не узнаете. Но это не обязательно так! Если вы будете задавать вопросы, то ваш напарник может удивить вас подходами, о которых вы даже не думали, или опытом, о котором не знали.

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

• Отвлекаться — это нормально. Работая в паре, можно и отвлечься от основной задачи, особенно если нет жестких сроков. Это нормально и естественно. Парная работа — это не только решение задач и обучение, но и возможность лучше узнать друг друга. А еще это весело! Так что если есть желание обсудить интересную тему — вперед.

Если вы менее опытный специалист

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

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

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

РАБОТА С ДРУГИМИ КОМАНДАМИ

Существует множество причин, по которым вам может понадобиться работать вместе с другой инженерной командой, например:

• необходимость разобраться в коде, написанном или измененном инженером из другой команды;

• внесение изменений в код, за который отвечает другая команда;

• вопросы по поводу использования сервиса или компонента, поддерживаемого другой командой;

• планирование изменений в коде, за который отвечает другая команда, для его соответствия общепринятым соглашениям;

• другая команда должна устранить тормозящую вашу работу проблему в системе, которую они обслуживают.

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

В небольших компаниях с ограниченным штатом инженеров легко познакомиться со всеми коллегами и узнать, чем они занимаются. Например, в коллективе из шести человек, включая вас, вы будете знать, что Боб и Сьюзи занимаются бэкендом, Сэм и Кейт работают с вебом, а Том разрабатывает мобильное приложение, так что вам будет понятно, к кому и по каким вопросам обращаться. То же самое справедливо и для компании с пятью командами разработчиков: команды платформы и ядра в основном состоят из бэкенд-разработчиков, а команды web core, техподдержки и клиентского опыта включают в себя веб- и бэкенд-инженеров, а также разработчиков мобильного приложения.

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

Создайте карту команд

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

• от которых вы зависите, то есть те, чьи API или сервисы используете;

• которые зависят от вас. Совет: просмотрите все сбои, которые повлияли на вашу работу, и если изменения были внесены другими разработчиками, то, скорее всего, это и есть зависимая команда;

• разрабатывающие функционал, схожий с вашим, особенно с точки зрения пользователей;

• работающие над теми же интерфейсами, что и вы, если вы тоже отвечаете за пользовательские интерфейсы;

• инфраструктур, которые вы используете, пусть даже косвенно.

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

Познакомьтесь с другими командами

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

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

Цели такой встречи:

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

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

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