Парне програмування: що це і наскільки ефективно для командної роботи
Серед розробників ця тема доволі дискусійна. Одні впевнені, що практика цікава та корисна для командної роботи. Інші ж вважають, що в ній немає сенсу. Про переваги, недоліки та особливості парного програмування розповідає Ярослав Антіпов, JS Group Lead в команді NIX.
Що таке парне програмування
Це підхід, за якого девелопери кооперуються в пари і разом пишуть код. Зазвичай практика використовується в Agile- та Scrum-командах. Адже парне програмування орієнтоване на структурування роботи. Хоча і в традиційній Waterfall-моделі така організація робочого процесу може спрацювати.
У парному програмуванні є дві ролі: драйвер і навігатор
Драйвер пише код, навігатор підказує, що й як робити, та в режимі реального часу відстежує помилки. Під час сесії розробники постійно міняються ролями, наприклад, щопівгодини. Це класичний підхід. У мене ж був досвід, коли до кодингу долучалися троє розробників. Один пише на 15-20 хвилин, інші асистують, і потім ротація. На тому ж проєкті була схожа команда з п’ятьох фахівців, які теж одночасно працювали над кодом.
Тут ключова ідея — в спільному обговоренні рішення на нижньому рівні. За традиційної схеми роботи команда визначає лише високорівневі завдання. Наприклад, дані йдуть з точки A в точку B через точку C. А при парному програмуванні ви разом і при створенні коду обираєте формат даних, оптимізуєте його та перевіряєте, щоб все працювало згідно з очікуваннями. Навіть якщо на верхньому рівні ідея хороша, на нижньому — можуть з’явитися баги. Тож наявність ще одного девелопера поряд підвищить шанси знайти потенційні проблеми. Фактично це код-рев’ю «в прямому ефірі».
Як підібрати розробника в пару
Фахівців слід обирати ретельно. Важливо все: спеціалізація, досвід, роль на проєкті, темперамент, особисті стосунки тощо. Головне, щоб ви з колегою мали приблизно однаковий рівень знань. Інакше є ризик непорозумінь. Наприклад, драйвер знає, що відбувається і швидко виконує задачу сам, а навігатор не розуміє нічого і стає просто спостерігачем. Особливо критичне поєднання джуна і сеньйора. Перший у ролі драйвера буде виконувати, що каже другий, а в ролі навігатора лише споглядати за напарником. Та й сеньйору це все видаватиметься нудним.
Але навіть якщо розробники одного рівня, це не вбереже від спірних моментів. Класична ситуація: обидва знають і розуміють код, але кожен пропонує своє рішення. Тоді девелопери чимало часу витрачають на обговорення нижнього рівня. Погньмо на цю проблем під іншим кутом. Як правило, розробники обговорюють рішення в коментарях під пул реквестом. Така комунікація буває сильно розтягнутою в часі. Залучені девелопери можуть не відразу відповідати на питання, бо банально знаходяться в різних часових зонах і пишуть, коли зручно. Перевага парного програмування — є можливість сходу вирішити спірний момент і розробити рішення, яке позбавить заминок у майбутньому.
Якщо ж пара не може обрати єдиний спосіб реалізації, варто звернутися до більш досвідченого фахівця або до колеги зі знанням конкретної технології. Це може бути хтось із вашої команди або з боку замовника.
Раджу орієнтуватися на принципи Agile. Не можете зробити ідеально? Робіть так, щоб працювало тут і зараз. Працюючий продукт є головним показником прогресу. Це також допоможе уникнути конфліктів у команді. Розробники завжди мають розуміти, що працюють не заради власного его, а для написання якісного коду, який і покликаний розв’язувати проблеми користувача.
Як виглядає процес парного програмування — читайте в повній версії статті.
