Обзоры кода, каковы преимущества? [закрыто]

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

Должны ли мы рассмотреть вопрос о проведении формальных проверок кода? Какие будут преимущества?

Мы делаем обзоры кода немного по-другому (возможно).

Мы собираем всех программистов вместе (каждую пятницу) и смотрим, что мы сделали за недельный период. Затем мы выбрали, какие проекты мы хотим рассмотреть, чтобы в каждом готовом / выполняемом проекте было по крайней мере один или несколько человек. Затем примерно через час мы смотрим на внесенные изменения, ищем ошибки, как работают другие проекты и т. Д. Затем мы обсуждаем, сообщаем об ошибках, как это следует делать (мы не исправляем ошибки, а просто указываем на них). и спам код с FIXME). В целом это обычно для нас (10 программистов) занимает около 2 часов.

Плюсы:

• Каждый участник знает, что происходит в компании
• Ошибки найдены быстрее
• Это заставляет нас писать читаемый код (код, который можно прочитать без объяснения или введения!)
• Методы оптимизации / хитрости / продуктивные программы распространяются быстрее
• Программист как специалист "эволюционирует" быстрее
• Это весело

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

Я надеюсь, что это принесет пищу для размышлений. Удачи.

Вы можете прочитать эту бесплатную книгу:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Конечно, у них есть продукт, который нужно продвигать, но там еще много полезной информации.

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

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

Первые 2 пункта довольно хорошо охвачены парным программированием, третье очень зависит от пары и могло бы стать лучше после официального анализа кода.

Должны ли вы делать официальные обзоры кода?

Абсолютно

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

Я бы представил две формы проверки кода:

Рецензирование кода

Даже если парное программирование работает для вас, никогда не помешает взглянуть на код другим взглядом. Преимущества этого:

1. Он получает свежий взгляд на код, тот, кто может иметь более глубокие знания в областях кодовой базы, с которыми вы (и / или ваш партнер), возможно, не так хорошо знакомы. Это может выявить проблемы, связанные с подделкой.
2. Это заставляет вас (пару) повторно подтвердить свое решение до подачи заявки. Поскольку рецензент ничего не знает о том, что вы написали, вы должны объяснить это полностью. Это может раскрыть крайние случаи, о которых вы не думали, или неверную логику.

Рецензирование кода (в моем мире) проводится перед каждой отправкой. Как это происходит в мире парного программирования, я не уверен.

Отзывы о коде группы

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

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

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

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

Я никогда не занимался парным программированием на практике (только надеялся на это), поэтому не могу напрямую сравнить эти две практики. Тем не менее, я могу рассказать о своем опыте с официальными обзорами кода.

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

В среднем мы проводили одну сессию в неделю с участием 3-5 человек. Каждый сеанс занимал около 3-4 часов времени на человека (включая подготовку) и проверял 200-300 строк кода (LOC) *. В этом темпе за период более 6 месяцев нам удалось проверить около 5 тыс. LOC из примерно 50 тыс.

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

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

* Это нормальный темп официальных проверок кода.

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

Цитируется из Википедии (выделено мной).

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

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

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

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

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

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

Каковы преимущества? Что ж, было бы лучше, если бы вы рассмотрели риски, связанные с этим.

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

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

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

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