Парне програмування: показання до застосування та правила етикету

20 травня
Олексій Мироненко, Senior Java-розробник, тімлід
Парне програмування: показання до застосування та правила етикету
Олексій Мироненко, досвідчений Java-розробник, вже вісім років керує розподіленими технічними командами. Олексій вірить, що софт об'єднує людей, а програмісти здатні контролювати робочі процеси та сам софт, який створюють. У його проекті активно застосовується парне програмування. Коли та як варто використовувати цю техніку — у статті Олексія.

Парне програмування — один із прийомів у методології екстремального програмування. Ця техніка відома ще з 1980-х років, а зараз вона виявилась особливо актуальною у зв'язку з розвитком мікросервісів і пов'язаних з ним змін у комунікаціях між розробниками.

ОСНОВИ ТЕХНІКИ ПАРНОГО ПРОГРАМУВАННЯ

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

Я бачив, як за одним монітором пише код команда з шести осіб, але це, звісно, нестандартна ситуація. Правда, ролі при цьому не дуже змінюються: як і раніше, лишається один драйвер, який користується клавіатурою та мишкою, та ті, хто допомагає розраховувати курс. Звісно, ці ролі не є перманентними, учасники процесу по черзі займають позицію ведучого: за часом або за необхідністю, в залежності від конкретної задачі.

Існує різновид парного програмування, відомий як пінг-понг, адаптований для розробки через тестування. Але особисто я близько знайомий якраз із класичним варіантом, коли один пише, а другий каже, куди рухатись далі.

ДИСТАНЦІЙНЕ ПАРНЕ ПРОГРАМУВАННЯ

Цей різновид парного програмування передбачає дистанційну роботу через інструменти спільного редагування коду. У ситуації відсутності прямого контакту підвищується значення комунікативних навичок. Тут складніше не втратити зв'язок і стежити, щоб людина на іншій стороні отримувала такий самий час безпосередньої взаємодії з кодом. Простіше, якщо програмісти часом працюють локально, розшарюючи екран, інакше в гру вступає неприємне відчуття лагу між моментами, коли ти друкуєш символи, й коли бачиш їх на дисплеї. Так само дивно виглядають снепшоти, які ми бачимо при затримках мережі, коли хтось скролить екран. Але дотримання відносно простих правил етикету дистанційного спілкування дозволяє уникнути більшості проблем.

КОЛИ ПАРНЕ ПРОГРАМУВАННЯ КОРИСНЕ?

Я не назву ситуації, коли без парного програмування не можна обійтися. Але гаряче рекомендую використовувати його, коли ви всією командою освоюєте невідому предметну галузь або новітню технологію, використання якої вимагає проект. Парне програмування значно прискорює обмін знаннями та дозволяє члену команди, який знає про потрібний предмет хоча б трохи більше за інших, донести цю інформацію до всіх одразу, а не розмовляти з кожним індивідуально.

Другий ідеальний юзкейс для парного програмування — випадок, коли ми пишемо щось критично важливе. Ця техніка дозволяє не відправляти код на рев'ю по 20 разів різним людям, супроводжуючи щоразу листом зі складними запитаннями. Написати код разом, а потім разом же його перевірити — для систем з високою значимістю підхід ефективний.

Доведено, що паралельне програмування значно підвищує якість коду — приблизно на 15 %. Хоча успіх використання прийому, в першу чергу, залежатиме від конкретних людей та їхнього досвіду в його застосуванні. Якість коду, думаю, зростає перш за все тому, що ми отримуємо не просто більший обсяг аналізу коду, а отримуємо його на набагато більш ранніх етапах.

КОЛИ ПАРНЕ ПРОГРАМУВАННЯ НЕ ПРАЦЮВАТИМЕ?

Навряд парне програмування підходить для восьми годин безперервної роботи. Якщо проект горить і палає, парне програмування навряд працюватиме з такою швидкістю, з якою ви захочете. У парі досить зручно рефакторити написаний у пожежному порядку код, приводячи його у вигляд, прийнятний для команди. Але швидко писати набіло вдвох, мабуть, не дуже й зручно.

Парне програмування — складна комунікативна вправа, воно погано працює там, де люди занадто звикли до ієрархії. Особливість людського спілкування в тому, що якщо один з пари бере на себе роль старшого, другий, якщо він не схильний до конфлікту, автоматично приймає роль джуніора, незалежно від досвіду та рівня підготовки. З точки зору проекту це контрпродуктивно, але щоб уникнути подібного, за всіма групами на перших порах доведеться уважно стежити, підтримуючи рівність.

ПОБІЧНИЙ ЕФЕКТ

Неосновний, але позитивний ефект парного програмування — можливість мінімізувати кількість задач, які одночасно перебувають у роботі. У загальному заліку команда набагато менше розпорошуватиме увагу та заощадить час на перемиканні контексту. Паралелізм буде нижче, але задачі розв'язуватимуться якісніше, і жодна з них не зависатиме надовго. Ви ж знаєте, як іноді таск, на який відводиться по 30 хвилин на день у загальному потоці зокрема термінових справ, встигає застаріти задовго до остаточного закриття?

НАЛАГОДЖЕННЯ КОМУНІКАЦІЙ

Незважаючи на те, що комунікації в парному програмуванні є складним питанням, при правильній постановці процесу воно допомагає налаштувати обстановку в команді краще, ніж традиційне код-рев'ю. Мій досвід показує, що досвідчені розробники, які недавно прийшли в нову команду, часто сприймають зауваження до написаного ними коду як особисту претензію. Письмовий переклад такої оцінки в інтерактивну форму дозволяє уникнути конфліктів, оскільки при спілкуванні віч-на-віч люди менш схильні до ворожих інтерпретацій коментарів співрозмовника.

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

ПРАВИЛА СПІЛКУВАННЯ

Суворих правил тут, звісно, немає, а загальні рекомендації виглядають дуже простими:

  • не бійтеся говорити вголос;
  • будьте ввічливими та доброзичливими;
  • не впадайте в повчальний тон.

Рекомендую дуже простий трюк. Якщо бачите, що людина поруч робить не те, що потрібно, порахуйте до 5, а потім до 10. Якщо вона продовжує робити не те, потрібно про це сказати. Миттєва реакція на помилку може збити настрій напарника. Цілком можливо, дійшовши до крапки з комою, він повернеться на початок і виправить неточність, яку й сам одразу помітив.

Збивши іншого з думки, ми ризикуємо відразу щось втратити. Але якщо це вже сталося, головне якомога швидше повернутися до нормальної комунікації. Наприклад, можна швидко обговорити питання, які виникають, а продовжити розмовою про фідбек — з'ясувати, в якій формі ваш співрозмовник хотів би отримувати зворотний зв'язок. Ця тема виходить за рамки парного програмування, але це дуже важливо в будь-якій команді й обстановці. Самому ж найпродуктивніше приймати будь-який зворотний зв'язок як подарунок, хоча цього доведеться вчитись. Важливо пам'ятати, що будь-хто, хто зважився на критику, ризикує заради вашої спільної роботи. Він іде на ризик конфлікту, яких ніхто не любить, і заслуговує на подяку.

Ще одна складна навичка — відмовитись від зайвих припущень. Говорячи з іншими людьми, ми часто робимо комунікаційну помилку — думаємо, що знаємо, що вони мають намір зробити або сказати. Такі здогадки часто затьмарюють очевидні факти, які якраз є відправною точкою для конструктивної розмови. Припустимо, якщо вас перебили, навряд варто говорити напарнику: “Ти, звісно, вважаєш себе найрозумнішим!”. Набагато корисніше помітити: “Я збирався виправити цю строчку за дві секунди. Ти помітив важливу помилку, але ти згодний, що мене перебив?”. Сухі факти: було зроблено справедливе зауваження, але помилку ви й самі збирались виправити. Далі можна вирішити, як уникати таких ситуацій у майбутньому, якщо вони вас дратують.

ПЕРСПЕКТИВА ЗРОСТАННЯ

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

До речі, перші програмістки, які працювали з машиною Eniac, діяли саме в парі. Вирішили, що тільки так її можна швидко освоїти, а були вони досить розумними.

СТАВЛЕННЯ БІЗНЕСУ

Якщо IT не є основна сферою діяльності замовника, йому буває важко повірити, що якість коду, заміряти яку дуже складно, варта додаткових зусиль. Для бізнесу з іншої предметної області поняття якості взагалі може виглядати чимось абсолютно абстрактним. Тобто очевидний ризик використання нової методології обіцяє вкрай туманні переваги — інакше кажучи, нагадує аферу.

Якщо ви впевнені, що парне програмування у вашому проекті виправдане, варто запропонувати бізнесу зрозумілу угоду, ввівши метрики для ухвалення рішення. Швидше за все, допомогти можуть статичний аналіз коду і при можливості сторонній аудит. Парний кодинг може бути корисним замовникові, якщо продукт у перспективі з'їдатиме менше ресурсів на підтримку або додавання нових фіч. Але перетворювати запит типу “ми хочемо писати більш елегантний код” на форму “ми хочемо скоротити ваш річний рахунок на обслуговування” доведеться вам. Тому що з боку бізнесу запитання, чому дві людини виконують задачу, з якою будь-яка з них впоралася б самостійно, виглядає цілком розумно.

Простіше за все пропонувати парне програмування для роботи над критично важливими системами, зонами високого ризику або у сферах, що знаходяться під пильним контролем регуляторів. Якщо замовнику важлива довгострокова перспектива проекту, переконати його буде легше. Позитивний момент — при впровадженні парного програмування йдеться, швидше, не про інвестиції, а про довіру до команди. Паралельне програмування знижує кількість задач, що водночас перебувають у роботі, але загалом обходиться не дорожче і працює не повільніше за більш звичні методи розробки. Найскладніше пояснити, чому дві голови за одним монітором — добре, в умовах мікроменеджменту. Але, на щастя, на допомогу можуть прийти дослідження і вимірні дані — наприклад, кількість виявлених клієнтом дефектів системи.