Вполне нормально, что в начале работы, когда специалисты находятся на стадии знакомства, прощупывают так называемые «фичи» друг друга. Нужно время для некоторых проб и собственных ошибок, чтобы выбрать подходящий стиль для обоих. Парное программирование даст кандидату больше информации о будущей работе, чем он получил бы сам, задавая вопросы. Поэтому я с уверенностью заявляю, что это лучший способ понять, впишется ли соискатель в коллектив. Парное программирование — это возможность для кандидата прочувствовать на собственной шкуре, какой может быть работа с вами. И если ему не понравится этот опыт, ничего страшного, он имеет полное право отказаться от вашей вакансии.
- Еще один интересный принцип – иногда «в комплект» к студенту-отличнику ставят троечника.
- Что касается пары разработчиков, то они каждые полчаса или час меняются ролями.
- Когда какой-то программист застрял в какой-либо проблеме, не очевидно, что он или она сразу обратится за помощью.
- Результаты исследований соответствуют и моим наблюдениям.
Правда в том, что иногда Junior вообще не может выполнить задачу. Они могут просто-напросто не знать какого-то алгоритма, библиотеки, особенности языка и не знать о том, что они пока еще этого не знают (те самые unknown unknowns). Здесь не важно, это недостаток знаний об уже разработанной части системы или о том, что только предстоит разработать.
Бывает так, что в процессе работы напарники теряют общий контекст — например, один закапывается в детали реализации, а другой — в нюансы архитектуры. Если это случится, обсудите с напарником все неясности, найдите общий язык и синхронизируйтесь снова. Парное программирование эффективнее, чем обычное код-ревью, так как баги устраняются на лету, по мере их появления. Кроме того, оно решает и другую важную проблему — негативное отношение к ревью кода. Те, кто должен оценивать чужой код, нередко относятся к этому формально, а те, чей код оценивают, переживают из-за критики или не соглашаются с ревьюерами. Известно, что чем раньше обнаружен баг, тем дешевле его исправить.
А может уровень окажется одинаковым, а приоритетные области разные, тогда обмен опытом будет продуктивным и полезным для каждого участника. Конечно, всё зависит от коллектива, отношений и личных качеств обучающихся. Иногда все складывается наилучшим образом, и каждый выполняет именно ту часть задачи, в которой он разбирается и тандем работает. Кроме преимуществ для сотрудников, есть весомые плюсы для руководства.
Популярные Стили Парного Программирования
Это техника программирования, при которой исходный код создаётся парами людей, программирующих одну задачу, сидя за одним рабочим местом. Один программист («ведущий») управляет компьютером и, в основном, думает над кодированием в деталях. Другой программист («штурман») сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом.
Одновременно с этим парное программирование может мешать очень опытным разработчикам, у которых и так есть идея и структура решения. Им будет проще реализовать код в одиночку, а не тратить время на обсуждение идей. Если кратко, то это методика, когда над одним участком кода, проектом работают два разработчика. Обычно один из них пишет код, второй комментирует и помогает. Такая методика не панацея, но она многое даёт как компании, в которой отлажены такие процессы, так и самим специалистам. В западных IT компаниях все больше практикуют новый способ программирования на двоих.
Применение парного программирования, в противоречие мнению большинства наших менеджеров проектов, позволяет улучшить общую производительность команды. Парное программирование становится все популярнее. Метод постоянно проверяется на практике, разработчики рассказывают о нем в своих блогах и вдохновляют других, находят недостатки метода и пытаются их исправить. Согласованность базы данных — это требование, согласно которому любая транзакция базы данных должна изменять затронутые данные только разрешёнными способами. Любые данные, записанные в базу данных, должны быть корректными в соответствии со всеми заданными правилами, включая ограничения, каскады, триггеры и любые их комбинации.
Зачем Нужно Парное Программирование
Метод отлично подходит для обучения детей, но важно ставить в пару детей разного уровня и возраста. Если это будут сверстники с одинаковым уровнем знаний, парное программирование превратится в соперничество. А если уровень и возраст будут немного разными, получится продуктивная работа в команде. Ребенок с более высоким уровнем будет учиться через объяснения, а ребенок с более низким — через тягу за напарником. При работе в паре программистам проще находить и исправлять ошибки, работа и обучение идут эффективнее и быстрее, а дух команды растет.
По некоторым исследованиям, пускай довольно старым, устранение бага на каждом следующем этапе работы над проектом обходится в десять раз дороже, чем на предыдущем. «Меня успокаивает, что партнёр постоянно проверяет мой код. Я могу быть уверен, что сделал хорошую работу, если кто-то другой, кому я доверяю, наблюдал за ней и одобрил».
Поэтому для джуниора важно работать в паре с более опытным программистом. Да, это будет хардкор, потому что задачи будут сложными, а знаний недостаточно, но как говорится, тяжело в учении – легко в бою. Вот мы с вами и вступили обеими ногами на территорию парного программирования. Все было бы просто, если бы программист только обменивал свой код на зарплату.
Кроме того, практически все опрошенные заявили, что парная работа даёт им больше уверенности в своих решениях. «Штурман на заднем сиденье» — если штурман более опытен, чем ведущий, он берёт на себя принятие уже не только стратегических, но и тактических решений и как бы обучает начинающего. Если же наоборот, то ведущий параллельно с написанием кода может продумывать стратегию и обучать штурмана. Хотя бывают и исключения — джун тоже многому может научить.
Простые задачи могут быть усложнены парным программированием. Оно поднимает моральный дух, когда ты не остаешься один-на-один с трудными проблемами программирования. Если вы будете менять напарника для Всезнайки, скажем, каждую неделю, то каждый программист сможет получить и поделиться частью важной информации и почувствовать себя важным для команды.
Если вы будете писать код за одним рабочим местом – отлично. Совершенно необязательно делить между собой роли “писателя” и “читателя” – клава может произвольно переходить к тому, кто что-то придумал и хочет выразить это в программном коде. Второй в это время смотрит на то, что получается, указывает на возможные проблемы и ошибки, дополняет своими идеями. Эта модель работы идеально подходит для пары “эксперт–новичок”. Эксперт в роли экскурсовода выполняет функцию от А до Я — досконально рассказывает и показывает всю суть работы, а новичок находится в роли пассивного слушателя.
Парное программирование позволит учиться у другого разработчика и получать обратную связь по вашему коду. Стиль берет начало парное программирование для чего из экстремального программирования. Один пишет код, в то время как другой проходит TDD (Test-Driven Development).
В этом случае время написания программного кода может возрасти в несколько раз, а качество кода может оказаться хуже, чем если бы его писал один программист. Парное программирование – это практика гибкой разработки программного обеспечения, при которой два программиста используют одну рабочую станцию. Существует несколько проверенных временем стилей парного программирования. Но ведь в парах работают люди, люди с различными навыками, есть ли тут какой-нибудь подвох? Кроме того, опрошенные в ходе исследования разработчики заявили, что они более уверены в результате, чем в случае одиночной работы.
Джуниору будет невероятно интересно и полезно работать с сеньором, а вот последнему – вряд ли особенно интересно будет воспитывать новичка. Если мы говорим не о целенаправленном процессе обучения, на которое отведено фиксированное время, то лучше выбирать себе в пару человека с уровнем, близким к вашему. Еще один интересный принцип – иногда «в комплект» к студенту-отличнику ставят троечника. Считается, что иногда именно отстающий в учебе может подать интересную идею или показать метод работы, незнакомый отличнику, использующего привычные шаблоны. Но, как показывает практика, чаще такое выливается просто в растягивание времени. Задачу, которую отличник в одиночестве выполнил бы за полчаса, в паре можно выполнять и все два.
Если периодически менять напарников, то постепенно все программисты небольшой компании научатся работать друг с другом. Или хотя бы поймут, с кем им комфортно работать, а с кем нет. Разработка через тестирование — подход к разработке, при котором сначала пишется тест, а потом код, который должен удовлятворять условиям этого теста. Попробуйте найти на форумах опытного разработчика и попросите его покодить вместе. Это действительно самый быстрый и эффективный способ научиться чему-то новому. Если обобщить, парное программирование требует от участников развитых мягких, или гибких, навыков (недаром работа в парах — это одно из воплощений Agile-разработки).
Кроме того, объединение программистов для совместной работы может повысить сплоченность, доверие и уважение команды. Со временем это возросшее чувство командной работы может улучшить общее качество продукции отдела программирования. Как отмечает Agile Alliance, еще одним преимуществом парного программирования является то, что оно ведет к лучшему распространению знаний в команде разработчиков. Строгое парное программирование – более строгая версия стиля Штурман/Водитель, в которой «Штурман» говорит «Водителю» что делать, а «Водитель» только пишет то, что ему говорят.
Если у кого-то из них есть идея о том, как действовать, они попытаются это сделать, прежде чем обратиться к другим. Новые сотрудники часто борются с контекстом кодовой базы, но не со знанием программирования. Ветераны хорошо разбираются в контексте, но иногда они склонны срезать углы, чтобы быстрее справиться со своими задачами. В идеале это должен быть человек, который пишет на том же языке, что и вы, но более опытный.
А чтобы перевести теоретическое и эфемерное знание в хорошо работающий навык, необходима практика. Если мы обратимся к обучению иностранным языкам, то просто переписывать упражнения из учебника не очень эффективно. Настоящая отработка возможна при живом общении в парах или команде, когда мы пользуемся языком так, как в жизни.
В работу вступает психологическая составляющая специалистов. Например, эксперт может нервничать из–за большого потока вопросов новичка, отвлекающих работать или же возник спор на личностной почве. Но, командная работа — есть командная работа, поэтому следует избегать как можно больше личных моментов, набраться терпения и заострить внимание на задачах. «Одна голова хорошо, а две лучше» – старая поговорка, но уже в новом формате. Стоит признать, программирование совершенствуется со скоростью света точно также как и вся сфера IT. Парное программирование — свеженькая практика, которая однозначно заслуживает должного внимания.