Серед розробників ця тема доволі дискусійна. Одні впевнені, що практика цікава та корисна для командної роботи. Інші ж вважають, що в ній немає сенсу.
Переваги, недоліки та особливості парного програмування розглянемо далі.
Що таке парне програмування?
Це підхід, за якого девелопери кооперуються в пари і разом пишуть код.
Зазвичай практика використовується в Agile- та Scrum-командах. Адже парне програмування орієнтоване на структурування роботи. Хоча і в традиційній Waterfall-моделі така організація робочого процесу може спрацювати.
У парному програмуванні є дві ролі: драйвер і навігатор
Драйвер пише код, навігатор підказує, що і як робити, та в режимі реального часу відстежує помилки. Під час сесії розробники постійно міняються ролями, наприклад, щопівгодини. Це класичний підхід.
У мене ж був досвід, коли до кодингу долучалися троє розробників. Один пише на 15-20 хвилин, інші асистують, і потім ротація. На тому ж проєкті була схожа команда із п’ятьох фахівців, які теж одночасно працювали над кодом.
Тут ключова ідея — у спільному обговоренні рішення на нижньому рівні. За традиційної схеми роботи команда визначає лише високорівневі завдання.
Наприклад, дані йдуть із точки A в точку B через точку C. А при парному програмуванні ви разом і при створенні коду обираєте формат даних, оптимізуєте його та перевіряєте, щоб все працювало згідно з очікуваннями.
Навіть якщо на верхньому рівні ідея хороша, на нижньому можуть з’явитися баги. Тож наявність ще одного девелопера поряд підвищить шанси знайти потенційні проблеми. Фактично це код-рев’ю «у прямому ефірі».
Як підібрати розробника в пару?
Фахівців слід обирати ретельно. Важливо все: спеціалізація, досвід, роль на проєкті, темперамент, особисті відносини тощо.
Головне, щоб ви з колегою мали приблизно однаковий рівень знань. Інакше є ризик виникнення непорозумінь. Наприклад, драйвер знає, що відбувається, і швидко виконує задачу сам, а навігатор не розуміє нічого і стає просто спостерігачем.
Особливо критичне поєднання джуна і сеньйора. Перший у ролі драйвера буде виконувати, що каже другий, а у ролі навігатора лише споглядати за напарником. Та й сеньйору це все видаватиметься нудним.
Але навіть якщо розробники одного рівня, це не вбереже від спірних моментів. Класична ситуація: обидва знають і розуміють код, але кожен пропонує своє рішення. Тоді девелопери чимало часу витрачають на обговорення нижнього рівня.
Погляньмо на цю проблему під іншим кутом. Як правило, розробники обговорюють рішення в коментарях під пул реквестом. Така комунікація буває сильно розтягнутою в часі. Залучені девелопери можуть не відразу відповідати на питання, оскільки банально перебувають у різних часових зонах і пишуть, коли зручно.
Перевага парного програмування — є можливість сходу вирішити спірний момент і розробити рішення, яке позбавить заминок у майбутньому.
Якщо ж пара не може обрати єдиний спосіб реалізації, варто звернутися до більш досвідченого фахівця або до колеги зі знанням конкретної технології. Це може бути хтось із вашої команди або з боку замовника.
Раджу орієнтуватися на принципи Agile. Не можете зробити ідеально? Робіть так, щоб працювало тут і зараз. Працюючий продукт є головним показником прогресу. Це також допоможе уникнути конфліктів у команді.
Розробники завжди мають розуміти, що працюють не заради власного его, а для написання якісного коду, який і покликаний розв’язувати проблеми користувача.
Як виглядає процес парного програмування?
Починайте з розбору тікету, над яким будете працювати. Це дозволяє парі обговорити та спланувати верхній рівень роботи.
Визначте, де і який код буде знаходитись, де і які компоненти потрібно створити, які функції потрібні та де вони мають знаходитись.
Наступний крок — визначити періодичність ротації. Зміна ролей залежить від багатьох факторів. Наскільки складна задача? Наскільки кожен із розробників знається на тій чи іншій частині проєкту? Хто має більше досвіду з обраними технологіями?
У деяких випадках комусь доведеться більше працювати як драйвер або ж як навігатор. Інколи хтось у парі може сказати: «Я це добре знаю, дай мені, швидко зроблю сам». Не сприймайте ролі як догму, не обов’язково чекати своєї зміни.
Можете змінювати ролі відповідно до ситуації. Буває, що пара може взагалі розпаралелитись. Якщо ж навігатору нічого робити, він може за узгодженням сторін почати працювати над іншою частиною задачі.
Що стосується організаційних моментів, то в ідеалі розробники перебувають в одній кімнаті та мають, наприклад, дві сесії по 3 години на день. Вони працюють за одним комп’ютером і передають один одному клавіатуру та мишку або ж ноутбук при зміні ролей.
У реальності ж це подекуди складно реалізувати. У мене був досвід такого програмування з колегами зі Сполучених Штатів. Ми мали лише чотири години спільного часу на день. На додачу доводилося використовувати Zoom для спілкування та Visual Studio Code Live Share для шерінгу коду. Всім важливо було мати однаковий сетап.
Зміна ролей
На мій погляд, парне програмування варто зробити постійним на проєкті. Так у вас усі тікети будуть проходити один і той же флоу. Це організаційно простіше, бо команда не намагатиметься вигадувати нове для кожного тікету.
Звичайно, не без винятків. Парне програмування має недоліки, через які в деяких випадках виявляється малоефективним. Про це окремо поговоримо згодом.
Повертаючись до роботи в парі, зверніть увагу, що напарник може бути як постійними, так і змінюватися час від часу. Це питання комфорту.
Якщо людям подобається працювати разом і вони ефективні, то краще залишити їх сталим «дуетом». Якщо ж людина хоче працювати один тиждень з одним колегою, а наступний — з іншим, то чому б і ні? Нормальна ситуація, яка може піти на користь обом розробникам.
Пам’ятайте, що колега може «випасти» з робочого процесу. У житті трапляються лікарняні, відпустки, несинхронізовані вихідні. В будь-якому випадку робота не має зупинятися.
Якщо відсутність одного з розробників нетривала, інший може повернутися до індивідуального кодингу. Якщо ж пауза затягується, краще знайти тимчасового партнера. Так ви збережете темп і якість роботи.
Окрема частина процесу — оверв’ю для нового партнера або для колеги, який брав паузу у роботі. Розкажіть, над якими тікетами зараз працюєте, на якому ви етапі, чому обрали ті чи інші рішення, які результати.
Знову ж таки: комунікація майже в режимі 24/7 є основою для ефективного парного програмування. Не може бути так, що один пише, а інший, грубо кажучи, скролить стрічку соцмережі. І повернувшись до парного програмування, і при зміні пари обговорюйте якомога більше деталей.
Добре, коли кожен знає особливості різних частин проєкту. Хорошою практикою є передача фіч між парами. Це дає змогу розшарити знання про застосунок чи платформу, над якою працює команда, що особливо корисно у великих проєктах.
Як покращити навички парного програмування?
Розвивайте соціальні зв’язки
Не обмежуйтеся написанням коду. Знаходьте час, щоб попити каву разом, обговорити життєві дрібниці: вихідні, фільми, хобі. Так ви будете спокійніше працювати разом і знаходити компроміси.
Хибний підхід — зациклюватися на своєму «я» і зневажати партнера. Ви вдвох відповідальні за код. Навіть початківець інколи пропонує щось цікаве чи розповідає про незнайомий вам підхід до роботи.
Спілкуйтеся під час парних сесій
Незалежно від ролі проговорюйте всі свої дії. Якщо ви драйвер, розповідайте, що пишете, і чому. Інколи ви навіть самі відразу будете усвідомлювати, де криється проблема.
У ролі навігатора аналізуйте код напарника та запитуйте, чому він робить так, а не інакше. Ви маєте розвивати критичне мислення й шукати сенс у своїх діях і діях партнера.
Не сприймайте коментарі як мікроменеджмент
Парне програмування — це про деталі. Ви обговорюєте дрібниці, але завдяки цьому зменшуєте вірогідність виникнення багів.
Наприклад, драйвер фільтрує масив, а навігатор каже: «Тут пропущено кейс, потрібен чейндж». Або взагалі ви забули крапку з комою, використали не той протокол, не переназвали змінну. Ці ж коментарі ви б отримали в код-рев’ю. Часом, ніхто і не помітить проблему, але рано чи пізно десь вона себе проявить.
Переваги та недоліки парного програмування
За правильної організації парне програмування має суттєві переваги:
- Вища якість коду. Обговорення навіть низькорівневих рішень підвищує шанс одразу обирати кращі рішення. При цьому частковий код рев’ю відбувається прямо під час створення коду, що зменшує кількість примітивних помилок.
- Розподілення знань. При роботі в парах усі в команді знатимуть, чому обрані ці рішення. Тобто люди розуміють ідею коду та чому він написаний саме так. Це забезпечує гнучкість команди й знижує вірогідність дублювання коду.
- Мінімізація координації поза сесіями. При парному програмуванні природно зменшується кількість традиційної комунікації типу коротких мітингів. Хоча, звичайно, вони не зникнуть цілком, оскільки є потреба в обміні знаннями поза парами.
- Вищий рівень дисципліни. Коли розробник пише код наодинці, є ризик, що він буде відволікатися на інші справи. Але якщо фахівці працюють разом, то це допомагає обом утримуватися в межах робочого процесу й конкретної таски.
- Навчання на практиці. Програмування в парі можна розглядати як навчання. І не тільки новачків, а й досвідчених фахівців. Але це не обов’язково будуть глобальні речі. Можна вивчати й дрібниці: нові хоткеї, оператори тощо.
- Міцніше відчуття командної роботи. Щільна співпраця допомагає формуванню команди. Це ж не дейліки на 15 хвилин, де ви перекидаєтесь лише парою слів! У парному програмуванні більше часу на соціальні інтеракції поза межами робочих тем.
Однак пам’ятаємо і про недоліки цього підходу:
- Нижча продуктивність на проєкті. Два розробники пишуть код, який із приблизно такою ж швидкістю міг би писати один. Звичайно, якість вище, але не кожен замовник погодиться на додаткові витрати та зайве очікування.
- Складність вибору пари. Важко знайти розробників з однаковим рівнем знань, які швидко та з комфортом для себе працюють у парі. А деяким людям взагалі не зручно при написанні коду так багато спілкуватись із кимось.
- Можливі проблеми із доступом до напарників. Складно скоординувати людей на один час. Завжди комусь треба до лікаря, хтось хоче обідати на годину раніше, у когось вранці спортзал. І це не кажучи про згадані вище відпустки або різні часові зони.
Коли краще використовувати парне програмування?
Вважається, що парне програмування не дуже підходить для рутинних задач, мовляв, це механічна робота з готовими компонентами та інструментами. У такому разі немає сенсу залучати двох розробників.
Хоча з досвіду скажу: і з простими тасками можна працювати в парі. Один пише задачу, другий — юніт-тест до неї.
Так, це не парне програмування в чистому вигляді, але теж ефективне поєднання зусиль. Зазвичай примітивні тікети краще ділити між розробниками. Паралельна робота забезпечує швидкий темп розробки.
У цілому ж парне програмування не є поширеною практикою. Кілька років тому воно було популярніше, але сьогодні багато задач розробник може реалізувати самостійно, швидко і досить якісно.
З одного боку, дедалі більше з’являється бібліотек і фреймворків для не базових задач. З іншого — ви завжди можете звернутися по допомогу до ChatGPT або Copilot, які замінюють напарника-навігатора.
Як на мене, парне програмування чудово підходить для задач «на подумати». У нестандартних тасках двоє людей можуть швидше знайти креативне рішення.
Підхід добре працює на початкових стадіях проєкту чи фічі. На старті фахівці зможуть продуктивно закласти «кістяк» майбутньої роботи, передбачити та спробувати уникнути потенційних проблем на рівні концепції чи архітектури, продумати інтеграції у проєкт. Тож приводів для парного програмування вистачає.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.
