Как избежать политики в обзорах кода? [на удержание]
Поэтому я пытаюсь представить обзор кода своим командам. Но значительное число коллег опасаются, что политический аспект может разрушить хорошую командную работу.
Сталкивались ли вы с проблемами политики при проверке кода? Если да, то как этого избежать?
Или, точнее, как сделать правильный обзор кода, чтобы в нем было меньше политики?
6 ответов:
Edit: Если вы подходите к рецензии как к упражнению "я вам не доверяю, поэтому мне нужно проверить, что вы делаете", то вы упускаете основную причину для рецензий, и любой отзыв, скорее всего, будет менее успешным.
Предположения автора о том, что его собственный код совершенен каждый раз, если не оптимистичны, то, по крайней мере, ошибочны.Люди-люди, и они могут и будут упускать различные вещи из своего кода. Вторая или третья пара глаз будет довольно часто подхватывать то, что автор совершенно упустил из виду. Иногда эти вещи могут быть ослепительно очевидны и все же все еще упущены автором кода.
Существует несколько проверенных способов обеспечения успеха обзоров:
Как отметил Нил Б., в проверке могут участвовать только члены команды, участвующие в работе над кодом. Если, конечно, нет веской причины иначе, например, команда использует утилиту или, возможно, промежуточное программное обеспечение, написанное другой группой, и вы хотите проверить свое использование из предоставленной утилиты / middleware / etc. Подчеркните, что проект-это коллективное усилие, и команда должна работать вместе, чтобы гарантировать, что проект, то есть индивидуальный вклад каждого, объединенный вместе, является лучшим, что они могут сделать. Это не кусок Дэва а, который был лучше, чем кусок Дэва Б.
- подчеркните возможности обучения, доступные команде от членов команды, участвующих в обзоре. Там накоплен многолетний опыт работы типичной команды разработчиков программного обеспечения. как правило, довольно крупные. Собрать весь этот опыт вместе в одном направлении, чтобы убедиться, что лучший продукт выходит за дверь,-это очень мощный инструмент, особенно для обучения менее опытных членов команды.
- Всегда подчеркивайте, что речь идет о рассматриваемом коде. Не человек.
- Всегда Используйте такой язык, как "эта функция не проверяет отрицательные входы", а не "вы забыли проверить отрицательные входы"
- Не позволяйте долго обсуждения / отклонения / обоснования в обзоре.
Во время обзора возможны только три ответа: принять изменение, отклонить изменение, перейти в автономный режим для последующего обсуждения.- фрагменты кодадолжны быть предоставлены перед началом работы.
- Все участники обзора, кроме ведущего, который руководит совещанием по обзору, должны прочитать код заранее.
- должно быть запланировано время, чтобы рецензенты могли прочесть код.
Кстати, вы можете посмотреть наFagan inspections , который еще больше углубляет вышеупомянутые пункты.
Edit: Извините, но я забыл упомянуть, что вы должны иметь некоторые стандарты кодирования. В противном случае ваши обзоры легко опустятся до "священных войн" с битвами, такими как:
- стиль скобок,
- вкладки или отсутствие вкладок в источнике,
- уровни отступов 4 пробелов или 8 пространств
- и т. д.
Наличие стандарта кодирования устраняет такие дискуссии из уравнения. Имейте в виду, что у вас все еще будут такие, э-э, "захватывающие" дискуссии при создании стандартов кодирования! ;- )
Если вы боитесь политики, не называйте их с самого начала" кодовыми обзорами", а скорее публично и постепенно вводите некоторые :
- стандарты именования
- соглашения о кодировании
- правила развития (например, всегда делать определенную вещь определенным образом или никогда не делать определенную вещь)
- руководящие принципы развития
- лучшие практики разработки
- и т. д.
Все это во имя улучшения ремонтопригодности, читабельности, уважения стандарты, уменьшение ошибок и т.д.
Применяя их понемногу, вы будете делать свои обзоры кода, но основное внимание будет уделяться улучшению существующего кода ( с позитивной коннотацией ), а не обвинению кого - то в написании плохого кода ( "обзор кода" может быть легко воспринят как негативная вещь-Эй, я знаю, что вы пишете плохой код, или я не доверяю вам, поэтому мне нужно проверить, что вы делаете)
Если ваши команды разработчиков вовлекаются в большую политическую борьбу, вылечите эту борьбу, прежде чем пытаться делать обзоры кода. Кроме того, обзор обычно должен проводиться только командой, написавшей код - обзоры не предназначены для того, чтобы позволить какому-либо тому, Дику или Гарри приходить и делать комментарии.
Первый обзор. Не приносите такие вещи, как "ОК, ребята, теперь я буду на вашем soulder, лучше иметь какую-то хорошую вещь, чтобы показать мне".
Я нашел эту статью в блоге чрезвычайно полезной, когда мы представили обзоры кода:
Http://www.basilv.com/psd/blog/2007/strategies-for-effective-code-reviews
С уважением, Ованес