Вы просматриваете запрос на слияние. Вы видите переменную, которую нужно переименовать. Или комментарий, который следует перефразировать. Или какая-то логика if/else, которая может быть защитным предложением.

Следует ли прокомментировать PR или оставить его без внимания?

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

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

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

И да, даже придирка — это возможность. Вот как можно придираться к проверкам кода:

Префикс с «Nit:»

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

Дайте рекомендацию, а не команду.

Придирки всегда субъективны. Это вопрос личных предпочтений. Язык должен указывать на то, что вы признаете это.

Дайте четкое предложение в коде.

GitHub упрощает внесение четких, предлагаемых изменений — используйте их.

Если придирка — ваш единственный комментарий, одобрите PR.

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

Вот анатомия хорошей придирки:

Придирка выше:

  • ✅ Префиксы с «Nit:»
  • ✅ Дает рекомендации
  • ✅ Объясняет, почему
  • ✅ Дает четкое предложение в коде
  • ✅ Не блокируется (проверен PR)

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

Как только вы начнете так придираться, вы никогда не вернетесь.

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

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

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

Нравится эта статья?

Посмотрите мой видеокурс — Master the Code Review! Лицензии доступны для индивидуалов и команд. 🎥