Время, выделенное для проверки кода

Если вы делаете обзоры кода

• Сколько времени вы тратите на проверки кода по сравнению с реализацией?
• Сколько изменений подвергается проверке кода?
• ты думаешь это намного / должно быть больше?

Есть ли исследования эффективности?

[править] Спасибо всем за ответы, трудно выбрать «победителя» для такого вопроса, в других ответах также есть много ценной информации.

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

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

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

Что касается обучения, программное обеспечение Smart Bear бесплатно отправит вам небольшую книгу Best Kept Secrets of Peer Code Review . В нем есть ряд статей о различных аспектах анализа кода, включая исследования о том, сколько времени они должны занять и насколько они эффективны.

В нашем проекте каждое существенное изменение в системе рассматривается руководителем группы или вместе с другим разработчиком, который станет основным «потребителем» нового модуля. Мы говорим по скайпу и либо используем Rudel в Emacs (плагин для совместного редактирования, в основном он позволяет нескольким пользователям редактировать один и тот же файл в реальном времени), либо TypeWith.me (Piratepad), либо один из нас делится своим экраном в скайпе.

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

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

Для простых вещей, таких как соглашения об именах и ошибки в области видимости, мы используем собственные или открытые автоматические инструменты (jslint, pylint, pyflakes, pep8). И мы не ограничиваем коммиты и толчки: мы используем Mercurial, который имеет очень легкое ветвление и слияние (я должен сказать, легче, чем в Git). Ошибки - это не вопрос проверки кода.

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

Там нет правильного или неправильного ответа на это. Но, как многие до меня предлагали, - если проверка кода выполняется внешним членом команды [настоятельно рекомендуемый метод], это может составить приблизительно от 30% до 35% усилий по разработке. Но если это делается внутренним членом команды проекта, который был частью команды разработчиков [не рекомендуется], это может быть выполнено примерно в течение 20% времени, затраченного на разработку.

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

Каждая организация и кодовая база различны, поэтому трудно получить значение для всей отрасли.
Если вы действительно серьезны, то вам следует начать собирать метрики. Т.е. делать обзор кода, пока не будет удовлетворительно выполнено, включая доработку. Начните собирать это в базе данных (LOC, сложность кода, язык программирования, время и т. Д.). Затем также соберите метрики на вашем уровне дефектов во время тестирования. До тех пор, пока вы можете уменьшить этот код обзор должен оплатить сам. Если дефект возвращается после тестирования, соберите показатели того, сколько времени было потрачено на устранение дефектов. Создайте эти данные в своей организации, создайте базовые показатели, и вы сможете предсказать их довольно точно. Условия для дальнейшего изучения - Стоимость качества и Стоимость плохого качества.

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