В целом, просмотр кода помогает:

  • Выявлять и ловить ошибки
  • Распространение знаний о кодовой базе по всей команде
  • Ознакомьте новых людей со способами работы
  • Убедитесь, что код читабелен и удобен в сопровождении

Мы углубимся в проверку кода, перечислив советы ниже:

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

Просмотрите весь код

  • Пересмотрите все, тогда ничего не будет упущено. Когда вы просматриваете весь код, вы убедитесь, что у вас есть хорошо поддерживаемый продукт.

Проверка кода часто и в течение коротких сессий

  • Лучше не просматривать код слишком быстро, а также не просматривать его слишком долго за один присест. Когда люди занимаются какой-либо деятельностью, требующей концентрации усилий в течение определенного периода времени, производительность начинает падать примерно через 60 минут. В среднем время проверки кода должно составлять от 10 до 15 минут в день.
  • Обзоры кода в разумном количестве в течение ограниченного периода времени приводят к наиболее эффективному обзору кода.

Всегда будьте терпеливы и пересматривайте, если требуется

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

Зафиксируйте усовершенствования и технический долг

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

Практикуйте легкие обзоры кода

  • Чтобы полностью оптимизировать время вашей команды и эффективно измерять ее результаты, рекомендуется упрощенный процесс.
  • Исследование Cisco Systems, проведенное SmartBear, показало, что облегченная проверка кода занимает менее 20 % времени формальной проверки и находит столько же ошибок! Формальный, или усиленный, осмотр занимает в среднем девять часов на 200 LOC.

Делайте код-ревью, как только видите запрос

  • Даже если это выглядит как большой обзор, постарайтесь сделать первый проход как можно скорее. Ваши коллеги будут благодарны, а их доброжелательность поможет вам быстрее расти как рецензенту. Не всегда легко проводить проверки кода сразу, особенно если они изменяют много кода или запуск вашего приложения занимает много времени. Если вы обнаружите, что откладываете проверку кода, эти советы могут помочь вам быстрее приступить к работе: Установите ограничение по времени, например, полчаса. При первом проходе потратьте полчаса на то, чтобы понять изменения и записать вопросы. Если по истечении срока вы считаете, что можете одобрить изменение, одобрите его. Если вы не готовы, отправьте автору любые мысли или вопросы, которые у вас есть на данный момент, и запланируйте и зафиксируйте время, когда вы собираетесь сделать более подробный проход и утвердить или запросить изменения.
  • Держите на своем компьютере два отдельных репозитория: один для ваших собственных изменений, а другой для изменений, которые вы просматриваете. Таким образом, компиляция изменений ваших коллег не уничтожит артефакты компиляции, связанные с вашими собственными изменениями.

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

  • Когда вы предлагаете изменения, предполагайте, что автор может справиться с изменениями. Замедлять их, чтобы дождаться второго раунда проверки кода, почти никогда не стоит, особенно если изменения представляют собой простые вещи, такие как переименование переменных или извлечение дублированного метода. Если вы заставите авторов ждать дольше из-за стиля, код в конечном итоге станет хуже. Замедление изменений заставляет людей неохотно отправлять небольшие изменения, которые уточняют и очищают код. Если вы не чувствуете себя квалифицированным, чтобы дать одобрение, скажите это в этих словах и придумайте план, как заставить нужного человека посмотреть код. Когда вы забываете нажать «одобрить», автор изменения не знает, забыли ли вы, или вы думаете, что код сломан, или вам все равно, заблокированы ли они. Помогите им почувствовать ваши благие намерения, четко предупредив, каким будет следующий шаг.

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

  • Представьте, что вы сидите перед компилятором, которому поручено исправить небольшую ошибку. Но вы знаете, что как только вы скажете «Я закончил», ваши коллеги — или, что еще хуже, ваш начальник — будут изучать вашу работу. Не изменит ли это ваш стиль разработки? Во время работы и, конечно же, до того, как вы объявите код законченным, вы будете немного более добросовестны. Вы сразу же станете лучшим разработчиком, потому что хотите, чтобы общий тон разговоров «за вашей спиной» был таким: «Его материал довольно жесткий. Он хороший разработчик; не «Он делает много глупых ошибок. Когда он говорит, что закончил, это не так». Эффект эго побуждает разработчиков писать лучший код, потому что они знают, что другие будут смотреть на их код и их показатели. Никто не хочет прослыть парнем, который совершает все эти юношеские ошибки. Эффект эго побуждает разработчиков тщательно проверять свою работу, прежде чем передавать ее другим. Хорошая характеристика Эффекта Эго заключается в том, что он работает одинаково хорошо независимо от того, являются ли обзоры обязательными для всех изменений кода или используются только в качестве «выборочных проверок», таких как случайный тест на наркотики. Если вероятность того, что ваш код будет отправлен на проверку, составляет 1 к 3, этого все равно достаточно, чтобы заставить вас отлично поработать. Однако выборочные проверки должны быть достаточно частыми, чтобы поддерживать эффект эго. Если бы у вас был всего 1 из 10 шансов получить отзыв, возможно, вы не были бы столь усердны. Вы знаете, что всегда можете сказать: «Да, я обычно не делаю этой ошибки». Просмотр 20–33% кода, вероятно, даст вам максимальную выгоду от эффекта эго с минимальными временными затратами, а просмотр 20% вашего кода, безусловно, лучше. чем не рассматривать ни одного.

Документируйте все комментарии проверки кода

  • Документируйте все комментарии проверки кода в электронном письме, документе Word, Excel или любом стандартном инструменте, используемом организацией. Совершить ошибку в первый раз допустимо, но повторять ту же ошибку — плохой знак. Документ проверки кода помогает разработчикам программного обеспечения перепроверить выявленные проблемы и избежать подобных ошибок в будущем. Кроме того, ведение документа проверки кода является обязательной частью процесса уровня интеграции модели зрелости возможностей (CMMI).

Можно найти на Techwebies