Компания, в которой я работаю, требует, чтобы весь код был проверен другими разработчиками до его принятия. Члены моей команды часто бывают разочарованы, потому что другие разработчики слишком заняты написанием кода, чтобы делать обзор, особенно если он очень длинный. Как вы стимулируете других разработчиков делать своевременные обзоры кода?
(Мы используем git-svn, поэтому мы можем продолжить кодирование в ожидании обзора. Однако я все еще расстраиваюсь, когда мне приходится долго ждать, прежде чем я смогу зафиксировать свой код.)
code-reviews
titaniumdecoy
источник
источник
У вас есть ряд вопросов для решения - вы должны завоевать сердца и умы, и вы должны убедиться, что есть время для проверки кода.
Вторая часть, вероятно, самая простая - вы соглашаетесь (коллективно, и это должно включать управление), что первое, что делает разработчик каждое утро, это свои обзоры кода - это просто, понятно, эффективно и дает вам хорошую ясную подсказку, чтобы побить людей если они не соответствуют. Более того, вы ничего не мешаете, вы не просите их прекратить работу над своим кодом, вы не просите людей втиснуть что-то в их список дел ...
Первая часть - это реальная проблема - участники процесса обзора должны видеть, что он имеет значение, иначе они никогда не выполнят обзор кода (который считается не имеющим значения), когда они могут писать код или исправлять ошибки (которые конечно важнее ...?).
Если вы можете соединить их вместе - во-первых, убедившись, что все верят (или понимают), что в обзорах кода есть ценность, - в самом основном это должно означать меньше ошибок, что означает больше нового кода, что обычно более увлекательно, - а затем, во-вторых, организовать чтобы в расписании было свободное место для пересмотра кода, и, надеюсь, хорошие вещи произойдут ... это станет частью культуры.
Когда-то это стало частью культуры, возможно, больше нет необходимости говорить «первым делом каждый день» - но, сказав, что я думаю, что это хорошо вписывается в шаблон, в котором, вероятно, хочется, чтобы разработчик работал.
источник
В большинстве компаний, в которых я работал, у вас есть 3 дня, чтобы завершить обзор. Недопустимо не делать отзывы. Это часть твоей работы. Если вы вовремя не делаете достойных обзоров, это влияет на вашу оценку производительности. И да, обзоры всегда бывают в самые неподходящие времена. Слишком плохо, учитесь включать время обзора в свои оценки. В любом случае, если руководство действительно считает, что проверки важны (т. Е. Они требуют, чтобы весь код проверялся), тогда они будут придерживаться аналогичной политики. Кроме того, если люди не завершают обзор в отведенное время, это означает, что они согласились с материалом.
источник
Подумайте об использовании такого инструмента, как Review Board . Это очень полезно, особенно для длинных обзоров.
Вы можете загрузить свои различия и подождать, пока рецензент не закончит обзор. Если у вас есть открытые обзоры, которые мешают вам продолжать работу, вы можете сообщить об этом во время ежедневных собраний (ваша команда хочет, чтобы новые функции были проверены, чтобы их можно было проверить как можно скорее, не так ли?).
источник
Несколько моментов, которые нужно добавить, которых нет в других ответах.
Код для проверки должен быть проверен в
Задачи блокирования имеют приоритет, поэтому проверки кода должны иметь приоритет над другими работами (но не пытаться нарушить ваш поток). Как разработчик, вы должны хотеть, чтобы другие просмотрели ваш код (поскольку вы стремитесь сделать его лучше). В этом знании вы должны выполнять обзоры для других в кратчайшие сроки.
Сложнее задать вопрос, когда и как хорошо выполнять проверку кода.
Правило, которое сработало для нас в том случае, когда общий код должен быть пересмотрен, поскольку он имеет более широкое влияние, тогда как в коде для отдельного приложения (особенно если мы используем разработку через тестирование) это менее важно.
источник