Обзор кода

Какую политику обзора кода вы могли бы рекомендовать как лучший для проекта, который вы управляете?

Ответы

Ответ 2

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

/Allan

Ответ 3

Я был расстроен тем, как просмотры кода были сделаны в командах, в которых я работал. Часто это случайная двухминутная работа, которая является прославленным тикающим упражнением. На самом деле я писал о том, что я называю Обзор Drive-By Code и перечисляет 5-точечный процесс, который я хотел бы видеть.

В заключение

  • Объясните контекст изменения, которое я рассмотрение.
  • Покажите мне свои модульные тесты.
  • Покажите мне свой код.
  • Покажите мне ноль предупреждений StyleCop и ноль нарушений FXCop.
  • Покажите мне все это здание на сервере непрерывной интеграции.

Ответ 4

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

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

Ответ 5

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

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

Каждая регистрация помечена идентификатором ошибки или запросом функции (для нового кода), и это позволяет отслеживать трафик.

Наконец, участие QA означает, что их тестирование кода обеспечит некоторую проверку.

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

Ответ 6

Мы интегрировали процесс проверки кода как шаг рабочего процесса в Jira. Когда разработчик совершает изменения в магистрали, они отмечают проблему как фиксированную в jira, и ее отправляют кому-то для проверки кода. Они могут отклонить или отправить его для тестирования.

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

Вот политика обзора кода, которую мы используем на работе: http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem

Краткая версия: изменения развиваются в ветвях, которые проверяются (и проверяются на прохождение тестов) до их объединения. Если объединенный код вызывает регрессию, он возвращается из магистрали.

Ответ 10

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

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

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

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

Ответ 11

rietveld кажется интересным, основанным на Mondrian, веб-инструментом для обзора кода, разработанного в Google Guido Van Rossum (известность Python)

Это позволяет проводить обзоры кода в любое время и не требует контакта лицом к лицу.

http://code.google.com/p/rietveld/wiki/CodeReviewBackground

демо здесь
http://codereview.appspot.com/

Ответ 12

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

Ответ 13

У нас есть 5 разработчиков на разных уровнях в моей организации; как таковой, обзор кода иногда представляет собой скорее учебный инструмент, чем обзор, как таковой ". Однако, разделяя код между разработчиками (и прилежным использованием контроля источника), качество кода значительно повысилось.

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

Ответ 14

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

Rietveld

Ответ 15

"как лучший" зависит от множества факторов:

  • Сам продукт. Является ли это жизненно важным/критически важным?
  • Стоимость фиксации после релиза. Сравните стоимость патча для ПК на десятках машин и напомните миллионы смарт-карт со встроенным дефектом кода.

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

Ответ 16

Наш процесс обзора кода очень прост. Перед выпуском исправления/функции настоятельно рекомендуется пересмотреть его. Обзоры выполняются "лицом слева", и они просто открывают окно журнала subversion и проверяют различия. Они делают свои комментарии оригинальному автору и добавляют сообщение "+" в сообщение журнала, чтобы указать, что оно было просмотрено, и затем поместить свои инициалы внизу. Это позволяет легко в процессе выпуска идентифицировать определенные коммиты, которые не были просмотрены, и мы можем разделить непрочитанные коммиты до того, как будет выпущен код.

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

Ответ 17

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

Cruicble от Atlassian фантастичен для того, чтобы делать обзоры кодов "онлайн".

Findbugs/PMD/Checkstyle удаляют много фиктивных синтаксических проверок, которые должен выполнить разработчик.

Eclipse/IntelliJ IDEa содержат невероятные встроенные предупреждения.

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

http://www.aswec2008.curtin.edu.au/IndustryReport/Morgan%20-%20Agile.pdf

Ответ 18

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

Ответ 19

Я использую Trunk как ветку "Готово" (т.е. освобождаю) и включаю обзор кода в "Определение совершенного". Другими словами, код не может быть объединен в ветке "Готово", если он не был просмотрен.

Ответ 20

Мы построили процесс проверки кода на основе инструмента проверки кода, такого как gerrit и разделили политику на другом уровне в разной фазе

  • Разработчикам рекомендуется писать парное программирование при написании кодов, это может избежать некоторой большой ошибки и улучшить обмен знаниями.
  • Инструмент проверки кода Gerrit используется до того, как коды, поступающие в главный (основной) ветвь, и система непрерывной интеграции (CI) включена для проверки, все возможные автоматически обнаруженные проблемы автоматически анализируются в CI ( коды).
  • Обзор кода на основе веб-интерфейса запускается только в том случае, если первые коды проверяются (охват тестирования модулей, возможный приемочный тест), в нем будут участвовать более старшие люди и сообщество разработчиков продуктов. li >

Политика просмотра кода должна быть

  • эффективность, автоматическая проверка качества кода как можно больше от IDE до CI.
  • обзор социального кода, больше глаз для кодов, лучшего качества.

BTW: Gerrit используется только для git, вы можете проверить другие инструменты веб-обзора.

Ответ 21

Reviewboard - хороший инструмент для просмотра кодов.

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

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

Ответ 22

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

Ответ 23

psp one

Ответ 24

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

OTOH, я работаю для SmartBear Software, поэтому мы, конечно, "едим нашу собственную собаку" и используем Code Collaborator внутри страны. Должен признаться, что я никогда не делал обзор кода, прежде чем начал работать здесь, - а также, что мне было бы трудно представить, что нужно вернуться к неподтвержденному коду.