Как потерять друзей и заставить всех себя ненавидеть, делая код-ревью

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

Эти советы сугубо субъективные, они собирались путем ошибок (в том числе моих), набивания шишек, на основании моего жизненного опыта и опыта моих друзей и коллег. С течением времени менялась команда, одни люди уходили из нее, другие появлялись, но ревью всегда оставалось непростым процессом. Мы выработали некоторые правила его проведения, которые позволяют добиться продуктивности и избежать конфликтов. Сразу оговорюсь, здесь не рассматривается “техническая сторона”, только ревью в разрезе взаимодействия человека с человеком.

Цели ревью

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

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

• держать команду в курсе того, что происходит на проекте

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

• способ получения знаний

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

Как ревьюить чужой код

• Ты оцениваешь код, а не человека

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

Плохой пример:

Почему ты обозвал переменную myVar??? Мы же уже обсуждали это на прошлой неделе! Это ни в какие ворота!

Так лучше:

Почему переменная названа myVar, а не myAwesomeVar? Название myAwesomeVar подошло бы лучше, т.к. оно лучше отражает то, для чего заведена переменная. Предлагаю записать это правило в документацию.

Старайтесь всегда избегать личной окраски в ревью.

• Не закрывай не глядя

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

• Замечания должны быть конструктивными

Замечания типа “бред”, “трэш”, “плохо” — это не наша история. Считаешь, что плохо — объясни, что именно плохо и предложи вариант, как сделать лучше. Замечания всегда должны быть конструктивными.

• Если есть какое-то непонимание, обсудите вживую

Если чувствуете, что не получается прийти к консенсусу, не надо устраивать дебаты в переписке. В большинстве случаев команда сидит за соседними столами. Если нет — можно в крайнем случае и по скайпу набрать. Опять же повторюсь, человеку свойственно в своей голове рисовать эмоциональную окраску, которой скорее всего нет. Так что вместо того, чтобы орать друг на друга капсом, поднимите голову и выясните свой вопрос. Я бы даже предложила правило: больше 4 комментариев (2 вопроса, 2 ответа) на один вопрос —> обсуждение вживую.

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

Нет, ну реально раздражает (хоть и сами грешны)).

Как реагировать на комментарии

• Главная цель ревью — помочь тебе

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

• Не надо делать очень большие ревью

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

• Пиши в описании, что сделано и зачем

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

• Отмечай уже решенные вопросы

Это нужно, чтобы быстрее ориентироваться в море комментариев. Многие системы позволяют пометить вопрос как resolved. Если нет — хотя бы условьтесь оставлять под комментарием слово “ done”.

• Много комментариев — это нормально

Этот пункт особенно касается новичков. Если вам оставили кучу комментариев в ревью — это не значит, что надо срочно увольняться и менять профессию. Среди этих комментариев могут быть вопросы и советы. Много комментов — просто показатель, что вы еще осваиваетесь. У нас были ревью с более чем двумя стами комментариями.

• Отвечай конструктивно

Самый плохой ответ на комментарий вот такой:

— Не лучше было бы сделать вот так: /*Пример решения*/? Это позволило бы решить проблему А и проблему Б.

— Нет

• Отвечай на вопросы

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

• Не стоит дергать коллег по 10 раз на дню, чтобы они посмотрели твое ревью

Это очень отвлекает. Мы завели правило — смотреть ревью дважды в день, в начале и в конце дня. Если коллеги забывают, тогда напомнить им.

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

источник