Code review что это

В тысячный раз о code review

Потому что я вбила здесь в поиске «code review» и обнаружила 50 страниц по 20 результатов на каждой.

Штуки три с высоким рейтингом прочитала. Но всё по понятным причинам не осилила.

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

Итак. Есть много способов для повышения качества кода, создаваемого командой: тестирование, статический анализ, экстремальное программирование. Сегодня расскажу о code review.

Для тех, кто не в курсе, code review – это процесс просмотра кода, сделанного одним разработчиком, другим разработчиком с последующей выдачей комментариев. В идеале, это повышает качество кода.

Во мне процесс code review вызывает смешанные чувства: с одной стороны, это безусловное благо. Правильно настроенный процесс повышает культуру разработки кода, позволяет старшим сотрудникам ненавязчиво делиться опытом с новичками, улучшает качество инженерных решений и т.д. С другой стороны, если ты та самая старшая разработчица, грамотно и вдумчиво проводящая ревью, то каждый первый младший разработчик в твоей команде стремится заполучить твое мнение по поводу своего кода. И вот ты проводишь до трёх часов в день просматривая чужой код ​ вместо того, чтоб писать свой.

Это цена. Не все команды согласны её платить в погоне за качеством. Мне везло работать в тех, что согласны.

Итак, поехали. Как проводить code review, чтобы извлечь из процесса максимальную пользу?

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

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

​ Задавать вопросы в случае недопониманий. Тут всё просто. Нужно стремиться понять чужую мысль на 100%. Как вы знаете, если когда-нибудь читали чужой код, это не всегда бывает просто. Если что-то непонятно – спросите автора, можно по телефону, если так быстрее.

​​ Использовать комментарии. В коде имею ввиду. Хорошо откомментированный код снижает количество созвонов, требующихся в предыдущем пункте ​ Помните об этом. Экономьте чужое время.

​​ Соблюдать определённые ограничения. Эксперты советуют просматривать за раз не более 500 строчек кода, а также ограничивать длительность ревью шестьюдесятью минутами. Тут бы ссылку на источник, но я не помню, где видела это правило. Но оно правда дельное. Пользуйтесь.

​​ Использовать чек-лист. Чтобы повысить эффективность себя как ревьюэра, хорошо бы завести список того, на что надо обратить внимание. Мои три общеупотребимые вещи для проверки: дубликации кода; грамотное использование RAII (это ещё что такое? Кто не знает — объясню как-нибудь ещё); грамотное именование сущностей. Остальное специфично для языка и для проекта.

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

Как НЕ НАДО проводить code review?

​​ Юмор за 300. Как мы помним, вежливось очень ценна для грамотного code review. Я понимаю, что бывает присылают на ревью такое, что сложно не взоржать, и что мы все тут дофига юмористы. Но правда, лучше поржите с подружками после работы. Если у вас есть подружки-программистки не из вашей команды, расскажите им эту фееричную шутку – они оценят. Code review достаточно личная штука и шутки над кодом могут быть восприняты как личное оскорбление. Не надо так.

​​ Пытаться делать работу по отлову ошибок. Это не то, на чём нужно концентрироваться. Для отлова ошибок существует тестирование, валидация в конце концов. Оставьте эту работу тестам. А при ревью лучше сконцентрироваться на том хорошо ли код спроектирован. SOLID принципы, идиомы объектно-ориентированного программирования. Вот это всё. На этом концентрируйтесь. Хорошо ли такой код будет расширять и поддерживать в дальнейшем? Эти вопросы должны вас волновать в первую очередь, на мой взгляд.

​​ Проверять соответствие стилю (в смысле coding style/coding guidelines). Не нужно. Все проверки правильного количества пробелов, длинны строк, наличия табов и т.д. оставьте роботам. Т.е. просто введите в ваши процессы автомат по выравниванию стиля. Indent, clang-format и т.д. вам в помощь.

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

Всем хороших code review.

А с меня хватит на сегодня, пожалуй.

Что такое код-ревью

Зачем программисты смотрят и обсуждают код друг друга.

Время чтения: 6 мин

Открыть/закрыть навигацию по статье
Контрибьюторы:

• Егор Левченко ,
• Рома Карвацкий

Обновлено 25 июня 2023

Кратко

Скопировать ссылку «Кратко» Скопировано

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

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

Как происходит

Скопировать ссылку «Как происходит» Скопировано

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

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

Пулреквест (PR) — это предложение слить изменения в ветке разработчика с другой веткой. Иногда их называют мёрж-реквестами (MR).

Типичный код-ревью к пулреквесту на GitHub выглядит так:

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

Conventional comments

Скопировать ссылку «Conventional comments» Скопировано

Подобные замечания не ставят приоритет комментариям, поэтому они мало полезны:

Если поставить перед комментарием лэйбл, намерение станет ясным, а тон резко изменится.

suggestion: Это неправильно сформулировано.

nitpick (non-blocking): Это неправильно сформулировано.

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

suggestion: Это неправильно сформулировано
Можем ли мы изменить этот текст, чтобы он соответствовал формулировке со страницы маркетинга?

Формат

Скопировать ссылку «Формат» Скопировано

Conventional comments предлагает формат, где сообщение описывается как:

 [decorations]: [discussion]

• label — тип комментария;
• subject — основная мысль комментария;
• decorations ( опционально ) — дополнительные лэйблы для комментария. Они окружены скобками;
• discussion ( опционально ) — здесь содержатся подтверждающие заявления, контекст, рассуждения и все остальное, чтобы помочь сообщить «почему» и «последующие шаги» для разрешения замечания;

question (non-blocking): На этом этапе имеет значение, какой поток выиграл?
Может быть, чтобы предотвратить состояние гонки, мы должны продолжать зацикливаться, пока все они не выиграют?

Лэйблы

Скопировать ссылку «Лэйблы» Скопировано

Настоятельно рекомендуется использовать следующие лэйблы:

Лэйбл	Описание
praise	«Похвала» подчёркивает что-то положительное. Попробуйте оставить хотя бы один такой комментарий. Не оставляйте ложных похвал (которые на самом деле могут нанести вред).
nitpick	«Придирки» — это небольшие, но необходимые изменения. Придирчивые комментарии значительно помогают направить внимание читателя на комментарии, требующие большего внимания.
suggestion	«Предложения» предоставляют способы по совершенствованию в определённой теме. Важно быть предельно ясным в том, что предлагается и почему именно это улучшение. Рассмотрите возможность использовать блокирующие и не блокирующие декорации для последующего информирования о ваших намерениях.
issue	«Проблемы» высвечивают конкретные трудности рассматриваемого вопроса. Если вы не уверены, существует проблема или нет — рассмотрите возможность оставить question.
question	«Вопросы» допустимы, если у вас есть потенциальная проблема, но не уверены уместна она или нет. Обращение к автору с просьбой о разъяснении или расследовании может привести к быстрому урегулированию этого вопроса.
thought	«Мысли» представляют собой идею, которая всплыла в процессе ревью. Эти замечания по своей природе не блокируют, но они чрезвычайно ценны и могут привести к более целенаправленным предложениям и возможностям наставничества.
chore	«Рутинная работа» — это небольшие задачи которые необходимо выполнить до того как пулреквест (или другая форма ревью) «официально» будут приняты. Обычно в таких комментариях упоминаются какие-то общие процессы. Постарайтесь оставить ссылку в описании на процесс, чтобы автор мог понять как именно выполнять рутинную работу.

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

Декорации

Скопировать ссылку «Декорации» Скопировано

Декорации дают дополнительный контекст для комментария.

suggestion (security): Я немного обеспокоен тем, что мы внедряем собственную функцию очистки DOM здесь.
Можем ли мы вместо этого рассмотреть возможность использования фреймворка?

suggestion (test, if-minor): Похоже, что мы пропустили какие-то тесты

Декорации могут быть индивидуальными для каждой команды. Рекомендуется установить минимальный набор декораций на ваше усмотрение.

Возможные декорации включают:

• (non — blocking ) — комментарий с такой декорацией не должен препятствовать принятию рассматриваемого пулреквеста. Это полезно для команд, которые рассматривают блокирование комментариев по умолчанию.
• (blocking ) — комментарий с такой декорацией должен препятствовать принятию рассматриваемого вопроса до тех пор, пока он не будет решён. Это полезно для команд, которые считают, что комментарии не блокируются по умолчанию.
• (if — minor ) — эта декорация даёт автору некоторую свободу действий, которая заключается в том, что он может разрешить комментарий только в том случае, если изменения окажутся незначительными или тривиальными.

Больше примеров

Скопировать ссылку «Больше примеров» Скопировано

@elain — mask
nitpick (non-critical): Некритично, но для консистентности папку с изображениями батутов назвал бы assets.

@vasya _ pupkin
praise: Супер! Отлично поработал над этой фичей!

@anonymous
issue(critical): Здесь уж слишком разбухшая логика
suggestion(critical): Сейчас не особо больно, но по-хорошему бы декомпозировать это все дело

Итого

Скопировать ссылку «Итого» Скопировано

Преимущества и недостатки общепринятых комментариев (они же conventional comments):

Преимущества

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

Издержки

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

Полезные ссылки

Скопировать ссылку «Полезные ссылки» Скопировано

• Conventional comments
• Github saved replies

На практике

Скопировать ссылку «На практике» Скопировано

Игорь Камышев советует

Скопировать ссылку «Игорь Камышев советует» Скопировано

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

Не расстраиваться

Скопировать ссылку «Не расстраиваться» Скопировано

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

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

Ругать код, а не автора

Скопировать ссылку «Ругать код, а не автора» Скопировано

Многие люди совершенно не специально могут обидеть автора изменений, недостаточно мягко формулируя мысли:

❌ «Ты болван, тут нужно использовать пул коннектов!»

✅ «Слушай, а почему тут не используется пул коннектов? Мне кажется, это может привести к проблемам с производительностью».

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

Смотреть вглубь

Скопировать ссылку «Смотреть вглубь» Скопировано

При обзоре чужого решения велик соблазн давать мелкие советы. Это называется эффектом велосипедного сарая (bikeshedding). Он создаётся, потому что для обсуждения сложных, глубоких вопросов нужно сильно погружаться в контекст внесённых изменений, а это трудно. Намного проще написать десяток комментариев о забытых точках с запятой и спокойно продолжить заниматься своей задачей.

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

Code review. Всё, что нужно знать.

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

А начнем мы с главного — обсудим зачем вообще нужно Code review.

Какой профит? ��

Code review создано не только для улучшения кода, это социальный процесс, в котором принимают участие коллеги с двумя ролями — автор и ревьювер.

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

Ловушка

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

Какой процесс проведения Code review?

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

�� Code-review — процесс итерационный и на каждой итерации происходит следующее:

1. Автор делится кодом
2. Ревьювер смотрит код, формирует фидбек и отправляет его автору
3. Автор реагирует на фидбек уточняющими комментариями или изменениями в коде и снова отдает код на ревью.

⚽️ Такая игра в пас приведет к чистому коду и шарингу знаний, все в плюсе.

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

Как писать фидбек?

Фидбек должен быть изложен как рекомендации, а не команды к выполнению.

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

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

Критикуем код, а не кодера.

Цель Code review — сделать код лучше, а не найти виновных. Чтобы повысить командный дух и понизить напряжение — используй слово Мы, вместо Ты. Нужно размыть конкретику о том кто написал код, гораздо важнее сосредоточится на решении проблем, которые были найдены в коде.

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

One more thing совет ☝️

Настоятельно рекомендую время от времени менять ревьюверов. Это позволит получить новый взгляд и опыт для всех сторон.

На что обращать внимание? ��

Руководствуясь рекомендациями от Google по проведению Code Review, можно выделить следующие пункты на которые нужно обратить внимание при Core Review:

• Дизайн: хорошо ли спроектирован и вписывается ли код в вашу систему?
• Функциональность: ведет ли код так, как предполагал автор? Подходит ли эта реализация для выполнения поставленной задачи?
• Сложность: можно ли сделать код проще? Сможет ли другой разработчик легко понять и использовать этот код, когда он встретится с ним в будущем?
• Тесты: покрыт ли новый функционал тестами?
• Именование: выбрал ли разработчик четкие имена для переменных, классов, методов и т. д.?
• Комментарии: комментарии понятны и полезны?
• Стиль: соответствует ли код принятым у вас стайлгайдам?
• Документация: обновил ли разработчик соответствующую документацию (CHANGELOG, как минимум)?

Где срезать углы? ��

Практики, которые помогут сократить время, затраченное на ревью:

• Устранение ошибок до ревью. Проверяй свой код самостоятельно, велика вероятность, что еще до ревью ты сам найдешь пути для улучшения. Проверив код самостоятельно, ты экономишь время ревьювера, он этого не забудет ☺️
• Создай со своей командой стайлгайд и усовершенствуйте его итеративно. Стайлгайд положит конец спорам во время Code review о нейминге, комментариях и т.д.
• Не запаривайтесь над мелочами, сконцентрируйтесь на интересных вещах. Пусть за форматирование и прочее беспокоится автоматизированный анализатор и форматтер кода, а не ревьювер с автором. Сэкономленное время лучше потратить на тимбилдинг ��
• Правильные сообщения в коммитах помогут быстро влиться в контекст. Не забывайте, что сообщение коммита — часть документации для ревью ☝️

Заключение ��

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

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

Куда дальше? ��

Самое время написать стайлгайд для своего проекта или же подумать над интеграцией автоматического анализа и форматирования кода. А возможно кому-то стоит переосмыслить Code review и начать воспринимать его более положительно, что позволит получить наслаждение от каждой сессии Code review ��

Как провести код-ревью: советы по применению

Разбираемся, кому и когда нужна (и не нужна!) дополнительная проверка кода, и каких ошибок избежать на старте.

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

Что такое код-ревью и зачем его проводят?

Код-ревью — это процесс проверки кода, который позволяет:

выявить → ошибки, пропуски, уязвимости и стилистические недочеты (с точки зрения проекта или принятых в команде правил).

• улучшить →

→ читаемость и понятность кода для других разработчиков.

→ архитектурные решения. Например, разбиение на модули, code style решения, неверно подобранный паттерн проектирования.

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

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

Когда не нужно проводить код-ревью?

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

Причины, чтобы отказаться от код-ревью в конкретном случае:

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

Причины, чтобы отказаться от постоянной практики код-ревью:

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

Как организовать процесс проверки кода?

• После выполнения задачи автор кода делает в отдельной ветке push в удаленный репозиторий и создает Merge Request (MR).

• Назначается assignee (ответственный за MR) и reviewer (ответственный за проверку).

• Затем начинается серия проверок, которая называется раундами. Цель каждой итерации — найти проблемы и недочеты, которые могут отразиться на работе проекта в будущем.

Раунды

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

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

Если таких проблем не нашлось, уровень проверки понижается до тех пор, пока не найдутся места для улучшений.

«В первом раунде не стоит акцентировать внимание на мелких недочетах. Скорее всего, автор сам их обнаружит и поправит, и ревьюеру не придется тратить время на поиск незначительных проблем»‎, — отмечает разработчик Selectel Антон Щербак.

После код возвращается автору: он вносит изменения и снова отправляет на проверку. Процесс продолжается до тех пор, пока решение не признают приемлемым — оно одобряется тем, кто проводил ревью, и после assignee выполняет merge.

«Решение не должно быть идеальным — оно должно соответствовать потребностям проекта и выполнять поставленную задачу»‎, — резюмирует Антон Щербак.

Как понять, что решение готово?

→ Оно не имеет явных ошибок.

Ревью может выявить недочеты, которые видны без запуска проекта. Обычно это:

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

→ Соответствует стайл-гайдам, принятым в команде.

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

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

→ Не затрагивает код, выходящий за рамки задачи.

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

→ Пропущено через линтеры, используемые в проекте.

Большинство команд в Selectel использует pre-commit — так при каждом коммите код прогоняется через линтеры. Для Python используется black, isort, flake8, pyupgrade и autoflake.

→ Обладает хорошей читаемостью и пояснением неочевидных мест.

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

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

→ Если на проекте пишутся автотесты, решение должно ими покрываться.

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

→ Нет оверинжениринга (кода «на будущее»‎).

Часто код, который решает еще не возникшие проблемы, не пригождается и становится лишним.

Еще Дональд Кнут говорил: преждевременная оптимизация — корень всех проблем в программировании.

Советы по процессу

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

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

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

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

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

Так не стоит комментировать → «Ты тут ошибся, поправь по моему примеру. Вот ссылка».

Так лучше → «Мы уже сталкивались с аналогичной ситуацией. Вот как эта проблема решилась тут → ссылка. Можем ли реализовать нечто подобное?»

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

Удобные инструменты для код-ревью

• GitLab — используем в Selectel.

По ссылке конкретные гайдлайны, которыми пользуются в GitLab. В них описано, как построена практика код-ревью в компании.

GitHub. Подробнее об инструменте — по ссылке.