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

13

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

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

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

Грэм С
источник
2
Интересно, может быть, это не лучший вопрос для Workplace.SE, но мои собственные 2 цента как младший разработчик. В то время как я был стажером, я очень нервничал по поводу участия в обзорах кода по нескольким причинам: отсутствие навыков, отсутствие знакомства с базой кода и т. Д. Вскоре я обнаружил, что участие в обзоре кода помогло с обоими этими аспектами ( особенно знакомство), и было очень полезно, заставив меня почувствовать, что наша кодовая база была чем-то, что меня интересовало, поэтому я хотел внести свой вклад. Я определенно не всегда оставлял хорошие комментарии, но я не знал, пока я (продолжение)
Dannnno
2
(продолжение) попытался, и это помогло мне лучше работать с командой в целом. Я думаю, что если вы попытаетесь объяснить, почему это полезно для вас, команды и базы кода для их участия, даже если их комментарии неверны; если их комментарии неправильны, это почти лучше, потому что тогда они могут извлечь из этого уроки.
Данннно

Ответы:

15

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

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

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

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

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

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

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

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

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

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

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

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

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

JeffO
источник
-3

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

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

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

gnasher729
источник
5
1) Назначение «вины» за ошибки - отличный способ заставить ваш персонал уйти 2) Назначение вины младшему персоналу за неспособность обнаружить ошибки, написанные старшим персоналом, вдвойне плохо.
Филипп Кендалл
2
@PhilipKendall Если мой код содержит ошибку, никто не должен винить меня. Я профессионал и очень горжусь своей работой. Это что-то вроде нового века, когда никто не делает ничего плохого, и каждый получает трофей за участие?
Джеффо
@PhilipKendall: я не знаю, где ты работаешь ... Где я работаю, я скажу «какая глупая ошибка, которую я совершил», а рецензент скажет «и я тоже ее пропустил», а потом мы оба рассмеялись. «Вина» означает брать на себя ответственность, а не стоять в углу с тупой шляпой.
gnasher729
1
@ gnasher729 Да. Но никто не попадает "в беду" за это.
Филипп Кендалл