Peer Reviews или Pair Programming, или Both?

Ответ 1

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

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

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

Ответ 2

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

Некоторые вещи, на которые следует обратить внимание:

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

Ответ 3

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

Ответ 4

Экспертная оценка должна быть ОБЯЗАТЕЛЬНАЯ.

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

Лично я считаю, что экспертная оценка должна быть забавной. Продовольственная обеспечена и поддерживает атмосферу веселой. Это действительно следует рассматривать как время, когда разработчики/программисты могут учиться друг у друга, не имея возможности судить (и мы все знаем, как каждый запрограммированный кажется рожденным врожденным субъективным геном). Я, как правило, оценил или помог организовать обзоры на 1/3-й или 1/4-й раз как открытый. Под этим я подразумеваю, когда группа объединяется, и один человек представляет проект, который они работают или даже просматривают, что даже не связано с текущим проектом (я знаю, что это сложно с крайними сроками, но попробуйте его).

Объявления, как правило, собираются вместе, чтобы отображать в настоящее время картины, рисунки и художники, чтобы помочь облегчить вдохновение. Реалистично, вдохновение должно стать ведущей концепцией, которую вы надеетесь усовершенствовать в обзоре. Вторично, чтобы люди просто замечали вещи, которые делают их коллеги-разработчики, которые они НЕ заметили раньше. "О, вау, так тебе удалось сделать это в одной строке кода? Круто". Благодаря тому, что разработчики вдохновлялись и мотивировались тем, что они делают, над чем работают, и как они это делают, будут выплачиваться дивиденды больше, чем использование экспертной оценки для установления порядка и ранжирования иерархии.

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

Если вы держите вещи позитивными и организовываете их, как правило, большой опыт.

Почти забыл прикоснуться к парному программированию. Это сложнее для настройки. Очевидно, что у вас не может быть двух ваших слабых программистов, работающих вместе, или вы можете организовать миллион обезьян с миллионом пишущих машин. Постарайтесь укрепить более сильного человека и предложить стимулы как в частном порядке. Тот, кто слабее, должен знать, что улучшение может быть вознаграждено (если они требуют такого стимула), и более сильный программист должен знать, что настоящие лидеры начинаются как хорошие наставники. Убедитесь, что более слабый разработчик набрал. Не наоборот или он становится презентацией и "зевает", что кто-то может ничего не получить по опыту.

Ответ 5

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

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

В зависимости от проекта они либо были заданы перед тем, как войти в "живую" ветвь, либо в какой-то случайный момент времени. На 3 из 4 проектов они были приняты, по общему признанию, как необходимое зло изначально, но позже как ценный вклад.

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

4-й проект использует наложенную схему просмотра "в случайное время", и технические лидеры пока не ввели ее (сломанная команда?)

Два описанных вами метода - это формальные подходы. Они не работают хорошо для всех личностей и групп.

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

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

Ответ 6

• Да, наша компания использует рецензии на одноранговые коды. Мы проводим их как обзоры Over-The-Shoulder и приглашаем тестировщиков команд принять участие в собрании, чтобы лучше понять изменения.

• В обзоре кода есть определенные преимущества, поскольку несколько исследований были продемонстрированы. Для нашей компании было очевидно, что качество кода увеличилось по мере уменьшения количества вызовов поддержки и уменьшения количества зарегистрированных ошибок. ПРИМЕЧАНИЕ. Некоторые из преимуществ здесь были результатом внедрения Scrum и отказа от водопада. Подробнее о Scrum ниже.

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

• Некоторые из препятствий, которые нужно преодолеть при реализации обзоров кода, - это идея, что "старший брат" наблюдает за мной и мысль о том, что отсутствие совершенного кода означает пытку и боль. Иногда заставить разработчиков доверять друг другу трудно, особенно когда речь идет о "иерархическом порядке" или "святости, чем ты", и прикладывать тяжелую работу под микроскопом. Доверие - это ключ к решению этих проблем. Разработчик должен верить, что они не будут наказаны сверстниками или руководством за ошибки в коде. С кем не бывает. Запомните проблему, разрешите ее и перейдите.

Scrum Одним из преимуществ использования методологии Scrum является то, что цикл разработки ( "спринт" ) является коротким. Временной интервал "спринта" определяется тем, что наилучшим образом подходит для вашей организации и потребует проб и ошибок, но на самом деле не должно быть больше четырехнедельных итераций. Преимущество заключается в том, что для этого разработчики ежедневно общаются и сообщают о проблемах на раннем этапе проекта. Это было первоначально принято нашим департаментом развития и распространилось на все сферы нашей компании, так как преимущества схватки далеко заходят. Для получения дополнительной информации см. http://en.wikipedia.org/wiki/SCRUM или http://www.scrumalliance.org/. Поскольку итерации развития меньше, процесс проверки кода рассматривает меньшие фрагменты кода, что делает просмотр более вероятным для поиска проблем, чем часов или дней официальных обзоров.

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

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

Ответ 7

Сравнительный анализ после перехода на обзоры PR на github от парного программирования.

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

"Обзоры кодов против программирования на парах" https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926