В настоящее время я работаю старшим разработчиком с тремя младшими учениками ниже меня и внедрил процесс проверки кода, чтобы помочь управлять качеством кода, поступающего в производство.
Я считаю, что для всех нас очень полезно проверять работу друг друга, однако примерно через 5 недель процесса я единственный, кто оставил какие-либо комментарии в инструменте (BitBucket).
Я думаю, что есть некоторые культурные проблемы на работе, и, возможно, естественное нежелание в случае, если их комментарии неверны, но есть ли способ, и я могу помочь юниорам чувствовать себя более комфортно, критикуя мои, а все остальные работают?
Ответы:
Для меня вопрос здесь заключается в следующем: «Что вы ищете для своих младших разработчиков, чтобы получить доступ к обзорам кода?». Для меня потенциально самое важное - научить начинающих разработчиков смотреть на хороший код; если они обнаружат проблемы в вашем коде, это бонус.
Если вы ищете, чтобы ваш младший персонал учился на обзорах кода, самое важное, что вам нужно сделать, - это создать среду, в которой обучение ценится, а не рассматривается как пустая трата времени. Это означает ряд вещей:
источник
Проводите встречи по пересмотру кода лично в назначенное время каждую неделю. Я продал это своему товарищу по команде, вот так (мы на самом деле оба старшие разработчики, но все что угодно):
«Обзор кода частично предназначен для того, чтобы я немного лучше узнал ваш код и узнал, что происходит на вашей стороне, если вы когда-нибудь столкнетесь с грузовиком, и мне приказано закончить ваш спринт. Но в основном это для вас, чтобы объяснить свой код кому-то еще, потому что когда вы делаете это, он затрагивает другую часть вашего мозга, и часто ваше объяснение им, и / или их вопросы или комментарии, может заставить вас вспомнить что-то, что вы забыли сделать в коде, или может заставить вас реализовать лучший способ сделать его более читабельным или лучше его спроектировать. Это приведет к более красивому коду. "
Мне нравится думать об этом как о шоу-и-рассказать. Люди могут показать свою работу своим сверстникам. Дело не в том, что ваши сверстники находят что-то неправильное в вашей работе, что никому не нравится. Речь идет о том, чтобы произвести впечатление на ваших пэров своим потрясающим кодом, который всем нравится.
Однако я думаю, что использование инструментов проверки кода, где нет человеческого взаимодействия, нет встречи в комнате, нет доски ... это становится просто еще одной раздражающей «вещью», которую нужно сделать. Это не значит, что таких инструментов не должно быть, но они должны быть чем-то, к чему вы должны прибегнуть, если во время совещания по рассмотрению кода обнаружится, что может потребоваться более глубокий анализ определенного раздела кода. Затем вы можете назначить одного из младших разработчиков для просмотра кода другого в определенной области.
источник
Вы можете помочь, подав хороший пример. Вы не можете защищаться, когда кто-то указывает на ваши ошибки. Сделайте обзор кода на свой собственный код и отметьте области улучшения. Поделитесь этим с командой. В конце концов, они узнают, что это поощряется, и никто не будет побежден за ошибку в своем коде.
Иметь работу означает брать на себя ответственность и гордость за свою работу. Если проверка кода является частью этого, то участие в проверке кода должно быть включено в оценки. Я посещал онлайн-классы, где участие в онлайн-дискуссиях является частью класса. Комментарии должны быть разработаны. «Я согласен» не приемлемо.
Проверка кода должна улучшить код. В зависимости от вашей ситуации это может быть измерено по количеству продаж, жалобам пользователей или другим оценкам, если вы пишете код для внутреннего использования. Реальность такова, что ваш код служит какой-то цели, и ваша команда должна измеряться тем, насколько хорошо они служат этой цели. Те, кого вы определяете, способствуют успеху, получают пропорциональную долю в наградах.
Сосредоточьтесь на выпуске качественного кода. Цель состоит не в том, чтобы каждый чувствовал себя хорошо, избегая ошибок. Я пишу плохой код; Я должен исправить плохой код. Это работа и жизнь. Я ненавижу исправлять ошибки, поэтому стараюсь их избегать. Я горжусь своей работой, поэтому меня беспокоит, когда мой код не работает. Я чувствую себя плохо из-за пользователей или кого-то еще, кто не торопится указывать на эти вещи, и это мотивирует меня хотеть это исправить.
Как примечание: если у вас есть среда, в которой никто не может дать или принять конструктивную критику, у вас есть проблема.
источник
Процесс: кто-то хочет совершить свои изменения. Кто-то назначен рецензентом и проверяет изменения. Затем проверенные и исправленные изменения отправляются на тестирование.
Если при тестировании обнаруживаются ошибки, внесенные в изменение, виноваты в равной степени и автор, и рецензент.
Таким образом, выполнение обзора без каких-либо комментариев доставит вам неприятности, если код не будет идеальным.
источник