Згаяний час чи корисний інструмент? Три історії розробників про переваги та недоліки парного програмування
Парне програмування може стати чудовим способом онбордингу людей до проєкту та спільної роботи над новими складними технологіями. Проте іноді робота в парі сповільнює кодинг і призводить до конфліктів.
Ми поспілкувалися з трьома розробниками про їхній досвід у парному програмуванні та попросили поділитися власними історіями та порадами.
Сергій Журавель, FE Lead Developer, Temy
Парне програмування — це такий собі одноріг: про нього багато чули, але мало хто бачив. Я давно вивчав екстремальне програмування та цікавлюся парним програмуванням, сам його теж практикував.
Екстремальне програмування — методологія розробки програмного забезпечення, одна зі гнучких методологій розробки. Має на меті поліпшення якості програмного забезпечення та чутливість до змін у вимогах замовників. Екстремальне програмування радить часті «випуски» програми у коротких циклах розробки, щоб поліпшити продуктивність праці та виконання змін вимог замовника.
Нещодавно парне програмування довелося вводити на одному з проєктів, над яким я працюю, ще й у доволі цікавих умовах.
Парне програмування часто використовують в екстремальному програмуванні та гнучкій розробці (Agile-методології). Зараз у нас формується команда, що працює за цікавою методологією, щось між Scrum і Kanban. Однак команда почала будуватися з автономних спеціалістів, хоча в Agile-програмуванні, особливо в Scrum, намагаються формувати T-shaped фахівців. Ми разом зі СТО цього проєкту помітили, що в певний момент команда розбилася на підкоманди, які складаються з бекенд-розробників і фронтенд-розробників. Іноді вони між собою комунікують і навіть можуть домовитися. Ми думали, як їх об’єднати, водночас не змушуючи до того, щоб виконувати роботу один одного.
Тому нещодавно почали робити end-to-end тести й помітили, що вони можуть стати точкою групування команди. Вирішили, що писати їх будуть всі: і фрондент, і бекенд — попри те, що end-to-end тести пишуть на JavaScript, який значно ближчий нашим фронтенд-розробникам, адже бекенд у нас пишуть на Go. Тож я запропонував методику парного програмування. Ми почали збиратися разом, — фронт і бек, — брати декілька тестів і разом над ними працювати.
Я розумію та знаю, чого бояться програмісти в парному програмуванні. По-перше, є ризик витратити зайвий час розробників, адже дві людини одночасно працюють над одним завданням. Однак здебільшого все навпаки: працюючи над одним завданням, два розробники можуть виконати його набагато швидше. Зі свого досвіду знаю, що під час кодингу часто виникає ступор. Але достатньо розповісти про свої негаразди колезі, і той швидко зрозуміє, що не так. Парне програмування частково розв’язує цю проблему.
Крім того, після спільної роботи над кодом його функціонал знають одразу декілька розробників. В іншому разі людина самостійно розв’язує завдання й лише вона розуміє, що, чому і як робила. Тоді інформація може загубитися, адже розробник не завжди документує кожен свій крок, і код можуть не зрозуміти його колеги. Парне програмування значно зменшує ризики виникнення таких проблем. Це одна з причин, чому його використовують, адже обмін знаннями відбувається одразу.
Парне програмування — чудовий спосіб розв’язання конфліктів між двома розробниками. На жаль, робочі суперечки — непоодинока річ. Трапляється, що два розробники одного рівня вважають, що саме їхня думка правильна, адже мають різні світогляди та підходи до роботи. Я маю кілька варіантів розв’язання таких питань:
- Очевидний. Якщо склалася погана ситуація, варто під’єднати ліда, менеджера або СТО. Не можна жалітися на іншого програміста, однак варто розповісти менеджеру про ситуацію на проєкті, пояснити обидві думки й попросити їх прокоментувати. Фінальне рішення залишається за старшим колегою.
- Парне програмування. У такому разі обидва розробники мають показати, як саме працюватиме код, адже напарник по проєкту міг просто не розуміти цього. Коли разом виконуєш завдання, можна обрати кращий варіант.
Звісно, парне програмування використовують не на кожному проєкті. Наприклад, трапляються випадки, коли команда складається з автономних розробників, які, попри мінімальну взаємодію, чудово справляються з проєктом. Парне програмування більше зав’язано на Agile-напрямах. Часто команди спеціально підбирають для комфортної роботи разом, тож проблеми з парним програмуванням не виникає. Парне програмування не є шляхом розв’язання всіх проблем компанії. Це хороша річ для командної роботи, яка, втім, навряд чи підійде індивідуальним кодерам.
Працювати разом над одним кодом можна офлайн, коли два програмісти буквально сидять за сусідніми столами. Зараз із цим можуть виникнути складнощі, але, на щастя, є низка інструментів, які дають змогу практикувати парне програмування онлайн:
- Visual Studio Code. Популярний редактор коду, що має плагін Live Share, який використовують для спільної роботи.
- Cloud9 IDE я використовував раніше, але її викупила компанія Amazon, і тепер ця IDE є частиною AWS сервісів. Це гарний варіант для тих, хто працює з AWS.
- Є багато різних IDE, що мають режим спільної роботи, але можна також працювати разом під час відеодзвінка. Недолік цього підходу полягає в тому, що лише одна людина працює з кодом.
Ларіса Анцифрова, Front-end Engineer, SocialTech
Перший досвід парного програмування я здобула, коли треба було реалізувати на продукті новий функціонал. Ми чітко розуміли, що він незалежний, а оскільки в нас шість кросфункціональних команд, то для виділення бізнес-зони вирішили зробити це мікрофронтендом. Сформувався великий обсяг завдань, який ми розділили між двома розробниками. Перші завдання вирішили розв’язати разом, аби розібратися з особливостями третьої версії фреймворку Vue, прописати роутинг підпроєкту та сформувати структуру файлів.
Спочатку ми сфокусувались на роутингу. Зібралися разом: один розробник писав код, а інший підказував, скеровував, що і як краще зробити. Так ми заклали кістяк проєкту та визначили подальші кроки. Далі взялися за завдання, пов’язане зі створенням компонентів, та помінялися ролями. Разом прописали компоненти за синтаксисом оновленої версії фреймворку та вирішили, у якому стилі будувати код надалі. Наступні завдання вже реалізовували самостійно й паралельно.
Зараз здається, що тодішні завдання ідеально підходили для парного програмування. З роутингом мали справу обидва розробники, тож, витративши час на спільне написання коду, ми скоротили час на код-рев’ю й уточнювальні запитання. У написанні компонентів ми частково досягли своїх цілей, оскільки парно реалізували тільки один, і в ньому не скористалися усіма можливостями нової версії фреймворку.
Парне програмування допомогло краще розібратися з кодом, новою структурою та технологією. Крім того, у парі рішення ухвалюють швидше. Однак такий процес підхожий не для всіх типів завдань. Наприклад, якщо робоча задача вимагає рутинного написання бойлерплейту, парне програмування буде зайвим.
Я точно хочу повторити цей досвід, коли це буде доцільним, адже парне програмування часом стає в пригоді: поки один розробник пише якісь рутинні речі, інший міркує над наступними кроками, вивчає документацію та готується до майбутніх завдань.
На мою думку, парне програмування найбільше підходить у таких випадках:
- коли завдання комплексне і вимагає ухвалення кількох важливих рішень, які впливатимуть на всі наступні завдання;
- коли команда вивчає нову для себе технологію;
- щоб менш досвідчені фахівці підвищували навички написання коду, працюючи в парі з досвідченішим колегою.
Успішність парного програмування лежить у чітко поставленому завданні, розумінні загальних цілей та відкритому спілкуванні між учасниками.
Владислав Фурдак, CEO в Nearshore Devs
Перший досвід парного програмування я здобув ще 2015 року, коли працював у компанії DataArt. На проєкті я був уже досвідченим фахівцем, і зі мною працював практикант. Ми разом розбиралися з робочими завданнями, я підказував та показував йому, що і як робити. Звісно, це важко назвати повноцінним парним програмуванням — радше менторингом у формі парної роботи.
Справжнє парне програмування я практикував 2019 року, коли працював у невеликій продуктовій компанії на позиції Senior-розробника. Через те, що процес був складний та місцями занадто інженерний, нові люди не могли з ним розібратися одразу ж. Тому там практикували парне програмування, під час якого більш досвідчений розробник, який сам і написав половину коду, пояснював мені як новачку проєкт.
Ми влаштовували зідзвони, використовуючи спеціальну програму для спільного програмування Drovio. Чому не Zoom чи Google Meet? Вони надто викривлюють зображення під час дзвінка, геть не видно рядків коду. Тож ми знайшли програму, яка дає змогу виділяти необхідні рядки та брати під свій контроль курсор. Зображення також було набагато кращим.
Процес відбувався так: у нас з колегою було одне завдання на двох. Упродовж перших двох годин код писав більш досвідчений розробник, а я ставив запитання та спостерігав за роботою. Потім ми мінялися місцями. Я мав зрозуміти хід думок розробника, щоб я сам навчитися цього. Проєкт був дуже складний, і парне програмування серйозно полегшило мені онбординг.
Результат такої роботи був непоганим. Зрозуміти, як працює проєкт, набагато легше, коли бачиш, як завдання виконують спеціалісти вищого рівня. Однак когнітивно це непросто, бо кожен має свій темп роботи та унікальне мислення, важко стежити за роботою іншої людини. І навпаки, доводиться більше концентруватися, коли хтось спостерігає вже за тобою. Тож три-чотири години таких «вправ» — це повноцінний робочий день, втомлюєшся набагато швидше.
Коли йдеться про те, щоби ввести нового співробітника в курс справ, парне програмування може значно пришвидшити роботу. Однак коли йдеться про двох однаково досвідчених розробників, парне програмування, звісно, не гарантує пришвидшення виконання завдань.
Що точно є перевагою цього підходу — під час роботи в парі ти менше «засинаєш» та більше концентруєшся на коді. Навіть моєму більш досвідченому колезі дуже подобалося парне програмування, адже в такому режимі він працював продуктивніше. Це як «метод каченя»: ставиш перед собою каченя та проговорюєш йому все, що робиш під час написання коду. Так от я і був цим каченям :)
Мабуть, найважливіше під час парного програмування — робити перерви. Коли ти кілька годин безупинно працюєш, сильно втомлюєшся. Краще планувати сесії хвилин на 40 з перервами. Зараз я не маю завдань, де парне програмування буде доцільним. Але якби знову входив до складного проєкту з нуля, це було б доброю ідеєю. Якщо нічого надто складного немає, зазвичай парне програмування не потрібне. Крім того, це може бути занадто витратно для бізнесу.