что такое код ревью
Код ревью, как внедрить и не испытывать боль
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето:
20% времени мы пишем новый код.
80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).
Во время поддержки мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
Способы иметь хорошо поддерживаемый код:
Все эти способы нужно уметь готовить. Есть тесты, которые только мешают, бесполезная документация и бессмысленный код ревью.
Что же такое код ревью?
Что нам даёт код ревью:
Проверку кода по многим критериям.
Автор не всегда видит неочевидные места в его коде (по разным причинам).
В результате написания и переписывания может быть потеряна композиция.
Автор, находясь в контексте задачи может недостаточно оставить комментариев.
Эти и многие другие проблемы может решить код ревью.
Шаринг знаний о проекте.Не только автор знает, что там пишется в другом проекте или части проекта, а все.
Шаринг знаний о технологиях.Вы можете заметить, что кто-то напилил своих костылей, а похожая проблема в проекте уже решалась. В таком случае ревьюер может подсказать что уже использовалось и избежать ненужного кода
Сотрудники быстрее онбордятся. Новые сотрудники, проводя код ревью, быстрее узнают и понимают традиции команды, а проходя его, имеют возможность исправить ошибки, узнать больше о продукте и меньше испытывать стресс.
Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью.
Советы по организации процесса
Условные обозначения:
— Как делать не нужно
+ Как делать нужно
- Ревьюить только джунов и новых коллег
+ Проводить ревью для всех и всеми
Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия и неравенства. Такую атмосферу следует избегать.
- Обсуждать на код ревью стиль
+ Настроить у себя на проекте инструменты, которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на споры о вкусах. Договоритесь заранее и пропишите правила. В случае разногласий голосуйте.
Не обсуждайте стиль на ревью
- Ревьюер запускает руками билд или проверяет код на баги.
+ Автор сам несет ответственность за поставленный код.
Автор тщательно проверил свой код на работоспособность и залил в удаленный git репозиторий
На сервере CI/CD проверяет тесты, сборку, работоспособность в целом.
Проверка со стороны ревьюера.
- Ревьюер не читает код
+ Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл)
Обращайте внимание на код ревью.
- Агрессия, негатив, «токсичное» поведение в комментах
+ Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Агрессия, негатив и токсичное поведение в принципе стоит избегать во всех областях жизни. Грубое поведение во время код ревью может привести к:
Стрессу и страху совершить ошибку
Примеры плохих комментов:
Примеры хороших комментов:
«Давай попробуем сделать …» «Может попробуем вынести…»
То же самое касается и ответов на комменты автором. Если автор не согласен, то необходимо объяснять с помощью аргументов, а не фраз в духе «я так делать не буду». Если не получается текстом, иногда проще подойти или сделать короткий созвон, чтобы понять друг друга.
Чаще хвалите код в ревью
- Все комментарии обязательны к исправлению
+ Помечать необязательные комментарии
Пытаться объяснить алгоритмы на словах
Написать пример псевдокода
Особенно актуально, если автор не совсем понимает что от него хочет ревьюер. Не нужно полностью писать реализацию. Напишите небольшой пример псевдокода. Gitlab, github и bitbucket позволяют вставлять в комментарии разметку markdown. Ваш код будет хорошо отформатирован и более понятен, чем длинная цепочка комментов.
- Оставлять больше 50 комментариев
+ Оставлять до 50 комментариев
Если комментариев накапливается очень много, то у вас:
Или не настроены линтеры, и вы не определились со стилем, поэтому комменты о вкусовщине
Или переделать в коде нужно многое
Во втором случае оставьте 1 комментарий с рекомендациями как и что нужно переписать. В таком случае лучше закрыть мердж реквест, переписать код и открыть новый.
Если код будет переписан полностью, отследить изменение по комментариям практически невозможно и они не имеют смысла. Авторы тоже должны это понимать и следить, чтобы всем было комфортно.
- Отправлять огромные фрагменты кода на ревью
+ Дробить большие участки кода на несколько реквестов и вливать постепенно
Задачи бывают разными по объему. Может быть задача исправить 1 строчку кода, а может быть задача отрефакторить весь проект. Во втором случае не отправляйте реквест в котором исправлены 500 файлов и 4000 изменений. Никто в здравом уме не сможет это нормально проверить, и желания такое проверять вы тоже не найдете.
Сделайте ветку feature/epic-name
Изменения делайте в ветке feature/epic-name-implement
Pull реквесты делайте в ветку feature/epic-name. Порционно.
В конце реализации фичи подлейте feature/epic-name в мастер. Да, в этом случае пулл реквест тоже будет огромный, но всё уже будет заранее проверено
Другой вариант как этого избежать: feature flags. Вы вливаете изменения на прод, но не даете им пользоваться. Нормально это реализовано мало у кого. Поэтому с этим подходом нужно быть осторожнее.
Уважайте тех, кто будет проверять ваш PR
- Pull Request висит без ревью трое суток
+ Выработать расписание
Среди аргументов против код ревью вы услышите, что с ним у вас увеличивается время «доставки» фич. Чтобы этого не происходило, выработайте у ревьюеров расписание. Например, новые реквесты проверять до работы и перед уходом домой, а исправленные в перерывах в течении дня (например пока проект собирается или тесты гоняются).
В заключении
В этой статье я хотел рассказать и показать плюсы проведения код ревью. Будучи старшим разработчиком я всегда за то, чтобы мой код проходил code review. Лично для меня это отличный способ “увидеть” свой код чужими глазами. еще до того как ветка отправляется на ревью. Не говоря уже о том, что для команд это недорогой и эффективный способ иметь кодовую базу, с которой можно будет эффективно работать.
Если в вашей команде нет код ревью, то самое время его внедрить .
Ссылки и благодарности
По теме рекомендую почитать:Статья How to Do Code Reviews Like a Human
Спасибо лису и kirjs из @learnInPublic за ревью статьи про ревью.
Code review — как это делать в стиле Google?
Авторизуйтесь
Code review — как это делать в стиле Google?
Рано или поздно для каждого программиста настаёт время отвлечься от собственного кода и оценить чужой. Осознав неизбежность этой работы, вам нужно будет решить, как цензурно выразить всё, что вы думаете о рецензируемом коде. Мы расскажем, как с этой задачей справляются в Google.
Стандарты
Главная цель code review в Google — постоянно совершенствовать кодовую базу. Соответственно, если вы делаете обзор на код, являющийся частью большого проекта, — подумайте в первую очередь не о сиюминутных решениях, а о том, как это повлияет на весь проект в перспективе. Есть два аспекта, которые вам придётся отбалансировать.
Дилемма обозревателя
С одной стороны, разработчику нужно предоставить возможность развиваться. Если вы честно скажете, что он наваял полный бред, который не пойдёт в кодовую базу ни под каким видом, вы можете лишить его всякого желания работать над улучшением кода.
В то же время нужно придерживаться стандартов качества кодовой базы проекта. Иногда кажется, что немного костылей и просто не слишком хорошего кода — не так уж и страшно, но такие вещи имеют свойство накапливаться.
Главное правило
Запомните, именно вам предстоит найти баланс, позволив кодерам развиваться, и в то же время не пожертвовав качеством кода.
Отсюда главное правило: даже если сам код, с вашей точки зрения, не идеален и не полностью соответствует стандартам вашей компании, его нужно добавить в базу, если вы уверены, что он улучшит проект.
Естественно, из этого правила бывают исключения. Например, если предложенный код добавляет фичу, которая определённо не нужна в проекте, от одобрения надо отказаться, как бы хорош ни был сам код.
Наставничество
Принципы
Разрешение конфликтов
В случае разногласий с кодером постарайтесь найти вариант, устраивающий обоих. В первую очередь обратитесь к чётко прописанным стандартам проекта. Возможно, будет лучше обсудить проблему при личной встрече или по видеосвязи.
Если это не помогает, стоит расширить дискуссию, вовлекая других членов команды, тимлида, эксплуатационников и инженеров. Не допускайте, чтобы вашего решения приходилось ждать слишком долго из-за разногласий с кодером.
Что нужно проверить в рецензируемом коде
Проверьте каждую строчку кода, рассмотрите весь код в контексте проекта. Удостоверьтесь, что он способствует улучшению кодовой базы. Ну и не забудьте поблагодарить разработчика за интересные решения.
Последовательность действий при рецензировании кода
Скорость подготовки code review
Чем чреваты медленные code review?
Как быстро нужно делать code review?
В идеале стоит приступать сразу после получения кода. Постарайтесь уложиться в один рабочий день. Учитывайте часовой пояс разработчика.
Единственное исключение из этого правила — если вы сконцентрированы на другой задаче. Переключение займёт слишком много времени.
Постепенно вы сможете увеличить скорость работы. Но не делайте это в ущерб качеству.
Работа с большими объёмами
Попросите разработчика разбить код на несколько небольших фракций, с каждой из которых можно быстро справиться. Если это невозможно, постарайтесь как можно быстрее прислать хотя бы общие рекомендации по улучшению. Разработчик не должен простаивать.
Экстренные ситуации
Иногда дела обстоят так, что скорость становится основным фактором, ради которого приходится жертвовать качеством. В вашем проекте такие ситуации должны быть чётко обозначены. В качестве образца можете свериться с гайдом Google.
Как писать комментарии во время рецензирования
Работа с возражениями
Разработчики могут быть не согласны с вашими указаниями. Эти люди работают непосредственно с кодом, так что задумайтесь, возможно, в их возражениях есть резон? Если же вы уверены в своей правоте, попробуйте донести свои аргументы до собеседника. Всегда оставайтесь корректны и внимательно изучайте доводы разработчика.
Не поддавайтесь на уговоры из разряда «сабмить сейчас, доделаю потом». Возможно, доделает. Но, как правило, нет.
А вот общие жалобы на излишнюю придирчивость имеет смысл пропускать мимо ушей. Придерживайтесь стандартов, принятых в вашем проекте и требуйте того же от других.
Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.
Перейти к регистрации
Адаптированный перевод статьи «How to do a code review»
Как проводить Code Review по версии Google
Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.
И вот недавно при подготовке к очередному выпуску подкаста «Цинковый прод» я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.
Термины, используемые в оригинальной статье:
CL — changelist. Но обычно это называют Merge Request или Pull Request, поэтому в статье я буду использовать сокращение MR
LGTM — Looks Good to Me. Короче, когда жмут кнопку «approve». Я буду использовать термин «апрув», как более понятный населению.
Идеальность MR
На практике можно встретить различные крайности при рассмотрении MR. Кто-то всей командой задалбывает замечаниями, пока всё до мелочей не будет исправлено, кто-то смотрит примерно логику и жмёт «апрув».
В Гугловском документе написана интересная мысль. MR не должен быть идеальным, но он должен улучшать кодовую базу. Т.е с каждым привносимым изменением код должен становиться лучше и лучше. И если MR добавляет много хорошего, то не надо придираться к мелочам; выгоднее, чтобы это улучшение попало в код побыстрее.
Никакой MR не должен делать код хуже. Единственное исключение — это если MR является срочным фиксом чего-нибудь.
Свобода делать замечания
Несмотря на то, что нельзя задалбывать мелочами, тем не менее можно свободно эти мелочи писать хоть к каждой строчке. Противоречие с предыдущим пунктом решается просто: мелочи и придирки ревьювер помечает префиксом «nit:» от англ. nitpick (придирка). Такие замечания фиксить необязательно, однако автор MR может захотеть что-то исправить или, даже если нет, учесть на будущее некоторые моменты.
Факты важнее персональных предпочтений
Почти всегда стандартные принципы построения ПО (software design), базирующиеся на лучших практиках, лучше, чем хитровымученные велосипеды. Поэтому предпочтение нужно отдавать им.
Если можно применить несколько стандартных подходов, то это на усмотрение автора.
Прямая цитата для лучшего понимания:
Aspects of software design are almost never a pure style issue or just a personal preference. They are based on underlying principles and should be weighed on those principles, not simply by personal opinion. Sometimes there are a few valid options. If the author can demonstrate (either through data or based on solid engineering principles) that several approaches are equally valid, then the reviewer should accept the preference of the author. Otherwise the choice is dictated by standard principles of software design.
Если ревьювер и автор MR не согласны друг с другом
Сначала идет попытка достигнуть консенсуса в комментариях к MR. Если это не получается, то личное обсуждение. Если все равно не пришли к единому мнению, то привлекать членов команды. Но главное, MR не должен застревать надолго из-за несогласия двух человек.
Скорость проверки MR
Скорость экстремально важна. Если раз в несколько дней давать по одному комменту, то автор MR будет жаловаться, что к нему придираются и не дают работать.
Если MR проверяется очень быстро, то любые замечания не будут являться большой проблемой — ведь их фиксы тут проверят, и таск пройдет дальше.
В Гугле советуют не отвлекаться от фокусировки над своей задачи, но если уж отвлеклись, то просмотреть, нет ли чего-то поревьювить. Например, вернулся с обеда — поревьювил. Пришел на работу — поревьювил. И т.д.
Порядок просмотра MR
Сначала надо просмотреть MR в целом. Надо ли это вообще, в правильном ли месте код (или это должно быть в отдельной библиотеке), есть ли какие-то глобальные проблемы.
Т.е. нет смысла смотреть какие-то детали реализации, если код вообще не туда и не для того.
Вообще, порядок просмотра важен, чтобы как можно быстрее выдавать автору фидбек (смотри предыдущий пункт).
Когда посмотрели MR вцелом, надо пройтись по основным файлам, т.е. проверить самое главное (если непонятно, что самое главное, можно спросить у разработчика).
Опять же, о любых проблемах нужно сообщать сразу, даже если вы еще не досмотрели MR и решили вообще досмотреть его позже.
Далее надо выбрать логичную последовательность просмотра оставшихся файлов. Ни один файл не должен быть пропущен.
На что обращать внимание при просмотре
Слишком большие MR
Слишком большие MR нужно просить разбивать на части. Почти всегда это возможно.
Как писать комментарии на код ревью
Если с вашим мнением не согласны
Нужно разобраться детально. Возможно, вы чего-то не понимаете, запросите больше информации. Возможно наоборот. В любом случае, зачастую понимание приходит только после пары раундов объяснений с обеих сторон.
Боязнь расстроить автора MR
Бывает, что разработчик расстраивается, если ревьювер настаивает на каких-то изменениях. Однако, чаще всего разработчики расстраиваются из-за формы замечания, а не из-за содержания. Будьте вежливы, объясняйте аргументами, и скорее всего всё будет ок.
«Я исправлю это потом»
Если разработчик согласен с тем, что в коде есть проблема, но просит заапрувить MR, обещая, что исправит это в другой раз, то, по мнению ребят из Гугла, это «потом» чаще всего никогда не наступает. Поэтому если MR — не какой-то срочный багфикс прода, то нужно настаивать на исправлении.
Выводы
Мне очень понравился этот документ от Google. Особенно лайфхак со словом «nit», акцент на скорости code review, а также то, что MR не должен быть идеальным. Вроде бы просто, но пока это явно не обдумаешь, до дела не доходит.
Если эта статья покажется интересной читателям и наберет какое-то количество плюсов, то я напишу следующую часть: процесс code review со стороны автора MR.
Алсо, в ближайшем выпуске «Цинкового прода» мы подробно обсудим код ревью с разных сторон. Поэтому не забудьте подписаться на наш подкаст о разработке!
Code review — улучшаем процесс
Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.
Как этого можно избежать? Ответ на вопрос в названии – Code review.
Code review — это проверка кода на ошибки, повышающая стабильность работы и качество кода.
Pull request / Merge request — это запрос к команде проекта (человеку или группе людей) на одобрение и применение изменений в выбранную ветку. Как только Pull request будет создан, перед одобрением происходит обсуждение написанного кода. Во время обсуждения могут быть предложены правки. После одобрения текущие изменения попадают в выбранную ветку.
Ниже перечислены рекомендации, которые помогут ускорить Code review и повысить его качество.
Поделим вопрос на три части и рассмотрим каждую по отдельности:
Часть 1. Проверяем код
Запускаем код автора у себя
Запустите код у себя и посмотрите, как изменения работают в связке с остальным кодом. Это помогает найти проблемные места, которые не видны в web-интерфейсе. Старайтесь видеть код комплексно, избегайте фокусироваться только на локальных изменениях. Так Вы быстрее разберетесь с кодом и быстрее найдете архитектурные неточности, если такие есть.
Помним про пользовательский опыт
Смотрим на общую логику
Разработчики могут успешно решить свою задачу, но поломать работу других кусков кода. Чтобы такого не происходило, смотрите не только на то, как решается конкретная задача, но и на то, как изменения отразятся на работе других сервисов, модулей и всего проекта в целом.
Смотрим на архитектуру кода
Архитектура кода определяет, как много времени в будущем мы потратим на расширение, добавление функционала или правку бага. Также архитектура кода может повлиять на потенциальное появление багов в случае изменений в проекте. В идеале расширение и добавление нового функционала не должно приводить к рефакторингу.
Пишем проще
Обращайте внимание на переусложнение кода: чем проще код, тем легче он читается и проще его поддерживать. Избавляйтесь от сложных кусков кода.
Многопоточность
Если в проекте подразумевается работа в нескольких потоках, то смотрите, что будет если во время выполнения кода в каком-то из потоков случится задержка, и как отрабатываются подобные кейсы.
Излишняя оптимизация
Как писал классик Дональд Кнут, преждевременная оптимизация – корень всех зол. Оптимизировать лучше только то, что нужно здесь и сейчас.
Отрабатываем ошибки
Обратите внимание, как поведет себя проект, если не удалось выполнить строчку кода, блок кода или запрос на сервер. Часто разработчики прерывают выполнение функции без вывода ошибок, но подобные кейсы необходимо прорабатывать.
Соответствие договоренностям
Код должен соответствовать договоренностям, код стайлу. Единообразие кода – не прихоть, а необходимость: такой код легче поддерживать, и в таком коде легче разбираться.
Наименования и внешний вид
Помните о других программистах, которым придется разбираться в вашем коде. Читабельный код упрощает его дальнейшую поддержку. Имена должны быть понятные и точно описывать класс, объект, функцию и т.д.
Комментарии к коду
Комментарии должны отвечать на вопрос: «почему так сделано?», а не «как это сделано?». Запомните это.
Часть 2. Обсуждаем
Главное правило обсуждения: любой комментарий должен быть нацелен на код, а не на человека, который его написал. Работает и в обратную сторону – не стоит воспринимать комментарии как критику Вас лично. Задача code review сделать Ваш код лучше, ведь то, что не заметили Вы, могут заметить другие. Коллеги могут предложить альтернативные решения, и в этом заключен потенциал для профессионального роста. Важно помнить, что обсуждение кода – это не состязание в остроумии и не показательное шоу «кто больше знает», поэтому сарказм, скрытая агрессия и хамство в нем неуместны.
Как правило, pull request проводят на специальных web-хостингах (github.com, bitbucket.org, gitlab.com и др.), где есть возможность просмотреть изменения и оставить комментарий к определенному фрагменту кода.
Соблюдаем договоренности
Повторим, код должен соответствовать договоренностям. Однако если таких договоренностей не существует, не стоит просить коллегу добавить пробел или отступ в коде.
В спорных моментах можно договориться всей командой прямо в процессе code review, но просить соблюдать эти правила лучше на следующих code review, так всем будет легче их принять. Кстати, задокументированный гайдлайн по стилю написания убирает практически все споры.
Предлагаем альтернативу
Избегайте высказываний типа «ты сделал не так. », «зачем, почему ты так пишешь?» и др. Они воспринимаются как критика и ведут к оправданиям. Лучше писать комментарий про содержание кода, без обращения к личности автора. Также старайтесь избегать приказов и принуждений: люди не любят, когда им кто-то приказывает, и воспринимают такие комментарии негативно.
Можно действовать по следующей схеме:
Остаемся в рамках задачи
Часто можно увидеть комментарии к коду, который был раньше и никак не трогался. Не надо комментировать то, что не относится к задаче. Любые сторонние правки могут занять много времени, да и восприниматься могут негативно, поэтому лучше смотреть на то, как человек выполнил текущую задачу, а не просить его рефакторить проект.
Хвалим
Если видите интересное или крутое решение, не стесняйтесь хвалить. К тому же, это отличная мотивация для ваших коллег продолжать писать хороший код в дальнейшем.
Все комментарии равны
Часто бывает, что один программист технически знает больше другого, что подтверждается градацией junior, middle, senior, team lead. Не стоит выделять комментарии одной группы как более важные. Это обесценивает мнение части разработчиков, что может привести к равнодушию и формальному участию в code review. Когда мнение всех одинаково важное, code review проходит продуктивнее.
Четко выражаем свои мысли
Для продуктивного общения пишите максимально развернуто и объясняйте каждую деталь. У всех разный уровень знания, а читать мысли еще пока никто не научился.
Задаем вопросы
Не стесняйтесь спрашивать своих коллег, чем их предложенный вариант лучше текущего вашего. Это отличная возможность узнать что-то новое и вырасти профессионально.
Решаем конфликты
Случается, что человек не принимает все доводы и своих предложить не может, отказывается что-то делать. Несколько практических советов на этот случай:
Часть 3. Улучшаем процесс
Описываем, что сделали
Описываем в заголовке pull request (или выносим в отдельный комментарий) суть задачи и какие шаги были проделаны для ее выполнения.
Делим pull request на части
Большой кусок будут долго смотреть, долго обсуждать и долго исправлять. Поделите код на небольшие логические части – так процесс пойдет гораздо быстрее.
Отвечаем на все комментарии
Желательно отвечать на каждый комментарий, чтобы в команде не возникало недоговоренностей. Другие разработчики должны понимать, что Вы прочитали их комментарий, проделали необходимую работу и внесли исправления. Постоянно открывать pull request и смотреть, что было поправлено, а что нет, очень неудобно и отнимает много времени.
Искать все?
Существуют разные подходы – искать максимум из возможного или комментировать сначала важные архитектурные моменты, а после исправления обращать внимание на мелочи.
Оба способа имеют право на жизнь. Я считаю, что второй вариант более трудозатратный: представьте, что после исправления надо полностью просматривать код еще раз, комментировать и снова ждать исправлений. Куда быстрее тщательно пройтись по коду один раз, оставить комментарии и потом проверить исправления.
Если есть архитектурные неточности и понятно, что мелкие ошибки сами исчезнут после исправления архитектуры, не стоит тратить время на комментирование мелочей в этом участке кода.
Ждать всех?
Можно не ждать пока pull request одобрят все и договориться, что одобрения 80% ревьюверов достаточно для закрытия задачи. Это ускорит попадание кода в основную ветку, что несомненно более выгодно для бизнес-процессов, но может привести к разногласиям в команде и равнодушию к code review.
Второй вариант – обязательно ждать одобрения всех причастных разработчиков. Качество кода вырастет, но сам процесс замедлится значительно. Выбор в пользу скорости или качества каждая команда должна принимать самостоятельно.
Мелочи
Если к коду нет серьезных замечаний, то не нужно ждать, когда будут убраны все маленькие неточности. Их можно указать в комментарии и сразу одобрить pull request – автор кода будет чувствовать себя спокойнее, повысится его лояльность к команде, почувствует, что ему доверяют. И, конечно, скорость прохождения pull request возрастет.