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

Ведущий и штурман, 2. Пинг–понг, 3. Экскурсовод, 4. Без структуры.

Инструкция: «Что НЕЛЬЗЯ делать в парном программировании?»: Работать в паре все 100% рабочего времени. Важно не забывать про другие дела и давать себе отдохнуть; Постоянно отвлекаться.

«Одна голова хорошо, а две лучше» - старая поговорка, но уже в новом формате. Стоит признать, программирование совершенствуется со скоростью света точно также как и вся сфера IT. Парное программирование — свеженькая практика, которая однозначно заслуживает должного внимания. Поэтому, welcome в мир нового метода работы с кодом. Готовы с ним познакомиться?

Не будем вдаваться в далёкую терминологию и сразу перейдем к сути. Методика парного программирования на первый взгляд довольно очевидна — двое специалистов пишут код за одним столом. Пока первый работает, другой наблюдает и анализирует, меняются, и так по кругу. Эта система рассчитана для того, чтобы вовремя выявить и исправить ошибки, обсудить варианты и определиться с задачами.

Насчет причины появления такого метода тоже не нужно долго гадать. Еще с детства жизнь даёт нам некие задания и намёки — вместе сделать поделку в садике, выполнить совместное задание за партой в школе, да даже наглядные мультики про Тимона и Пумбу или Крокодила Гену и Чебурашку тоже про это. Так уж сложилось, что мы, люди — существа социальные, и программисты не исключение, какие бы там стереотипы не существовали 😅

• Самый лучший способ обучения новичка. Частенько, работа в паре бывает по типу: Senior и Junior. Для новичка одни только плюсы — не нужно искать у кого спросить, а работа будет выполняться сразу качественно. Конечно, для сеньора дело обстоит немного иначе, но об этом позже.
• Одинаковый уровень знаний у обоих программистов. Если мы говорим не об обучении, а о целенаправленной работе над проектом, то такая работа будет быстрой и эффективной.
• Процесс работы. Так как здесь уже не самостоятельная деятельность, а совместная, то уже не получится работать только в своем режиме. Выбор стиля работы, планирование задач, организация work зоны — первое, что необходимо сделать перед парным программированием.

Ведущий и штурман

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

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

Пинг–понг

Стиль берет начало из экстремального программирования. Один пишет код, в то время как другой проходит TDD (Test-Driven Development). И также меняются.

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

Экскурсовод

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

Без структуры

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

А теперь, давайте немного отдохнем от разбора стилей и займемся планированием.

Планированием совместного рабочего дня.

Казалось бы, довольно очевидный момент на первый взгляд. Но поверьте, всего лишь одна недомолвка и BOOM💥 — ваша совместная работа на текущий день сорвана. А значит, и проблем потом не огрести.

Что нужно сделать перед парным программированием?

• сверить расписание на день;
• поставить напоминалки, если планируются события или другие задачи в течение дня;
• зафиксировать основные часы под написание кода.

Организация, планирование и снова организация…..

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

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

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

Далее прилагаем четкую инструкцию «Что НЕЛЬЗЯ делать в парном программировании?»:

• Работать в паре все 100% рабочего времени. Важно не забывать про другие дела и давать себе отдохнуть;
• Постоянно отвлекаться. Стоит помнить, что вы работаете с человеком. Вы тратите его время, пока читаете сообщения или копаетесь в телефоне. Тут нужно вспомнить про планирование, где вы, по идее, должны были внести в расписание «Просмотр писем»;
• Чрезмерный контроль. Кому нравится, когда за него всё проговаривают и не дают свободу действий?

Коли уж потянуло нас в «дебри» парного программирования, хотим поговорить о хороших и не очень сторонах этого подхода.

ПЛЮСЫ

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

МИНУСЫ

• Усложняет простые задачи. Парное программирование хорошо работает в случае крупных проектов. Если этот метод задействовать в мелких задачах, велика вероятность потратить больше средств, чем нужно.
• Личностный фактор. Не исключено, что в паре у одного из программистов может зафиксироваться роль «всезнайки», желающего монополизировать знания. Парное программирование не полностью исключает этот фактор, так как корень проблемы в человеческих чертах характера.
• Напряжение. Частое явление в паре, когда один чувствует себя менее эрудированным. Это не дает расслабиться и ощущать уверенность в собственных силах.

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

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

«Работает? Не трогай.» © Любой программист P.S — шутка! Желаем удачи в новых свершениях!