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

Парное программирование

Парное программирование - относительно противоречивая практика среди всех гибких практик, если не самая большая. Фактически, только несколько команд, которые его внедряют, могут извлечь из этого пользу. Для большинства остальных, даже если они утверждают, что они делают Agile, часто встречаются два противоположных сообщества: защитники делают упор на такие вещи, как knowledge transform, reduce potential defects, avoid information island и т. Д. Оппоненты, с другой стороны, считают, что это своего рода пустая трата времени. : разработчикам сложно всегда сосредотачиваться на определенной задаче, легко переключаться с одной темы на другую (и в конечном итоге заканчиваются спорами о сравнении редакторов / личных предпочтениях). Кроме того, еще одна распространенная проблема заключается в том, что сложно измерить производительность для каждого, когда команда применяет парное программирование (для некоторых организаций очень важно измерить все). Честно говоря, это самая сложная часть почти во всех проектах, над которыми я работал.

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

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

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

Настройка оборудования

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

Поэтому, прежде чем приступить к программированию, убедитесь, что экран находится на оптимальной высоте, иногда вам нужно отрегулировать высоту своего сиденья, чтобы оно подходило вам и вашим сверстникам. Если возможно, вам могут понадобиться двойные экраны. (Я видел это только однажды в своей карьере, это были Саманта и Раймонд из NAB, у каждого из них был стол с 17-дюймовым 4k-экраном Dell. Но я сомневаюсь, что для большинства у нас не всегда такая роскошная конфигурация)

Кроме того, вам нужно уточнить некоторые детали:

  • Адаптер VGA / HDMI
  • Высокий процент заряда батареи вашего ноутбука
  • Адаптер клавиатуры / мыши
  • Post-it и Sharpies

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

Конфигурация программного обеспечения

Пока у вас готово все оборудование, пора заставить программное обеспечение работать как на вас, так и на ваших коллег. К сожалению, программное обеспечение сложнее оборудования. У большинства профессиональных разработчиков есть собственный набор инструментов, от curl / wget до vim / emacs, и даже не ждите, что у вас и ваших коллег есть что-то общее с точки зрения инструментов. Это то, с чем вы можете столкнуться случайно, но не то, чего вам следует ожидать.

По моему опыту, расширенная IDE, такая как IntelliJ / WebStorm от JetBrains, имеет встроенные предопределенные комбинации клавиш, которые вы можете легко переключать. Если вы не можете согласиться с тем, какая комбинация клавиш подходит для вас обоих, просто переключитесь на свою, когда придет ваша очередь писать код, и наоборот.

В IntelliJ / WebStorm вы можете легко использовать Ctrl+to switch different preferences,3` для переключения раскладки клавиш. Это всего лишь 3 нажатия клавиш, и в большинстве случаев можно избежать потенциальных конфликтов.

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

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

  • Найдите файл по имени и перейдите к нему
  • Поиск по содержанию
  • Найдите конкретную функцию / строку
  • Выберите переменную, выражение, оператор
  • Запустить тесты (в командной строке или в IDE)

Кроме того, если бы вы могли выполнять следующие задачи в shell, это было бы еще лучше:

  • Поиск файлов / папок по ключевым словам
  • Загрузите файл по URL-адресу и сохраните его в файл
  • Регулярное выражение для поиска / замены

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

Когда знания - это дисбаланс

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

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

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

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

Для водителя

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

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

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

  • Есть ли какой-нибудь лучший подход, который вы можете увидеть?

Если он / она колеблется или не совсем понимает, попробуйте:

  • Как вы думаете, XYZ лучше?

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

Наблюдатель

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

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

Продолжайте сосредотачиваться

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

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

Однако в некоторых экстремальных сценариях, когда конфликт становится неизбежным, нам приходится искать компромисс в некоторых аспектах и ​​двигаться дальше.

Разбираться с разногласиями

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

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

В предыдущем проекте я выбрал scss module в качестве препроцессора CSS только потому, что в проекте непосредственно перед этим я использовал его и нашел его очень удобным. Пока один из коллег задумывался о styled-component, мы оба не убедили друг друга. В итоге в кодовой базе смешались оба стиля. Пока однажды я не обнаружил, что этот компонент, созданный поверх styled-component, выглядит довольно аккуратно, и после попытки рефакторинга некоторых компонентов, написанных scss на styled-component, я обнаружил, что код выглядит более кратким и не оказывает никакого влияния на существующие тесты.

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

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

Сложные задачи

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

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

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

Установите и контролируйте правильный темп

На самом деле внимание - это самый ценный ресурс, обычно вы вряд ли можете сосредоточиться на чем-то более 30 минут. После этого ваш мозг найдет что-то более интересное. Короткий перерыв может освежить мозг и дать ему отдохнуть. У нашего мозга есть интересная особенность: кажется, он обладает суперспособностью справляться с задачами в фоновом режиме - и гораздо более мощным, чем передний план. Скорее всего, вы уже много раз пережили тот aha момент, когда вы просто спускаетесь вниз за плоским белым.

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

  1. Получить задачу из списка дел
  2. Установите источник бесперебойного питания tomato на 25 минут и приступайте к работе
  3. Когда время истекло, задание перерыв на 5 минут
  4. Повторите шаги 2–3, через 15 минут через 4 tomatoсек.

Вот онлайн-помидор-инструмент, которым вы можете воспользоваться, а можете просто использовать таймер на своем телефоне.

Коммутационная пара

Когда вы всегда на время соединяетесь с кем-то, pair сам превращается в информационный остров. Например, A и B работали над order модулем, в то время как C и D работали над store управлением, без сомнения, через определенный период времени A и B не будут знать, над чем работают C и D. Не только знание предметной области, но и технические детали / шаблоны проектирования и т. Д. Когда ваша команда вырастет до 10+, ситуация пойдет еще хуже.

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

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

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

Уважай своего сверстника

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

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

Контролируйте свои эмоции

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

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

Сделай домашнее задание

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

Например, когда вам удобно использовать grep для полнотекстового поиска и вы заметили, что awk выглядит более эффективным, когда ваши коллеги демонстрируют некоторое преимущество этого. Затем вы можете выучить это как домашнее задание, когда вернетесь, и попробовать использовать разные варианты или сравнить с инструментом, с которым вы уже знакомы. Другим примером может быть то, что вы и ваш коллега обнаружили некоторые интересные особенности, связанные с webpack исправлением некоторых проблем в повседневной работе, но вы не понимаете механизма, скрытого под капотом, это хорошая возможность улучшить эту конкретную часть. Потратьте немного времени на то, чтобы сделать вашу внешность лучше на следующий день, и погрузитесь в удовольствие (если таковое есть).

Эти принципы фундаментальны, тонки и тривиальны. Но если вы сделаете это хорошо, вы и ваши сверстники почувствуете себя комфортно и уверенно во время брака и, надеюсь, принесет продуктивность в вашу повседневную работу.

Резюме

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

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

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