Какой самый эффективный способ проверки кода? [закрыто]

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

Каков был наиболее эффективный способ проверки кода?

Например:

• Один человек считается привратником качества и проверяет код, или команда владеет стандартом?
• Вы просматриваете код как командное упражнение, используя проектор?
• Это сделано лично, по электронной почте или с помощью инструмента?
• Вы отказываетесь от обзоров и используете такие вещи, как парное программирование и коллективное владение кодом, чтобы гарантировать качество кода?

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

Если вы знаете, что ваш код будет пересмотрен, это заставит вас сначала просмотреть его. Многие проблемы становятся очевидными тогда. В нашей системе вы должны объяснить рецензенту, что вы сделали, что снова заставит вас заметить проблемы, которые вы, возможно, пропустили раньше. Кроме того, если что-то в вашем коде не сразу понятно рецензенту, это является хорошим признаком того, что требуется лучшее имя, комментарий или рефакторинг. И, конечно, рецензент может также найти проблемы. Кроме того, кроме просмотра изменений, рецензент может также заметить проблемы в соседнем коде.

У этой системы есть два основных недостатка. Когда изменение тривиально, нет смысла его пересматривать. Тем не менее, мы должны строго придерживаться правил, чтобы избежать скользкого уклона, чтобы объявить изменения «тривиальными», когда их нет. С другой стороны, это не очень хороший способ просмотра значительных изменений в системе или добавления крупных новых компонентов.

Мы уже пробовали проводить более формальные обзоры, когда один разработчик отправлял по электронной почте код для проверки остальной части команды, а затем вся команда собиралась и обсуждала его. Это заняло у каждого много времени, и в результате эти обзоры были редкими, и только небольшой процент базы кода был рассмотрен. «Еще один человек проверяет изменения перед фиксацией» для нас гораздо лучше.

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

Если это сделано группой с проектором, это действительно должно быть рассмотрено индивидуально перед встречей. В противном случае это просто досадная трата времени.

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

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

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

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

Я думаю, что это плохая идея иметь одного рецензента кода привратника по многим причинам. Этот человек становится узким местом, и ему приходится делать слишком много рецензирования кода (просто для того, чтобы проект продолжал двигаться), чтобы быть действительно эффективным (60-90 минут за раз - это предел эффективности). Обзоры кода - отличный способ поделиться идеями и знаниями. Независимо от того, какой суперзвездой является ваш привратник, они могут учиться у других в команде. Кроме того, если все будут выполнять проверку кода, это также создает среду «коллективного владения кодом», в которой люди чувствуют, что им принадлежит качество кода (это не только контроль качества или привратник).

У нас есть бесплатный информационный бюллетень « Рекомендации по проверке кода в одноранговой сети », в котором есть 11 советов по эффективному анализу кода. Во многом это то же содержание из книги, что Джон упомянул в более искаженном виде.

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

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

На данный момент, по моему опыту, лучше всего назначить одного человека «королем» проверки кода, если хотите, и то, что он / она говорит. В связи с этим, если один пользователь не придерживается стандартов, король позаботится об этом.

Как разработчик, я много раз пересматриваю свой собственный код, чтобы быть читабельным, понятным и все остальное. Обычно мы используем javadoc или аналогичные в определенных языках, с которыми мы кодируем, и используем тег @author для привязки прав собственности к функциям, классам и т. Д.

Если функция не верна, мы говорим с владельцем, то же самое с классом и т. Д.

В моей компании каждому заданию назначается тестировщик для проверки задания, а также проверяющий код для проверки кода.

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

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

Одна важная вещь в проверке кода - она ​​может отлавливать ошибки, которые мы совершаем, но не является заменой для тестирования.

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

Не спорьте о плюсах и минусах спаривания, но трудно оспорить положительный эффект от постоянного пересмотра вашего кода (по крайней мере) другим человеком. Код даже написан и спроектирован (по крайней мере) двумя программистами - он вряд ли может стать лучше. Я говорю «по крайней мере», потому что, imo, вы должны стараться много переключать пары, чтобы каждый получил шанс на работу с кодом.

Одна из вещей, которые я пытаюсь сделать в обзорах кода, в которых я участвую, заключается в том, что после самостоятельного анализа кода я выполняю статический анализ кода, используя такие инструменты, как Findbugs, PMD, JavaNCCP и др., И смотрю на любые проблемы, с которыми сталкиваются эти инструменты. код для пересмотра. Я особенно хочу посмотреть на все, что имеет необычайно высокий уровень сложности, попросив их объяснить, почему этот уровень сложности необходим или почему предлагаемая уязвимость не важна.

YMMV

Там, где я сейчас работаю, мы производим аппаратные устройства и программное обеспечение, которое взаимодействует с ними и подходит для критически важной инфраструктуры. Следовательно, мы уделяем большое внимание качеству релизов. Мы используем вариант Fagan Inspection и проводим официальный процесс проверки. Мы сертифицированы по стандарту ISO 9001, в том числе.

Индустрия критической инфраструктуры очень заинтересована в надежности и повторяемости. :-)

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

Эта система работает хорошо - проверки выполняются, если позволяет время, и изменения могут просматриваться несколькими наборами глазных яблок.

Отличный и бесплатный инструмент Board Review работает для нас очень хорошо и зарекомендовал себя как отличный способ распространения отзывов.

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

Что мы делаем, так это то, что каждый раз, когда мы чувствуем, что проверка кода будет полезной, мы добавляем комментарий «todo: code review by joe» к измененному коду. Обычно мы выбираем Джо, потому что он владеет модифицированным кодом, но если этот критерий выбора не применяется (обычно так и есть), мы просто выбираем кого-то другого случайным образом. И, конечно, если Джо окажется доступным в то время, мы используем старый добрый метод проверки через плечо.

Как рецензент, единственное, что вам нужно сделать, это периодически искать во всем коде «// todo: проверка кода мной» , просматривать изменения и проверять код обратно без комментария «todo ...».

Если есть проблема, мы возвращаемся к традиционным методам общения (почта / чат / и т. Д.).

Этот метод предоставляет нам два основных качества, которые мы ищем в системе обзора:

• очень легкие над головой
• прослеживаемость

Мы считаем, что наиболее эффективный способ проверки кода - 1-на-1 с использованием github, чтобы показать различия в ветке.

• Один человек считается привратником качества и проверяет код, или команда владеет стандартом?

  • Зависит от размера команды - команда из 3 человек будет иметь 1 старшего, который лучше всех знает хорошие практики, в то время как команда из 12 может иметь 3 или 4 человека, которые будут выполнять эту роль.

• Вы просматриваете код как командное упражнение, используя проектор?

  • Лично. 1 на 1, чтобы быть менее угрожающим. Иногда делается в коммунальной сфере, хотя для распространения знаний. Зависит от конкретной ситуации, людей, графика и т. Д.

• Это сделано лично, по электронной почте или с помощью инструмента?

  • Лично. Мы используем git и github, и у него есть отличные инструменты для анализа кода и сравнения сравнения, чтобы сделать обзор кода проще.

• Вы отказываетесь от обзоров и используете такие вещи, как парное программирование и коллективное владение кодом, чтобы гарантировать качество кода?

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

Как и во всех элементах кодирования, правильный ответ должен учитывать:

• Тип компании (например, стартап против крупной корпорации)
• Размер компании
• Количество разработчиков
• бюджет
• Период времени
• Нагрузка
• Сложность кода
• Способность рецензента (ов)
• Наличие рецензента (ов)

Я работал во многих компаниях и видел много процессов. Моя нынешняя команда справляется с этим лучше всего, что я когда-либо видел.

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

Кроме того, мы храним наш код на github.com. Таким образом, после того, как разработчик заканчивает свое изменение, он публикует ссылку на коммит (ы) в истории.

Затем мы помечаем другого разработчика для обзора. Github имеет систему комментариев, которая позволяет кому-то комментировать прямо в строке кода. Затем Github отправляет электронное письмо в дистрибутив, поэтому иногда мы получаем дополнительные взгляды от некоторых других наших команд.

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

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

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