Должны ли мы попытаться просмотреть весь наш код?

18

В настоящее время мы модифицируем процесс разработки, и мне интересно, должны ли мы постараться сохранить 100% проверок наших коммитов.

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

  • Вы тратите на них «много» времени (скажем, 1/2 часа в день) или просто скользите в течение максимум 5/10 минут?
  • У вас есть фиксированное количество времени, которое вы проводите в день / неделю / спринт / проект?
  • Самое главное, считаете ли вы, что цель должна состоять в том, чтобы 100% кода было проверено коллегами или что в 100% нет необходимости?
Симеон
источник
Попробуйте потрогать 80% кода с 20% усилий. Инвестируйте в лучшие автоматизированные инструменты, которые можно купить за деньги.
Работа
2
Автоматизированные инструменты хороши, но становятся бесполезными, если у вас нет времени и ресурсов, чтобы поддерживать все тесты в актуальном состоянии.
Кирен Джонстон

Ответы:

19

У нас есть задача «Проверка кода» в каждой истории. Кто-то, в идеале не участвующий в разработке этой истории, рассмотрит все изменения кода, связанные с этой историей. Это работает хорошо.

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

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

Кстати, важно, чтобы кто-то еще делал обзор кода ..

Кирен Джонстон
источник
3
«Кстати, важно, чтобы кто-то другой проверял код…», подразумевает ли этот вопрос, что тот же человек, который пишет код, должен его просмотреть? Если это где? Я бы хотел это исправить :)
Симеон
4
Нет, это не так, я был всесторонним и сказал, что это важно
Кирен Джонстон
5
@Simeon - это на самом деле страшно распространенное заблуждение, что владелец может просмотреть свой собственный код. Это подрывает всю операцию
Tom Squires
5
@TomSquires: Точно. Когда вы долгое время работали с фрагментом кода, вы можете стать «слепым» к очевидным в противном случае недостаткам, потому что вы видите его таким, каким он должен быть, а не тем, чем он является. Эти проблемы легче обнаружить тем, кто никогда не видел код раньше. Писатели сталкиваются с той же проблемой, и так же, как книги не выпускаются без вычитки, код не должен выпускаться без рецензирования. Есть и другие преимущества для выполнения проверки кода, например, это хорошо для передачи знаний между членами вашей команды.
хаммар
@hammar - конечно, попытка найти кого-то, кто не написал код, у которого есть время, чтобы настолько близко познакомиться с ним, чтобы они могли его внимательно просмотреть, - это сложная задача
Питер Айтай
12

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

Сначала работайте над тем, чтобы сделать ваши отзывы более эффектными, затем определитесь с освещением.

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



Кроме того, обзоры не являются заменой для тестов и инструментов:

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



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

  • Код, который может содержать неопознанную ошибку, о которой было сообщено
  • В коде с этим недавно были обнаружены ошибки
  • Код с проблемами производительности (узкие места)
  • Код, написанный новыми разработчиками
  • Устаревший код, который недавно был обновлен кем-то, кто ранее не был знаком с ним
  • Код в новых областях
  • Существующий код, о котором вы хотите, чтобы новые разработчики узнали
  • Код, который решает сложные проблемы
  • Код, который был определен как сложный с помощью инструментов анализа

И помните, вы просматриваете код (или дизайн или тесты), а не авторов.



Я рекомендую следующие материалы для чтения:

Выборочные обзоры без работы
Лучшие секреты рецензирования кода

Дэнни Варод
источник
5

По-разному.

Это зависит от того, что делает ваше программное обеспечение:

  • Если он управляет электронным кардиостимулятором или космическим челноком, то определенно да.

  • Если это одноразовый прототип, то, вероятно, нет.

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

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

Стивен С
источник
5

Сначала вам нужно ответить на этот вопрос: почему вы просматриваете код?

С этим ответом в руках вы можете выяснить, какой код необходимо пересмотреть.

Некоторые обзоры кода выполняют именно то, что тестирование делает или сделало бы. Если это и есть цель ваших обзоров, то если вы проводите небольшое тестирование, лучше приблизиться к 100%. Тем не менее, если позволить тестовым инструментам сделать это, то это уменьшит необходимость проверки всего кода.

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

Джон Фишер
источник
3

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

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

Что касается времени, то все зависит от того, насколько высок компонент приоритета. Были времена, когда я проводил 10-15 минут, просматривая, и в других случаях несколько человек читали код по отдельности, а затем уходили в комнату, чтобы провести более формальный процесс проверки, который длится 30-45 минут (в зависимости от размера модуль).

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

Томас Оуэнс
источник
3

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

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

Без шансов
источник
2

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

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

Карл Билефельдт
источник
Это в среднем? Ограничение сложного обзора до часа кажется странным, и если не так много для обзора ... ну, я не могу понять, как час в день будет работать?
Кирен Джонстон
Это не предел. Я установил время исходя из того, сколько времени это заняло, а не наоборот. Обычно я могу сделать 2 отзыва за час. Если это занимает больше времени, ваши проверки слишком велики, вы не получаете достаточного количества проверок проекта заранее или ваши инструменты проверки кода слишком громоздки. Проверка кода - это проверка, а не редизайн.
Карл Билефельдт
2

Мы сделали 100% обзоров кода. Это намного дешевле, чем тестирование, особенно тестирование покрытия кода на 100%. Мы не тратим на них слишком много времени, обзор более часа в день становится менее продуктивным. (30 минут это не много).

В процессе установки нуля ведите записи. Что ты нашел? Что QA обнаружило позже? Что нашли ваши клиенты? Почему эти ошибки сбежали от вас?

MSalters
источник
7
Как обзор дешевле, чем автоматизированное тестирование? Предполагая, что вы пишете тест один раз, просматриваете тест один раз и имеете стабильный набор тестов, вы должны тратить гораздо меньше времени и денег на выполнение тестов, чем требуется для выполнения любого вида обзора (в течение срока действия проекта). Кроме того, стремление к 100% охвату кода является пустой тратой ресурсов, что может быть причиной увеличения времени / стоимости тестирования. Я также подвергаю сомнению 30 минут в обзорах - мы могли бы просмотреть модуль в течение 30 минут, но есть время для предварительного чтения кода, понимания его роли в системе и комментирования.
Томас Оуэнс
Заявления @MSalters не являются неслыханными, хотя я тоже скептически отношусь к тому, что они занимают всего 30 минут ... Я читал только об одном месте, где это было так, что инспекция была более рентабельной, чем автоматическое модульное тестирование, и это было НАСА. В этом случае они в конечном итоге отказались от модульного тестирования, потому что дешевле было вручную проверить код. Конечно, у НАСА все еще было соотношение тестер: разработчик, равное 12: 1, поэтому они также проводили много других испытаний ...
Майкл
2
@ Томас Оуэнс: модульные тесты находят простые ошибки. Дорогие ошибки - это те, где несколько единиц объединяются неожиданным образом. Еще один вид ошибок - это пропущенные угловые случаи. Разработчик, пропустивший кейс, тоже не напишет для него модульное тестирование, но его увидят вторые глаза.
MSalters
@MSalters Вот почему вы пишете автоматизированные интеграционные и системные тесты, а также модульные тесты. Действительно, единственные тесты, которые, возможно, должны быть выполнены вручную, являются приемочными тестами. А проверка тестов при создании поможет убедиться, что тестируются самые критические случаи.
Томас Оуэнс
2

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

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

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

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

Джим в Техасе
источник
2

Проверка кода, IMO, необходима. Вы 99,999 ...% времени не всегда будете правы, поэтому вам нужно убедиться, что это правильно. У меня есть установленное время? Но я не тороплюсь, чтобы проверить мой код. Обычно у меня коллега делает то же самое.

динамический
источник
1

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

Что касается того, сколько времени нужно потратить на рецензирование, хорошей практикой является оставить 5-10% от вашего общего предполагаемого времени разработки для проведения анализа кода и ответа на него.

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

Кэти Б.
источник