Парне програмування в деталях, частина 2. Практика
Мене звати Юрій Бондаренко, я співпрацюю з EPAM у ролі Senior Software Engineer. 22 лютого 2022 я закінчив працювати над другою частиною статті про парне програмування. Все було готово для того, щоб передати її в редакцію. Але вже
Пройшов місяць і я потроху опанував себе. В якийсь момент навіть знайшов цю статтю на лептопі, але подумав: «Навіщо це все?», «Та вона ще й російською». І ось зараз, вже влітку я вирішив, що її можна перекласти і опублікувати. Гадаю, що ця стаття допоможе вам хоча б на хвилинку відволіктися від новин та отримати корисну інформацію.
Отже, у першій частині статті про парне програмування ми говорили про плюси, мінуси та засади такого підхода. У другій — розберемо техніки, які можна використовувати, щоб отримувати найкращий результат, та задачі, які не вдасться розробляти в парі.
Сподіваюсь, мій практичний досвід віддаленого парного програмування стане в нагоді. А розпочнемо з тих завдань, які для нього не підійдуть.
Що не пасує робити в парі
Я впевнений, що будь-яку методику чи інструмент варто використовувати там, де він буде максимально корисним. Виходячи з цього, парне програмування не слід застосовувати для завдань, які значно ефективніше робити наодинці. Ось кілька прикладів:
Нудні/ тривіальні завдання
До цього типу можна віднести ті, для яких команда має чіткий шаблон, за яким подібні завдання вирішуються. У такому разі перевірка коду та контроль у реальному часі не потрібні і спільна робота буде зайвою. З іншого боку, не слід забувати, що велика кількість рутинних дій може бути ознакою поганої архітектури. У такому разі парна сесія здатна покращити її або знайти «корінь зла».
Те, що можна зробити самому
Парне програмування несе як велику користь, так і великі проблеми для джуніорів. Працюючи завжди в парі, менш досвідчений розробник може втратити професійну впевненість у собі.
Також парні сесії не допомагають навчитися розбиратися у питаннях самостійно. Варто пам’ятати, що коли людина сама вирішує якусь проблему, шукає вихід, її навчання може бути ефективнішим. Так, інженер самостійно експериментує та покращує свій код. У той самий час, це ж може привести його в кролячу нору.
Для вирішення цієї дилеми є кілька шляхів:
- періодично давати завдання, над якими розробники-початківці можуть працювати самостійно;
- для деяких завдань формувати пари, що складаються з двох джуніорів.
Цілком невідоме
Ще один тип завдань, для яких парне програмування не настільки ефективне, як робота наодинці, це завдання, в яких більшу частину часу потрібно витратити на вивчення або поглиблення знань у нових для фахівців в команді сферах. Це може бути як використання нових технологій, так і занурення у якийсь новий аспект бізнесу. Практика показує, що такі завдання ефективніше виконувати наодинці.
Отже, ви не бачите перешкоди, щоб спробувати парне програмування. Яку техніку варто використати саме вам?
Техніки парного програмування
Технік парного програмування багато і кожна з них оптимальна для певного роду завдань. Не обов’язково використовувати якусь загальноприйняту, але знання повного спектру технік значно спрощує адаптацію та знаходження правильного підходу при першому досвіді. Давайте розглянемо найпопулярніші з них.
Драйвер и навігатор
Назву цієї техніки часто перекладають як «водій та штурман», але мені здається цей варіант не дуже коректним. На мою думку, оригінальна назва більше відгукується з нашою сферою. Це скоріше не техніка, а класичне визначення ролей у парному програмуванні. Майже завжди є проблема з доступом до клавіатури, тому ці ролі можна використовувати і в інших техніках.
Ідея підходу полягає в тому, щоб мати два кардинально різні погляди на код — стратегічний і тактичний. Драйвер повинен бути сконцентрований на деталях (коді, що знаходиться під рукою), а навігатор повинен мислити глобальніше.
Драйвер — це людина, яка безпосередньо використовує клавіатуру (пише код). Його мета — вирішення невеликих завдань, ігноруючи кінцеву мету та більш глобальні проблеми. Також драйверу важливо озвучувати усі свої дії.
У навігатора основна мета — спостерігати за діями драйвера, переглядати код під час процесу, ділитися думками і давати вказівки. Він також стежить за більш глобальними проблемами та помилками, продумує наступні кроки.
Використовуючи цю техніку, потрібно не забувати про деякі важливі правила:
- почніть сесію з очевидної частини завдання, яке обговорили заздалегідь;
- не змішуйте ролі: будучи драйвером, не думайте про глобальні проблеми. І навпаки: як навігатор, не думайте тактично;
- регулярно змінюйте ролі;
- обговорюйте результат при кожній зміні ролей;
- майте чіткі цілі;
- використовуйте стікери та/або дошку для збереження ідей, кроків та потенційних проблем.
Пінг-понг
Цей метод передбачає роботу через TDD (test driven development) та ідеально підходить для завдань, у яких є чітко визначені вимоги, що піддаються опису за допомогою тестів.
У цьому методі на першому кроці один з розробників пише тест, а другий — реалізацію, яка дозволить йому пройти. Після цього вони міняються ролями. Між ітераціями можна проводити сесію спільного рефакторингу. Цей підхід також називають Червоний-Зелений-Рефакторинг.
Без зміни ролей
Техніка найкраще підходить для передачі знань чи навчання. Основна ідея полягає в тому, що драйвер повністю довіряє навігатору, а навігатор виконує роль спостерігача та керівника.
Цей метод схожий на мікроменеджмент і може бути корисним на перших етапах передачі знань. Ним не варто зловживати і слід пам’ятати, що кінцевою метою має бути перехід до класичного підходу зі змінами ролей.
Віддалене парне програмування
Так склалося, що практично весь мій досвід парного програмування був віддалений і почався ще 7 років тому. Зараз це дуже актуально, а мені якраз є чим поділитися.
Інструменти
Для віддаленого парного програмування основною проблемою є зручний спосіб спільного доступу до комп’ютера або середовища розробки. По суті необхідне рішення, яке дозволить двом людям використовувати екран з можливістю віддаленого керування комп’ютером.
Багато інструментів для відеоконференцій підтримують такий функціонал, також IDE від JetBrains нещодавно представили своє рішення для віддаленої спільної розробки, аналоги є і для VSC, Atom та інших середовищ розробки.
Існують також інші опції: наприклад, популярне колись окреме програмне рішення Screenhero у 2015 купив Slack для реалізації можливості спільної роботи у своєму продукті.
Якість звуку
До цього питання варто підійти вкрай відповідально. Найкраще знайти тихе місце без стороннього шуму, а якщо такої можливості немає, варто включати мікрофон лише в той час, коли він необхідний.
Також варто задуматися про якісну гарнітуру: вона значно покращує рівень сприйняття голосу і дозволяє ізолюватися від зовнішніх звуків.
Використовуйте відео
Здається не дуже важливим аспектом, але у разі віддаленого формату може бути ключовим. Важливою частиною живого спілкування є вираз обличчя, за яким легко можна прочитати емоції людини.
Щоб не втрачати цей контакт і при онлайн-роботі, вмикайте камери та стежте за мімікою один одного. Іноді це дозволяє розпізнати проблеми.
Обмеження мережі
Не забувайте про те, що робота з використанням мережі може накладати певні проблеми: затримки у відгуку IDE, звуці, відео тощо. Універсальної поради для боротьби з цими складнощами немає, однак, корисно бути попередженим.
Перерви
Як і з офлайн парним програмуванням, не забувайте робити перерви у роботі. Можна разом випити каву-чай та обговорити щось не пов’язане з поточним завданням. Такі розмови допоможуть створити відкритішу атмосферу та підтримувати позитивний клімат у компанії чи команді.
Тонкощі
Поділюсь практичними порадами, які накопичив за свій досвід використання парного програмування. Деякі пункти можуть здатися очевидними, однак, саме про такі речі ми найчастіше забуваємо.
Підготовка до роботи
Перш ніж безпосередньо розпочати програмування, необхідно виконати підготовчу роботу:
- Занурення у проблему. Цей крок властивий і самостійній роботі, але в парах є одна невелика відмінність. Вам необхідно обговорити завдання та розповісти, хто як зрозумів його. Так ви зможете уникнути неправильної комунікації та непорозумінь.
- Мозковий штурм. Мета цього кроку — пошук та обговорення можливих шляхів вирішення задачі. Мозковий штурм можна виконувати разом, а можна виділяти час на самостійне обмірковування і після обговорювати результати. Також на цьому етапі можна поділитися знаннями, щоб заповнити можливі прогалини в предметній галузі або технології, які необхідні для вирішення поставленого завдання.
- Підготовка рішення. В ідеальному випадку результатом цього етапу має бути підготовлений план дій, який містить як етапи розробки, так і методи тестування кінцевого результату. Його варто записати на стікері чи у якомусь загальному документі. Він не дасть забути про важливі деталі.
Тайм-менеджмент
Під час роботи в парах дуже важливо чітко стежити за часом. Це допоможе уникнути різноманітних проблем (найяскравішою з яких, мабуть, є «захоплення клавіатури»). Хорошим рішенням може стати техніка помідора. Вона дозволить не забувати про зміну ролей і таку важливу частину процесу як відпочинок.
Домовляйтесь про плани на день
Використовуйте календар для бронювання спільного вікна для роботи над завданням. Не запізнюйтеся та цінуйте час один одного.
Уникайте керування один одним
Не варто займатись безпосереднім командуванням один одним. В такому випадку ви не даватимете колезі часу на роздуми. Прямі команди «Створи клас з ім’ям ...», «натисніть shift 3 рази ...» і т.п. збережіть для іншого випадку.
Нетерплячість (правило 5 секунд)
У ролі навігатора намагайтеся бути терплячими. Побачивши якусь помилку у роботі драйвера — зачекайте 5 секунд, перш ніж щось казати. З великою ймовірністю він сам помітить цю помилку. Навігатору варто зменшити зайві втручання, оскільки вони переривають розумовий процес драйвера.
Документація
Складна тема для більшості проєктів, але й хороший приклад завдання, у якому партнери можуть дисциплінувати один одного. Роботу можна розділити на двох: наприклад, домовитися, що один з вас пише каркас/чернетку документації, а другий — займається її доопрацюванням та публікацією.
Створюйте нові пари
У парах постійно мають відбуватися ротації. Причин можна виділити декілька:
- так ви уникнете концентрації певних знань в одній парі;
- не будете «перенасичені» один одним у парі;
- даватимете відпочинок під час роботи над чимось складним;
- позбудетеся «прив’язаності» до конкретної людини, що нівелює складнощі при виході когось із пари у відпустку на лікарняний тощо.
Частоту ротацій кожна команда обирає самостійно: у когось це один спринт, у когось — тиждень.
Навіщо це все (замість висновку)
У рамках двох статей ми говорили про переваги використання парного програмування, але ще більше — про проблеми, недоліки та обмеження. То навіщо нам усе це? Невже парне програмування справді варте того?
На мою думку, тільки команда може вирішити, чи вона готова до парного програмування, і починати варто суто з її ініціативи. Процес застосування цього підходу досить непростий. Щоб команда змогла ефективно застосовувати його на практиці, кожному доведеться працювати над собою. Потрібно приділити увагу таким аспектам як концентрація, постановка та організація завдань, тайм-менеджмент, культура зворотного зв’язку та відкритість. Але кінцевий результат може перевершити усі очікування.
А як ви вважаєте, чи варто використати цю методику? Чи хотіли б її спробувати? Пишіть у коментарях, буду радий конструктивній бесіді.
28 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів