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

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

Дихотомия опыта

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

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

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

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

Серийные мысли

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

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

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

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

Разве это не парное «кодирование»

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

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

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

Инструментарий и удаленная работа

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

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

Почему бы не работать вместе?

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

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

Первоначально опубликовано на сайте mortoray.com 11 августа 2017 года.