Как постепенно вводить обзоры кода?

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

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

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

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

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

Это тяжелая работа.

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

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

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

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

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

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

Есть ли хороший способ представить отзывы?

Вероятно, есть несколько хороших способов, в зависимости от вашей команды и преимуществ, которые вы надеетесь получить от обзоров, но любой подход будет иметь некоторые общие черты:

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

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

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

• обсудить поведение: укажите, что цель состоит в том, чтобы улучшить код и выработать общее понимание, которое поможет команде написать лучший код по всем направлениям, чтобы не смущать кого-либо, сводить счеты и т. д. Критика должна быть объективной и конструктивной, а не личной. Установление некоторых основных правил может помочь облегчить рассмотрение кода.

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

Начните с проведения начальной встречи, чтобы объяснить все вышеперечисленное и решить проблемы членов команды. Получите электронное письмо, документирующее процесс.

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

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

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

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

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

Этот подход работает, но он не идеален.

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