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

Что это?

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

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

Стили сопряжения

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

Водитель-навигатор

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

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

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

Настольный теннис

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

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

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

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

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

Быть наставником

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

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

Практические советы

  1. Все дело в пропускной способности, когда вы удалены, обе стороны должны иметь высокую скорость загрузки / выгрузки.
  2. Одним из лучших приложений для удаленной работы является Screen Hero. Если вы не можете получить приглашение, не волнуйтесь, есть много подобных инструментов, и вы всегда можете использовать Google Hangouts.
  3. Для людей, которые работают вместе в офисе, ваш работодатель должен получить ваши экраны с одинаковым качеством/разрешением, я считаю, что очень важно иметь одинаковые условия при рассмотрении проблемы.
  4. Не расстраивайтесь из-за того, что просите о помощи, когда это необходимо, будьте открыты и восприимчивы к ней. Обратите внимание и следуйте дальше.
  5. Не отвлекайтесь, отключите уведомления, особенно если навигацией занимаетесь вы.
  6. В паре с кем-то, у кого меньше опыта, позвольте ему водить. Люди лучше учатся, делая. Они вспомнят, как это сделать, когда в следующий раз будут за рулем.
  7. Прежде чем погрузиться в проблему, обсудите ее со своим товарищем по команде. Вы хотите сотрудничать и получить обе точки зрения, прежде чем что-либо писать — что вы ожидаете, что будет проблемой, если это будет написано таким образом и т. д. У вас есть 2 разработчика, 2 ума, используйте их.
  8. Чувствуете себя уверенно в одной области? Попробуйте сделать это в одиночку. Возможно, это не всегда правильно, но вы можете научиться, бросив вызов. Будьте активны в этом.

Конечный результат

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

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

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