Как поощрить начинающих разработчиков участвовать в обзоре кода?

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

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

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

Для меня вопрос здесь заключается в следующем: «Что вы ищете для своих младших разработчиков, чтобы получить доступ к обзорам кода?». Для меня потенциально самое важное - научить начинающих разработчиков смотреть на хороший код; если они обнаружат проблемы в вашем коде, это бонус.

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

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

Проводите встречи по пересмотру кода лично в назначенное время каждую неделю. Я продал это своему товарищу по команде, вот так (мы на самом деле оба старшие разработчики, но все что угодно):

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

Мне нравится думать об этом как о шоу-и-рассказать. Люди могут показать свою работу своим сверстникам. Дело не в том, что ваши сверстники находят что-то неправильное в вашей работе, что никому не нравится. Речь идет о том, чтобы произвести впечатление на ваших пэров своим потрясающим кодом, который всем нравится.

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

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

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

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

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

Как примечание: если у вас есть среда, в которой никто не может дать или принять конструктивную критику, у вас есть проблема.

Процесс: кто-то хочет совершить свои изменения. Кто-то назначен рецензентом и проверяет изменения. Затем проверенные и исправленные изменения отправляются на тестирование.

Если при тестировании обнаруживаются ошибки, внесенные в изменение, виноваты в равной степени и автор, и рецензент.

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