Является ли проверка кода хорошей практикой?

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

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

Каковы преимущества этого и есть ли недостатки?

Проверка кода - отличная практика.

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

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

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

Дополнительные преимущества для обзоров кода (как прокомментировано для этого вопроса), включают:

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

Обзоры кода - очень полезный инструмент для обучения , особенно если у вас есть новый член команды. Ну, это также известно как процесс рецензирования :)

Существуют разные типы обзоров кода:

• Через плечо - когда один разработчик просматривает плечо автора кода, пока последний просматривает код.
• Отправка по электронной почте - система управления исходным кодом отправляет рецензентам код по электронной почте автоматически после регистрации. Извлечение из комментария: не сумев убедить руководство выделить время для какого-либо формального анализа кода, я обращал внимание на изменения, вносимые коллегами, всякий раз, когда я вытаскивал новые ревизии из системы контроля версий с использованием инструментов history / diff, встроенных в Tortise.
• Парное программирование - два автора разрабатывают код вместе на одной рабочей станции, что часто встречается в экстремальном программировании.
• Инструментальный обзор кода - Авторы и рецензенты используют специализированные инструменты, предназначенные для рецензирования кода.

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

Другие ссылки перечислены ниже (для более глубокого чтения погружения)

• MSDN - обзор кода
• Найдите и исправьте уязвимости перед отправкой вашего приложения
• Ссылка на вики

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

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

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

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

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

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

Несколько вопросов должны быть решены:

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

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

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

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

Проверка кода - отличная практика, особенно если разработчики делают это для обмена знаниями, а основные правила заранее установлены так, что предложения и критика должны быть КОНСТРУКТИВНЫМИ, а не использовать отдельного разработчика для целевой практики.

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

Если вы хотите продемонстрировать хорошую работу, которую разработчики делают с управлением, тогда «проверка кода» имеет другое значение и не должна быть такой подробной, как проверки кода, которые проводятся для инструктирования / улучшения качества кода среди разработчиков. Этот вид презентации может быть полезен для демонстрации того, что делают разработчики, если презентация может быть более высокого уровня и менее специфичной для кода, с акцентом на том, что понимают менеджеры (ценность, рентабельность инвестиций и т. Д.). Это может заставить менеджеров понять, что Джо добавил значительную ценность для компании, создав X, который, как мы можем показать, экономит время Y, или Z долларов за заказ и т. Д. Я думаю, что это может стоить усилий, чтобы показать ценность отдельных члены вашей команды. Помните, однако, что вы должны быть осторожны, вы не перегружаете свою аудиторию жаргоном или слишком большим количеством деталей.

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

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

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

Для нашей команды мы делаем, как упомянул @ElYusubov, и используем инструмент специально для Code Review - Crucible. Люди проверяют, комментируют и подписывают код. Каждую неделю мы садимся и рассматриваем интересные и / или сложные фрагменты кода.

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

В моей команде для каждого коммита требуется проверка кода (большие изменения заканчиваются формально, меньшие изменения заканчиваются «быстрым просмотром»). Я определенно чувствую, как будто это усилило мои инженерные / дизайнерские решения, тем более что я с большей вероятностью вытащу доску, чем терминал, так как знаю, что за мной "наблюдают". :)

По сути, я думаю, что он производит намного лучший код, с единственным небольшим недостатком, заключающимся в немного более медленном времени разработки (что, на мой взгляд, того стоит, если вам не нужно исправлять / расширять ужасно разработанный код). Кроме того, я думаю, что если у вас есть юниоры / стажеры в команде, они оценят возможность получить ценные отзывы. Я знаю, что!

Исходя из моего опыта, Code Review - это действительно здорово, если вы выполняете его хорошо. Когда у вас есть профессиональные / зрелые члены команды и менеджеры. Мы, как программисты, «решатели решений». Наша задача не создавать строки «текст». Вот почему мы должны делиться идеями, ошибками, проблемами, опытом. Проверка кода - действительно хорошая практика для достижения этой цели.

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

В моей компании мы пытаемся сделать обзор кода. Но слишком много времени тратится на «погоню за кроликом» (создание функций).

Большая часть проверок стиля и базовых синтаксических типов в наши дни перехватывается с помощью инструментов (FXCop и т. Д.).

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

Я не фанат наложения кода на проектор, чтобы команда могла его просмотреть - гораздо лучше провести совещание по проверке кода, где другой член команды (руководитель группы и т. Д.) Просматривает список с разработчиком. Это влияет на меньше людей - останавливает много потерянного времени на аргументы стиля - и менее смущает разработчика. Это более конструктивно и легче для разработчика воспринимать реальные проблемы и не быть ослепленным комментариями типа «Я бы сделал это ...».

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

Сесть с кучей списков, маркером и чашкой кофе в кофейной зоне отлично подходит для этого.

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

Обзор кода помогает увидеть «все». Отдельные разработчики имеют тенденцию видеть только свои требования / проблемы. CR открывает идеи и решения со всей перспективы. ЧР в основном помогает устранить ненужную ненужную работу. Весь продукт дешевле и лучшего качества.