Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Парне програмування в деталях, частина 2. Практика

Мене звати Юрій Бондаренко, я співпрацюю з EPAM у ролі Senior Software Engineer. 22 лютого 2022 я закінчив працювати над другою частиною статті про парне програмування. Все було готово для того, щоб передати її в редакцію. Але вже 24-го мене розбудили звуки вибухів та страшна картина за вікном мого рідного Харкова. Виходячи з логів охоронної системи, ми разом з родиною зібралися за 15 хвилин. Це був день, коли змінились ми та все навколо.

Пройшов місяць і я потроху опанував себе. В якийсь момент навіть знайшов цю статтю на лептопі, але подумав: «Навіщо це все?», «Та вона ще й російською». І ось зараз, вже влітку я вирішив, що її можна перекласти і опублікувати. Гадаю, що ця стаття допоможе вам хоча б на хвилинку відволіктися від новин та отримати корисну інформацію.

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

Сподіваюсь, мій практичний досвід віддаленого парного програмування стане в нагоді. А розпочнемо з тих завдань, які для нього не підійдуть.

Що не пасує робити в парі

Я впевнений, що будь-яку методику чи інструмент варто використовувати там, де він буде максимально корисним. Виходячи з цього, парне програмування не слід застосовувати для завдань, які значно ефективніше робити наодинці. Ось кілька прикладів:

Нудні/ тривіальні завдання

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

Те, що можна зробити самому

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

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

Для вирішення цієї дилеми є кілька шляхів:

  • періодично давати завдання, над якими розробники-початківці можуть працювати самостійно;
  • для деяких завдань формувати пари, що складаються з двох джуніорів.

Цілком невідоме

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

Отже, ви не бачите перешкоди, щоб спробувати парне програмування. Яку техніку варто використати саме вам?

Техніки парного програмування

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

Драйвер и навігатор

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

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

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

У навігатора основна мета — спостерігати за діями драйвера, переглядати код під час процесу, ділитися думками і давати вказівки. Він також стежить за більш глобальними проблемами та помилками, продумує наступні кроки.

Використовуючи цю техніку, потрібно не забувати про деякі важливі правила:

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

Пінг-понг

Цей метод передбачає роботу через TDD (test driven development) та ідеально підходить для завдань, у яких є чітко визначені вимоги, що піддаються опису за допомогою тестів.

У цьому методі на першому кроці один з розробників пише тест, а другий — реалізацію, яка дозволить йому пройти. Після цього вони міняються ролями. Між ітераціями можна проводити сесію спільного рефакторингу. Цей підхід також називають Червоний-Зелений-Рефакторинг.

Без зміни ролей

Техніка найкраще підходить для передачі знань чи навчання. Основна ідея полягає в тому, що драйвер повністю довіряє навігатору, а навігатор виконує роль спостерігача та керівника.

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

Віддалене парне програмування

Так склалося, що практично весь мій досвід парного програмування був віддалений і почався ще 7 років тому. Зараз це дуже актуально, а мені якраз є чим поділитися.

Інструменти

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

Багато інструментів для відеоконференцій підтримують такий функціонал, також IDE від JetBrains нещодавно представили своє рішення для віддаленої спільної розробки, аналоги є і для VSC, Atom та інших середовищ розробки.

Існують також інші опції: наприклад, популярне колись окреме програмне рішення Screenhero у 2015 купив Slack для реалізації можливості спільної роботи у своєму продукті.

Якість звуку

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

Також варто задуматися про якісну гарнітуру: вона значно покращує рівень сприйняття голосу і дозволяє ізолюватися від зовнішніх звуків.

Використовуйте відео

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

Щоб не втрачати цей контакт і при онлайн-роботі, вмикайте камери та стежте за мімікою один одного. Іноді це дозволяє розпізнати проблеми.

Обмеження мережі

Не забувайте про те, що робота з використанням мережі може накладати певні проблеми: затримки у відгуку IDE, звуці, відео тощо. Універсальної поради для боротьби з цими складнощами немає, однак, корисно бути попередженим.

Перерви

Як і з офлайн парним програмуванням, не забувайте робити перерви у роботі. Можна разом випити каву-чай та обговорити щось не пов’язане з поточним завданням. Такі розмови допоможуть створити відкритішу атмосферу та підтримувати позитивний клімат у компанії чи команді.

Тонкощі

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

Підготовка до роботи

Перш ніж безпосередньо розпочати програмування, необхідно виконати підготовчу роботу:

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

Тайм-менеджмент

Під час роботи в парах дуже важливо чітко стежити за часом. Це допоможе уникнути різноманітних проблем (найяскравішою з яких, мабуть, є «захоплення клавіатури»). Хорошим рішенням може стати техніка помідора. Вона дозволить не забувати про зміну ролей і таку важливу частину процесу як відпочинок.

Домовляйтесь про плани на день

Використовуйте календар для бронювання спільного вікна для роботи над завданням. Не запізнюйтеся та цінуйте час один одного.

Уникайте керування один одним

Не варто займатись безпосереднім командуванням один одним. В такому випадку ви не даватимете колезі часу на роздуми. Прямі команди «Створи клас з ім’ям ...», «натисніть shift 3 рази ...» і т.п. збережіть для іншого випадку.

Нетерплячість (правило 5 секунд)

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

Документація

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

Створюйте нові пари

У парах постійно мають відбуватися ротації. Причин можна виділити декілька:

  • так ви уникнете концентрації певних знань в одній парі;
  • не будете «перенасичені» один одним у парі;
  • даватимете відпочинок під час роботи над чимось складним;
  • позбудетеся «прив’язаності» до конкретної людини, що нівелює складнощі при виході когось із пари у відпустку на лікарняний тощо.

Частоту ротацій кожна команда обирає самостійно: у когось це один спринт, у когось — тиждень.

Навіщо це все (замість висновку)

У рамках двох статей ми говорили про переваги використання парного програмування, але ще більше — про проблеми, недоліки та обмеження. То навіщо нам усе це? Невже парне програмування справді варте того?

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

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

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Привіт, шукаю пару для live-програмування php.

Мав трохи такого досвіду, він був не зовсім канонічним, там просто хтось працював, а інші дивились 😁
Можу сказати, що це прикольно для обміну досвідом написання коду, для аналізу проблем з різних боків чи для проведення мозкового штурму.
Бо коли такі матьорі сіньйори-одиночки як Міша тут в коментах спішать закривать таски і рапортувать на стендапі що все готово, то ти тільки через рік-другий можеш зрозуміти, що твій колега взагалі не відбиває дупля скажем в патернах, загальноприйнятих підходах чи по замовчуванню пише нечитаєму дичину (якщо наприклад, немає регулярного код-ревью).
Але разом з тим погоджуюсь, що оця канонічна штука з однією клавіатурою і драйвером-штурманом, з 5-секундним мовчанням перед питаннями це щось утопічне і не життєздатне в типових канторах.
Також погоджуюсь з тим, що пари сіньйор-джуніор це типу вчитель-учень, це більше лекції, а не парне програмування, там одному буде скучно, а другому тяжко. Для нормальної атмосфери треба хтось рівний і з подібними цінностями, почуттям гумору і т.ін.

Не читаючи: ЕПАМ => російське => за кораблем

Та там вся стаття про те, як програмувати в стилі «ковгосп». Ти небагато втратив.

100%
Навігатора можна наймати раз в місяць. І то, чим більше тих навігаторів, тим більший рандом в ідеях. Суперечать правилам юзабіліті, дизайну і взагалі виходять за рамки, тупо витрачають час. Толку з тих спостерігачів. Один раб + 5 шаряться з майже однаковими зарплатами.

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

В мене є різний досвід )) Скажу навіть, що частіше це кодування на рівних, наприклад коли потрібно накидати якийсь прототип, вирішити каверзну проблему, або коли в когось є якісь унікальні знання/навички які хочется залучити. Але, люди часто забувають або взагалі не вважають парне програмування інструментом вирішення тої чи іншої проблеми. І як результ розмовляють про код )

Тому що це не інструмент, це — ідіотизм, вибачте. Дев’ять жінок не народять дитину за місяць.

Слово ідіотизм придумали дивляичись на таких як ви

Дякую за коментар, тільки дуже цікаво чого ви порівнюєте це з біологічним процессом, а не наприклад з будівництвом стіни в будинку?

Окей. Парне программування, це як дати двом будівникам один молоток та чекати, що вони почнуть цвяхи швидше/краще забивати.

Це як порівнювати керування літаком(2 пілоти) та керування мотоцикла(один пілот)?

В літаку треба перевіряти один одного в ріалтаймі. В программуванні ж для цього розумні дядьки придумали код-ревью.

Взагалі, я вважаю, що код-ревью це теж такий собі дуже гострий інструмент, який часто використовується там, де не потрібно (де можна робити фігак-фігак і в продакшен) чи коли розробники всі приблизно одного рівня (хто там кого перевіряти буде?), та в багатьох інших та є джерелом сварок та суперечок. Але якщо його використовувати з розумом та в коректних ситуаціях, то можна отримати деякий профіт.

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

Парне управління літаком — це окрема дисципліна яку довго і нудно вивчають.
Управління мотоциклом з пасажиром теж цілком собі парне.

У вас якось аналогії всі повз касу:
Швидше, дитину за місяць — а хто очікує що це буде швидше? Зазвичай у всіх є розуміння що парна робота забирає більше людино-годин, на це йдуть заради інших переваг. У попередній частині статті, до речі, більш швидкий результат і не згадується в списку переваг.
Краще — тут же і сказано що для тривіальних задач (аналогії «класти цеглу» і «забивати цвяхи») цей метод буде зайвим, але ваші робочі задачі ж мабуть трохи складніші, правда?

Ні. Мої задачи — писати круди, міграції та веб-морди. Для цього не потрібен помічник.

наприклад з будівництвом стіни в будинку?

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

Просто як це відбувається? Приходить Вася і каже «ей, Пєтя, давай разом попрограмуємо?» А у Пєті свої таски і треба на стендапах свій статус озвучувати. Мабуть треба щоб лід або пм якось це просували, визначали таски де парне програмування буде ефективним.

Погоджуюся, бо я мав схожі моменти коли ми працювали над тасками менш досвідченого учасника команди. Мені здається варіант коли у всіх свої таски тут треба переосмислювати, нема таски на Васю, є таски на команду. Це зводиться до відповідальності і code ownership.

На стендапі так і кажу: робив таку то таску, парно програмувас з таким то мембером і поясню чого. Ще не разу ні хто мені не казав не роби більше так. З Ваших слів здається що у вас не команда, а просто купка індівідуалістів. І не забуваємо, що час сессії потрібно шукати такий який буде комфордний для обох )

Воу воу, не ображайте мою команду, вони молодці )
Мені просто цікаво, як цей процес впроваджується бо за свою кар’єру я ніколи не бачив парного програмування ініциатива якого йде «знизу» і причина якого не «в мене є проблема, допоможіть». Підкажіть, а в командах де ви працювали — тількі в вас були сесії з парного програмування з вашої ініціативи чи інші тіммейти теж таке практикували? )

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

Приходить менеджер та каже, мов, я тут прочитав якусь чергову книгу по «ефективному» керівництву і зараз ми почнемо впроваджувати усю цю дичину.

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

Пропоную нову практику: программістський трійничок.

на сленге это уже называется train или паровозиком ))

Підписатись на коментарі