Если вы объединяете программу, вам все еще нужна рецензия?

Question

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

Однако, если вы занимаетесь парным программированием, у вас фактически есть рецензирование в режиме реального времени, так стоит ли проводить рецензирование в рамках этого процесса? Можете ли вы иметь пару отзывов коллег?

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

Был похожий вопрос некоторое время назад, но с другим акцентом и без ясного консенсуса

Answer 1

Это зависит.

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

Например, если вы пишете 3D-часть приложения, вам может потребоваться, чтобы она была рассмотрена вашим экспертом OpenGL.

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

Paring - это рецензирование. Или, как говорят XP, если что-то хорошо, доведите это до крайности. Если рецензии хороши, делайте это постоянно, то есть парное программирование.

Когда парное программирование выполнено правильно и пары часто меняются, вы будете проводить постоянные экспертные проверки всего разработанного кода. Еще лучше то, что код проверяется, поскольку он спроектирован, протестирован и написан (да, сначала напишите тест A.K.A Test Driven Development) не после того, как код был написан и более дорогостоящий для исправления.

Рецензируемый код - лишь одно из преимуществ парного программирования. Другие преимущества:

Улучшенное качество : пара активных программистов, работающих над одной и той же исторической картой, дополнит карту меньшим количеством дефектов

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

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

Передача навыков: Вращающиеся пары учат друг другу новые навыки (инженерия и область), когда они работают вместе. Уровень команды повысится для всех, и знания распространяются через команду.

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