У меня есть некоторые мнения об этом, но я отправлю ответ им.Кто, что, когда, где и почему вы должны кодосмотр?
Кому следует пересмотреть?
Все, кто отправляет код в общий репозиторий.
Кому следует пересматривать?
наставник или старший инженер, который будет смотреть за плохие запахи и ошибки в архитектурной корректности коды.
Ученики команды или стручка, работающие в одной и той же области кода, если вы работаете над 3D-рендерингом в компьютерной игре, все остальные графические программисты должны просмотреть код.
Любое другое, чьи модули сопряжены или зависят от передаваемого кода.
Какой код следует пересмотреть? (весь код? Большие изменения? Etc)
По моему опыту весь код, над которым будет работать более одного человека (и это почти весь код).
Где должен проводиться обзор? (Это должно быть выполнено лично?)
Отзывы наиболее полезны, когда они интерактивны и в режиме реального времени. Сказав, что я думаю, что важно иметь такую систему, как CodeReviewer, чтобы упростить распространение различий, чтобы рецензенты могли более эффективно и комфортно изучить изменения в своей собственной среде, прежде чем делать фактический обзор лицом к лицу.
Я никоим образом не связан с CodeBear, но я всегда находил, что мои обзоры кода были более эффективными, когда я мог просматривать изменения на своей собственной машине, так как у меня есть IDE и инструменты и все остальное настроено именно так, как мне нужно, чтобы эффективно разглашать код, чтобы увидеть, какое влияние могут повлиять на изменения кода, и это то, что я не могу сделать, если мой обзор будет всего 15 минут на ПК другого человека, наблюдая за их прокруткой их изменения.
Когда должны проводиться обзоры? (Поэтапно? До регистрации?)
Перед проверкой. Я был в ситуациях, когда инкрементный обзор кода заключался в том, что я писал код человека для них «поэтапно» во время каждого обзора. :(
Почему код был рассмотрен?
Две основные причины приходят на ум.
Первый заключается в сохранении качества и согласованности базы кода. Для любого реального мира кодовой базы у вас, скорее всего, будут программисты разного уровня, выходящие и присоединяющиеся к команде, которая отвечает за поддержание этой базы кода и обзоров, стараются свести к минимуму базу кода, становясь отражением динамики команд, например, 2 дрянных программиста присоединились к команде на прошлой неделе, а теперь 20 исходных файлов в них есть дерьмо.
Вторая причина заключается в устранении предположений о перспективах туннеля в коде. В какой-то момент база кода станет слишком массивной, чтобы один программист мог все понять. И с этого момента каждый, кто работает над кодом, будет иметь свой собственный «кусочек реальности» о том, что делает код и как работает система, и это часто приводит к написанию кода, основанного на наивных или неправильных предположениях. Поэтому, когда другие люди привносят свое представление о реальности в ваш код во время обзора, это помогает уменьшить эту проблему миопии базы кода.
Все, все ... пара программа! будет один ответ.
Однако, я думаю, это зависит от типа бизнеса, в котором вы находитесь, и насколько вы серьезно относитесь к качеству. Я работал в компании по медицинскому оборудованию, и обзор кода проводился периодически, переходя через страницы и страницы разностей вместе с диаграммой UML главным дизайнером, отделом QA и т. Д.
Есть несколько ответов на вопрос почему?
Кому следует пересмотреть?
Все, кто разрабатывает код, который будет выпущен в производство
Кто должен делать рецензирование?
Вся команда
Какой код должен быть пересмотрен? (весь код? Большие изменения? Etc)
От этого зависит. Мы просматриваем все изменения кода. Имена свойств и ini остаются нерассмотренными, если мы не сочтем это необходимым после просмотра кода.
Где должен проводиться обзор? (Должен ли он состояться лично?)
Да, это должно происходить лично. Помимо просмотра кода, вы можете получить ценную информацию об общих правилах кодирования, трюках IDE, список можно продолжить. Рассмотрение лично также дает кодеру возможность объяснить, почему они что-то сделали, оставляет больше места для обсуждения.
Когда должны проводиться обзоры? (Постепенно? До регистрации?)
Мы делаем это за неделю до ввода кода в эксплуатацию. В этот момент все проверяется, и это оставляет много времени для исправления любых проблем.
Почему код должен быть пересмотрен?
Список для этого вопроса является ginormous. Прежде всего, это уловить код, который может привести к ошибкам или ошибкам при производстве. Другие вещи, такие как ловли нестандартного кода, неаккуратный код, анти-шаблоны. В значительной степени вы это называете.
Вопрос был дан окончательный ответ. Но я хотел бы добавить, что даже если код в порядке, (по-видимому) ошибка, и следует стандартам, проверка кода имеет свои достоинства. А именно, он увеличивает номер грузовика на функциональность, которую разработчик выполнил. (Если только незначительно.)
Я, однако, не предлагаю, чтобы обзоры кода заменяли надлежащее комментирование.