Что такое код-ревью и кто им занимается?

Эффективный способ заботиться о качестве кода

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

Задачи код-ревьюера

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

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

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

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

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

Этапы работы и инструменты

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

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

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

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

«Наша задача в том, чтобы разработчик понял, в чём заключается комментарий и почему важно исправить код в соответствии с ним. Для этого недостаточно сильных технических знаний, нужны хорошие soft skills. Если ревьюер дал полезный комментарий, а разработчик почему-то не захотел исправлять — это будет выглядеть глупо», — говорит Андрей Строгов.

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

«Не стоит оставлять комментарии в духе “бред какой-то” или “тут ты не подумал”. Нужно формулировать проблему корректно. Субъективное мнение тоже не помогает улучшить код. Лучше найти что-то точнее, чем “это непонятный код”», — говорит Андрей Строгов.

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

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

Знания и навыки

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

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

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

«Для команды хорошо, когда ревьюер может искренне похвалить удачное решение, — говорит Андрей Строгов. — Разработчики делятся на две категории. Одни считают, что пишут идеальный код, другие — что их код плох. Поэтому важно научиться искренне хвалить за хорошие решения. Это приятно автору кода и укрепляет отношения в команде».

Стать хорошим ревьюером помогает практика. Если в вашей команде пока нет такой деятельности, можно искать подходящие проекты на GitHub и оставлять комментарии там. «Код-ревью влияет на качество кода уже самим фактом своего существования, —говорит Андрей Строгов. — Когда знаешь, что твой код посмотрят, тщательнее к нему относишься. Например, постараешься его понятно оформить, не будешь использовать запутанную логику, в которой не смог бы разобраться другой разработчик. Это полезная социальная составляющая, которая мотивирует делать более понятный код».

Источник

Код-ревью в Практикуме: как мы делаем его быстрее и эффективнее

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

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

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

Код-ревью в Практикуме

В Практикуме мы проводим ревью кода на собственной онлайн-платформе, которая называется «Ревизор». Туда попадают все сданные студентами работы. Платформа работает по аналогии с интерфейсами в Gitlab/Github/Bitbucket: можно просмотреть список файлов, изменения между версиями, а также оставить комментарии к определённым строкам.

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

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

Во вкладке «Код-ревью» можно оставлять разные типы комментариев к коду.

Ну а в последней вкладке видно все предыдущие варианты с комментариями.

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

Главное отличие «Ревизора» от других платформ в том, что у нас комментарии делятся на три типа: «Надо исправить», «Отлично» и «Можно лучше».

Что значат эти типы комментариев? «Надо исправить» — это обязательные правки. К ним относятся несоответствия заданию, грубые стилистические ошибки, неверное использование тех или иных инструментов и подходов.

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

«Отлично» — это комментарии, которыми мы хвалим студентов за то, что они верно справились с заданием или использовали нестандартные и интересные подходы.

В Практикуме студенты учатся по спринтам. Спринт длится две недели, и за это время студент изучает законченную часть теории, например ООП в Python. По завершении спринта студенты пишут итоговый проект. Он небольшой, но позволяет студенту закрепить материал, а ревьюеру — убедиться в том, что студент усвоил теорию как следует.

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

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

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

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

Формула идеального комментария

Постепенно мы пришли к внутренней формуле «идеального комментария».

Вот пример комментария:

А вот пример комментария «Отлично» за выбор эффективного решения:

Или пример необязательной правки:

Вот так выглядит хороший абстрактный комментарий, написанный по такой формуле:

Здесь лучше использовать кое-что другое, что реализует такой-то функционал, потому что вот это работает медленнее. Пример кода. Ссылка на бенчмарк, ссылка на пояснение «этого».

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

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

Принципы код-ревью

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

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

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

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

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

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

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

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

За счёт всех этих факторов у ревьюеров появляется больше времени на более качественный фидбек студенту.

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

Что почитать

Для тех, кто хочет повысить качество своего кода, я могу посоветовать книги Стива Макконнелла «Совершенный код» и Антона Спрола «Думай как программист».

Источник

Яндекс практикум код ревьювер

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

Совсем другой способ
учиться онлайн

(1) Практикум — это образовательная среда,
в которой ваш процесс обучения основан на реальных ситуациях. Вы учитесь программированию и с первого урока пишете код; на занятиях по дизайну — работаете с реальными макетами, а на уроках английского сразу начнёте разговаривать.

(2) Среда изначально спроектирована
для онлайн-обучения — вам понадобится
компьютер и спокойное место, где вас не будут
отвлекать. Самостоятельная работа сочетается
с регулярным общением с наставниками
и возможностью поговорить с поддержкой.
Любую проблему можно решить немедленно.

(3) Так, чтобы вы не бросали на полпути.
70% наших студентов завершают начатый курс
и вскоре находят работу или начинают применять
английский в жизни. Эта статистика отражает нашу
идею — из обучения каждый должен получить
осязаемую, практическую пользу.

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

Павел Моисеев

Всем привет! В сентябре завершил курс от Яндекс Практикума «Критическое мышление», который длился 2 месяца.

Курс могу порекомендовать по следующим причинам:

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

•навыки взаимодействия в командах в условиях онлайн конференции с людьми из разных сфер деятельности;

•отработка навыков работы с новыми системами визуализации и общения (slack и miro)

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

•постоянное сопровождение со стороны наставников курса относительно изучаемых вопросов.

Источник

Рецепт полезного код-ревью от разработчика из Яндекса

Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.

С помощью код-ревью я постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: «А что, так тоже можно?». В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть мои пулреквесты. Это мотивирует писать красивый и понятный код.

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

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

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

«До ревью». Советы автору

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

Коммиты

Каждый шаг рецепта – это коммит: разбили два яйца – закоммитили, добавили стакан молока – закоммитили, насыпали двести граммов муки – снова закоммитили.

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

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

Крошите, разбивайте, измельчайте свой код на маленькие коммиты. Это позволит ревьюверу лучше разобраться в вашем коде. Ничего страшного, если вы переборщите с декомпозицией. Два коммита легко объединить в один. Гораздо сложнее разделить большой коммит на несколько маленьких. «Нарезанные овощи» легко получить перемешивая «нарезанные помидоры» и «измельчённый лук». Но чтобы получить из тарелки салата все ингредиенты по частям, нужно потратить намного больше времени.

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

Описание коммитов

Когда я пишу email, то заполняю заголовок и содержимое письма. Заголовок — короткое и ёмкое название, тело письма — развёрнутое, подробное описание с картинками и ссылками. Такой же подход применяю к описанию коммитов.

Не люблю рецепты, где пишут «добавьте щепотку соли» или «выпекайте до готовности». Щепотка у каждого своя, а глядя на курочку в фольге я не могу определить её готовность. В описании коммитов стараюсь избавляться от всех неоднозначностей. При помощи ASCII-графики описываю тестовый пример. Если решению предшествовало обсуждение, где мы рисовали схемы на доске или в блокноте, то прикладываю к описанию ссылку на фотографию.

(пример описания коммита с использованием ASCII-графики)

(пример описания пулреквеста с заголовком и телом. Для редактирования комментария я использовал консольный редактор vim)

(пример отображения коммита с описанием на GitHub. По стрелкам в правом верхнем углу можно перемещаться между коммитами)

Самопроверка

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

Проверка кодстайла

Не представляю свою жизнь без линтера. Это инструмент, который автоматически проверяет соответствие кода выбранному стилю. Для JavaScript я использую ESlint. Можно сравнить линтер с роботом R2-D2 из «Звёздных воин», который ходит по коду и приводит его в порядок. Места, которые он не может исправить сам, подчеркивает красным.

С моим любимым WebStorm этот линтер работает «из коробки». Я вижу и исправляю проблему сразу, как только написал код, а не оставляю эту работу на потом. Перед коммитом линтер запускается автоматически при помощи husky.

Код после линтера приятно смотреть. Я избавляю ревьювера от необходимости писать десятки бесполезных комментариев о пропущенном пробеле. Всё внимание будет сконцентрировано на действительно важных вещах.

(пример запуска линтера на коммит)

Описание пулреквеста

(пример описания пулреквеста текстом, если скопировать результат вывода предыдущей команды)

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

Пулреквест готов! Но не спешите закрывать задачу, самое интересное ещё впереди.

«Во время ревью». Советы ревьюверу

Давайте ненадолго отвлечемся от создания пулреквеста и представим себя на месте ревьювера – человека, которому прислали код на проверку.

Ревью архитектуры

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

В любой непонятной ситуации задаю вопрос. Даже если он кажется мне глупым или банальным. Таким вопросом я могу натолкнуть автора на правильную мысль.

Задача ревьювера – показать альтернативы

В некоторых случаях я не согласен с предложенным решением. Это нормально! У каждого программиста своё мнение. Если код автора объективно хороший, то я не пытаюсь переубедить его. Максимум высказываю предложение, подкрепляя его ссылками, бенчмарками или картинками. Это позволяет вести конструктивный диалог, а не переходить на личности.

Единый стиль

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

Разберёмся на примере. Автор написал функцию суммирования массива чисел таким образом:

Такой код можно переписать компактнее, используя стрелочные функции:

Но проект начинали тогда, когда ещё не было стрелочных функций. Если написать компактное решение, то код перестанет быть единообразным, в нём станет сложно разбираться. Либо оставляем вариант автора, либо переписываем все функции на стрелочные. Главное – сохранить единый стиль.

Offline

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

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

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

Опасная практика, но порой без неё не обойтись. Применяйте offline-ревью с осторожностью.

«После ревью». Советы автору

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

Диалог

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

Я отвечаю на комментарии во вкладке с файлами. Так ревьювер получит одно письмо со всеми отметками и вопросами, а не по письму на каждый комментарий.

(пример ответа на ревью: комментируйте на вкладке с файлами и благодарите ревьювера в конце)

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

История коммитов

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

(пример ребейза, в котором четыре последние коммита сливаются в один)

Можно обойти трудности описанные выше используя новые возможности интерфейса GitHub. Для этого перед мержем выбираем пункт «Squash and merge».

(пример объединения коммитов при мерже через интерфейс GitHub)

(Серверную версию ветки можно удалить по кнопке сразу после мержа пулреквеста.)

Заключение

В заключение, ещё раз коротко о командах, которые я использую:

Вопросы

Копируем картинку в буфер обмена и вставляем в любое поле ввода на гитхабе. В комментарии к issue, коммиту или в поле описания пулреквеста. Спустя несколько секунд получим ссылку на картинку.

Я установил на сотовый телефон программу Office Lens. Она вычищает лишний мусор с фотографии, кропает, убирает искривления и позволяет быстро пошарить картинку в любой чатик.

Если по делу и без злоупотребления. В общем, всё как в жизни.

Источник