Когда самое эффективное время для просмотра кода?

Ответ 1

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

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

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

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

Проверьте этот вопрос для некоторых ресурсов для просмотра кода. Также ознакомьтесь с кодовым сотрудником.

Ответ 2

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

Обзор дизайна выполняется при разработке функции (как она будет реализована, какие модули задействованы, как она называется, кто она звонит, какие глобальные/локальные данные она использует, влияет на обработку, другие модули, I/O, какие требования он встречает, специальные угловые случаи и т.д.) Является полным и документированным.

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ничто не хуже, чем чтение страниц и страниц кода другого человека. Это просто человек, который начнет снижаться и не ставит 100% усилий в 100% случаев

Ответ 6

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

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

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

Ответ 7

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

Сколько отзывов зависит от вас, в зависимости от времени и других факторов.

Ответ 8

Я нашел наиболее эффективную форму проверки кода - это просмотр кода в режиме реального времени; то есть просматривать его во время его написания в качестве активного участника в разработке и реализации кода.

Ответ 9

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

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

В зависимости от "размера раскрытия недостающего, но существенного" (-: во время разработки я бы быстро просмотрел прогресс и обновления.

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

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

Ответ 10

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

Ответ 11

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

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

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

Затем предложение может быть прокомментировано всеми заинтересованными сторонами и заданными вопросами (wiki делает это хорошо). Оригинальные авторы могут пересмотреть предложение на основе обратной связи один или два раза. Реализация начинается, если не указано особо большое значение "gotcha".

Специфика реализации (например: код) должна быть пересмотрена только тогда, когда появляется первая применимая реализация и может быть проведено тестирование кода. Предполагается, что индивидуум должен следовать пересмотренной версии предлагаемого ими предложения.

Ответ 12

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

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