Принципы парного программирования

pair-programming

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

И тем не менее… эффективное парное программирование — это самый дешевый способ улучшить качество кода. Несмотря на то, что на первый взгляд это выглядит как уменьшение производительности вдвое — ведь ваша команда из восьми разработчиков теперь работает всего над четырьмя проектами, вместо восьми! — оказывается, производительность не ухудшается ни на каплю. Более того, я был свидетелем обратного.

Работа в одиночестве

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

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

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

Начало работы в парах

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

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

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

Роли

Работая в паре мы обычно называем две свои роли “водитель” и “штурман”. Водитель — это человек, в руках которого клавиатура, он печатает. Штурман не печатает ничего. Чем же тогда он занимается? Самое важное — понять, что он сидит и наблюдает. Водитель занят написанием хорошего кода, который будет компилироваться; водитель сфокусирован на деталях. Штурман же наблюдает за общей картиной: он следит, чтобы наш труд был согласован со всем проектом.

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

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

Штурман также может отслеживать “стек вызовов” процесса разработки. Вы знаете, как это бывает: мы начали писать тест «корзина товаров возвращает цены в евро», но для этого нам нужно изменить метод «получить цену товара» у корзины. Из-за этого перестают работать пара модульных тестов корзины. Первый из них показывает, что для элемента «корзина» отсутствует конвертация валюты. Поэтому теперь мы изменяем конструкцию конвертации валюты, чтобы мы могли передавать ее в фабрику элемента «корзина». Если не соблюдать осторожность, то подобный «стек вызовов» задач разработки может стать очень глубоким, но дисциплинированный штурман с подробным журналом навигации сможет проложить дорогу.

Смена ролей

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

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

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

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

Вывод

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

 

Источник


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>