Рецензирование или парное программирование, или оба? [закрыто]

  • Участвуете ли вы в рецензировании кода или практикуете парное программирование, или и то, и другое?
  • Удалось ли вам продемонстрировать повышение качества программного обеспечения с помощью этих методов?
  • Какие преимущества и недостатки вы наблюдали в ходе практики?
  • С какими препятствиями на пути реализации вы столкнулись?

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

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

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

Было бы полезно узнать ваш опыт работы с рецензентами или парным программированием, особенно истории успеха.

23.08.2008 03:48:55
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

21
23.08.2008 04:11:07

Рецензия должна быть ОБЯЗАТЕЛЬНОЙ .

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

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

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

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

Если вы держите вещи позитивно и организованно, как правило, это отличный опыт.

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

4
23.08.2008 04:21:15

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

НО с тех пор я был вовлечен во множество обзоров автономного кода.

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

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

Четвертый проект использует навязанную схему проверки «в случайное время», и технические лидеры еще не привели ее (сломанная команда?)


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

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

После того, как у вас появился этот дополнительный взгляд на ваш код, вы не захотите оглядываться назад.

2
23.08.2008 07:34:18

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

4
23.08.2008 07:50:13

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

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

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

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

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

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

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

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

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

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

2
29.10.2008 19:56:33

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

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

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

0
10.01.2016 18:32:00