Экспертные оценки, или Парное программирование, или и то, и другое?[закрыто]

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Если вы сохраняете позитивный настрой и организованность, это, как правило, отличный опыт.

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

Answer 4

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

Answer 5

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

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

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

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

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

---

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

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

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

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