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

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

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

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

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

Есть вещи, за которыми нужно следить:

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

Экспертная оценка должна быть MANDATORY .

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

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

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

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

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

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

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

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

BUT с тех пор я был вовлечен в множество оффлайновых обзоров кода.

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

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

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

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

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

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

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

• Обзор кода имеет определенные преимущества, что было продемонстрировано несколькими исследованиями. Для нашей компании было очевидно, что качество кода повышается по мере уменьшения количества обращений в службу поддержки,а также количества зарегистрированных ошибок. NOTE: некоторые из преимуществ здесь были результатом внедрения Scrum и отказа от Waterfall. Подробнее о Scrum читайте ниже.

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

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

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

“Right Way” кодовые обзоры, сделанные “right way”, полностью субъективны. Однако лично я считаю, что они должны быть неформальными, over-the-shoulder отзывов. Все участники проверки должны избегать личных нападок на проверяемого человека с такими заявлениями, как “why did you do it that way?” или “what were you thinking?” и т.д. Эти типы комментариев снижают доверие между коллегами, что приводит к вражде, многочасовым спорам о том, как лучше/правильнее кодировать решение. Имейте в виду, что разработчики не думают и не кодируют точно так же, и есть много решений проблемы.
Просто небольшое уточнение по over-the-shoulder отзывам; они могут быть проведены через удаленный доступ к рабочему столу (выберите вкус здесь) или лично. Однако они не должны ограничиваться только разработчиками. Обычно мы приглашаем всю нашу scrum-команду, состоящую из двух разработчиков на команду, тестировщика, документалиста и владельца продукта. Все не-разработчики находятся там, чтобы лучше понять вносимые изменения или новые функциональные возможности. Они могут свободно задавать вопросы или вносить свой вклад, но не принимать решения о кодировании или комментарии. Это было эффективно, так как будут заданы определенные вопросы, которые могут изменить направление проекта, поскольку первоначальные требования, возможно, пропустили сценарий, но именно это и есть agile, изменение.

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

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

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

“Code Reviews vs Pair Programming” https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926