Peer / Code Review разочарования

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

Чтобы добиться этого, я представил своей команде концепцию экспертной оценки. Два больших пальца в github pull-запросе на слияние. Отлично - но не на мой взгляд без икоты.

Я часто вижу комментарии рецензентов от таких же коллег, как -

• Было бы хорошо добавить пробел после <INSERT SOMETHING HERE>
• Нежелательная лишняя строка между методами
• Полная остановка должна использоваться в конце комментариев в docblocks.

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

• Вы можете уменьшить цикломатическую сложность ...
• Выходите пораньше и избегайте если / еще
• Абстрагируйте ваш запрос к базе данных в хранилище
• Эта логика на самом деле не принадлежит здесь
• Не повторяйте себя - абстрагируйтесь и используйте повторно
• Что произойдет, если Xбудет передано в качестве аргумента метода Y?
• Где для этого модульный тест?

Я считаю, что это всегда одни и те же люди, которые дают косметические типы обзоров, и те же самые люди, которые, по моему мнению, дают «рецензии на основе качества и логики».

Что (если таковые имеются) является правильным подходом к рецензированию. И прав ли я в том, что разочарован теми же людьми, которые в основном бегают по коду в поисках орфографических ошибок и эстетических дефектов, а не реальных дефектов кода?

Если я прав - как бы я побудил коллег на самом деле искать ошибки в коде в сочетании с предложением косметической коррекции?

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

С моей точки зрения, обзор кода касается совместной ответственности за код. Я бы не чувствовал себя комфортно, давая большой палец к коду без адресации / проверки логики, читабельности и функциональности. Я также не стал бы блокировать объединение для твердого куска кода, если бы заметил, что кто-то пропустил точку остановки в doc-блоке.

Когда я просматриваю код, я трачу примерно 15-45 минут на 500 лок. Я не могу себе представить, чтобы эти поверхностные обзоры занимали больше 10 минут, если они занимают такую ​​глубину. Кроме того, сколько стоит большой палец от мелкого рецензента? Конечно, это означает, что все большие пальцы не имеют одинаковый вес, и, возможно, необходимо выполнить процесс проверки в два прохода. Один большой палец для глубоких обзоров и второй большой палец для «полировки»?

Типы отзывов

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

Типы рецензентов

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

Экспертная оценка - это сотрудничество, а не игра в теги

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

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

Совет

К концу вашего вопроса вы написали:

как бы я побудил коллег на самом деле искать ошибки в коде в сочетании с явными эстетическими ошибками?

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

На более прагматичной ноте я лично делю комментарии проверки кода на два лагеря и формулирую их соответствующим образом: вещи, которые нужно исправить, и вещи, которые более косметичны. Я бы никогда не помешал проверке работоспособного кода, если в конце файла было слишком много пустых строк. Я, однако, укажу на это, но сделаю это с помощью чего-то вроде: «В наших рекомендациях говорится, что в конце должна быть одна пустая строка, а у вас есть 20. Это не шоу-стопор, но если у вас есть шанс, может захотеть это исправить ".

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

Что делать после обзора

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

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

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

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

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

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

Вот практический ответ:

Сценарий 1 : Вы являетесь старшим участником и тем, кто может решить практику

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

Сценарий 2 : Вы не тот, кто решает практику, или вы относительно младший член команды

Лучше всего просто решить проблемы с проверкой кода, пока не достигнете сценария 1 .

Простой ответ для предотвращения «банальных» комментариев к коду - это настаивать (ради эффективности) на том, что рецензент должен их исправить. Так что, если рецензент обнаружит, что вы (ужас!) Пропустили полный останов или написали комментарий неправильно, он должен просто исправить это и двигаться дальше.

По моему опыту это означает, что:

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

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

Обзор процесса обзора

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

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

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

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

«Было бы неплохо, но это не заблокирует вас» (если все отзывы попадают в эту категорию, я могу отправить запрос на слияние со словами «произойдет слияние в XX: XX, если вы не скажете мне, что хотите их исправить») , или «конечно, продолжайте, чтобы проверить, какой блок, который бросит система, был отключен»):

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

«Вещи, которые нужно исправить, но я верю, что ты это сделаешь» (если все вещи попадают в эту или предыдущую категорию, я отвечу «исправить это, я сливаюсь, когда ты мне скажешь» готово "(и в этот момент я, вероятно, быстро отсканирую, чтобы увидеть, что больше ничего не появилось)):

• Незначительные придирки («вы сравниваете логическое значение trueс немного параноидальным ...», ...)
• Незначительные нарушения стиля («в руководстве по стилю написано X, то, что вы сделали, находится за пределами этого; я бы сделал Y или Z, в зависимости от того, каким путем вы хотите идти»)
• Несколько пропущенных тестовых примеров, которые не должны быть трудными для написания

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

• Это может быть что-то вроде «нет, на самом деле есть НАМНОГО лучший способ написать это», «вы не вычисляете то, что ожидаете, потому что ваш модульный тест пропускает эти крайние случаи» и все другие серьезные проблемы.

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

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

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