ПАРНОЕ ПРОГРАММИРОВАНИЕ: ПЛЮСЫ И МИНУСЫ

АННОТАЦИЯ

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

Ключевые слова: парное программирование, стратегия, драйвер, навигатор.

Впервые услышав о парном программировании, неопытные специалисты принимают упомянутый метод за некое новое веяние, которое еще не успело устояться в мире Software Engineering. Однако это не так, ведь оно активно использовалось еще в прошлом веке. Данная ситуация имеет место быть не просто так. Дело в том, что в силу своей специфичности оно не так сильно распространено и встречается, далеко не во всех компаниях. Для наглядности можем взять жизненную ситуацию. Когда Junior приходит на свою первую работу, он зачастую видит примерно такую картину: Отдел из n-го количества программистов, несколько ведущих специалистов и Team Lead. И если не говорить о рефакторинге, то моменты, когда другой специалист будет взаимодействовать с твоим кодом это Code Review. Код работает, проверен кем-то из ведущих специалистов, вот, собственно, и вся история. Почему же, далеко не все компании прибегают к этому методу? Давайте разберемся с этим дав внятную характеристику парному программированию, рассмотрим основные стратегии, выделим преимущества и недостатки, отчего построим свой вывод.

Парное программирование является одним из видов экстремального программирования. Парное программирование это метод разработки программного обеспечения двумя разработчиками [1]. В течении процесса программисты делят между собой 2 роли: ведущий и ведомый или как принято называть: драйвер и навигатор. Драйвер занимается непосредственно написанием кода, в то время ка навигатор контролирует написание этого самого кода и направляет драйвера. Можно сказать, что два специалиста взаимодополняют друг друга. В то время как один сфокусирован на реализации конкретного метода, другой видит всю картину происходящего, замечает ошибки (здесь речь не о синтаксисе) и может сэкономить большое количество времени своим вмешательством. Напарники меняются ролями по договоренности, что должно эффективно влиять на работу. Дабы не быть голословным приведем цитату из книги Коберна Алистера: «Согласно статистике, программисты, которые ранее работали в одиночку, а теперь работают в парах, считают, что им больше нравится новый способ работы. Одной из причин они называют возросшую уверенность в качестве своего кода (коэффициент ошибок в том и другом случае подтверждает последнее замечание)» [2].

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

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

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

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

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

Вне зависимости от специфики стратегии ПП, его суть остается одной – в данном процессе участвуют 2 специалиста в работе над одним проектом.

Выделим плюсы и минусы данного подхода.

Плюсы:

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

Минусы:

• Психологические особенности. Некоторые программисты критично относятся к самым просты итерациям Code Review, что уж говорить о парном программировании.
• Не все коллективы могут изначально быть идеальными, между опытными разработчиками могут возникать споры о необходимости использовать тот или иной метод в модулях, что может снизить работоспособность.
• У каждого программиста свой график и своя скорость работы, зачастую попытки синхронизировать эти вещи кончаются провалом.
• Далеко не все руководители, зная об этом методе берут во внимание его плюсы (улучшение архитектуры и уменьшение ошибок). В первую очередь руководитель думает о том, что он сажает решать одну задачу двух специалистов, что на первый взгляд не кажется выгодно.

В большинстве случаев этих минусов хватает, чтобы не использовать парное программирование в работе над проектами. Кроме того, данный эффект усиливается тем, что в компании занимающейся реализацией того или иного продукта один человек занимается frontend-разработкой, а другой реализацией backend [3]. Если брать во внимание, что обычно проектов или задач у компании несколько, то и распределение разработчиков происходит равномерно в зависимости от этих проектов, что в свою очередь не дает места парному программированию. Но не будь хороших практик, то и разговора об этом методе вовсе и не было бы.

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

Список литературы:

1. Майк Кон. Гибкая разработка ПО. Вильямс, 2016 г. Succeeding with Agile: Software Development Using Scrum. [c.221].
2. Парное программирование в Vineti // Хабр URL: https://habr.com/ru/post/471138/ (дата обращения: 20.12.2019).
3. Парное программирование: преимущества и недостатки // КнигоГид URL: https://knigogid.ru/books/35872-parnoe-programmirovanie-preimuschestva-i-nedostatki/toread (дата обращения: 20.12.2019).