Згаяний час чи корисний інструмент? Три історії розробників про переваги та недоліки парного програмування

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

Ми поспілкувалися з трьома розробниками про їхній досвід у парному програмуванні та попросили поділитися власними історіями та порадами.

Сергій Журавель, FE Lead Developer, Temy

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

Екстремальне програмування — методологія розробки програмного забезпечення, одна зі гнучких методологій розробки. Має на меті поліпшення якості програмного забезпечення та чутливість до змін у вимогах замовників. Екстремальне програмування радить часті «випуски» програми у коротких циклах розробки, щоб поліпшити продуктивність праці та виконання змін вимог замовника.

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

Парне програмування часто використовують в екстремальному програмуванні та гнучкій розробці (Agile-методології). Зараз у нас формується команда, що працює за цікавою методологією, щось між Scrum і Kanban. Однак команда почала будуватися з автономних спеціалістів, хоча в Agile-програмуванні, особливо в Scrum, намагаються формувати T-shaped фахівців. Ми разом зі СТО цього проєкту помітили, що в певний момент команда розбилася на підкоманди, які складаються з бекенд-розробників і фронтенд-розробників. Іноді вони між собою комунікують і навіть можуть домовитися. Ми думали, як їх об’єднати, водночас не змушуючи до того, щоб виконувати роботу один одного.

Тому нещодавно почали робити end-to-end тести й помітили, що вони можуть стати точкою групування команди. Вирішили, що писати їх будуть всі: і фрондент, і бекенд — попри те, що end-to-end тести пишуть на JavaScript, який значно ближчий нашим фронтенд-розробникам, адже бекенд у нас пишуть на Go. Тож я запропонував методику парного програмування. Ми почали збиратися разом, — фронт і бек, — брати декілька тестів і разом над ними працювати.

Я розумію та знаю, чого бояться програмісти в парному програмуванні. По-перше, є ризик витратити зайвий час розробників, адже дві людини одночасно працюють над одним завданням. Однак здебільшого все навпаки: працюючи над одним завданням, два розробники можуть виконати його набагато швидше. Зі свого досвіду знаю, що під час кодингу часто виникає ступор. Але достатньо розповісти про свої негаразди колезі, і той швидко зрозуміє, що не так. Парне програмування частково розв’язує цю проблему.

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

Парне програмування — чудовий спосіб розв’язання конфліктів між двома розробниками. На жаль, робочі суперечки — непоодинока річ. Трапляється, що два розробники одного рівня вважають, що саме їхня думка правильна, адже мають різні світогляди та підходи до роботи. Я маю кілька варіантів розв’язання таких питань:

  1. Очевидний. Якщо склалася погана ситуація, варто під’єднати ліда, менеджера або СТО. Не можна жалітися на іншого програміста, однак варто розповісти менеджеру про ситуацію на проєкті, пояснити обидві думки й попросити їх прокоментувати. Фінальне рішення залишається за старшим колегою.
  2. Парне програмування. У такому разі обидва розробники мають показати, як саме працюватиме код, адже напарник по проєкту міг просто не розуміти цього. Коли разом виконуєш завдання, можна обрати кращий варіант.

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

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

  1. Visual Studio Code. Популярний редактор коду, що має плагін Live Share, який використовують для спільної роботи.
  2. Cloud9 IDE я використовував раніше, але її викупила компанія Amazon, і тепер ця IDE є частиною AWS сервісів. Це гарний варіант для тих, хто працює з AWS.
  3. Є багато різних IDE, що мають режим спільної роботи, але можна також працювати разом під час відеодзвінка. Недолік цього підходу полягає в тому, що лише одна людина працює з кодом.


Ларіса Анцифрова, Front-end Engineer, SocialTech

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

Спочатку ми сфокусувались на роутингу. Зібралися разом: один розробник писав код, а інший підказував, скеровував, що і як краще зробити. Так ми заклали кістяк проєкту та визначили подальші кроки. Далі взялися за завдання, пов’язане зі створенням компонентів, та помінялися ролями. Разом прописали компоненти за синтаксисом оновленої версії фреймворку та вирішили, у якому стилі будувати код надалі. Наступні завдання вже реалізовували самостійно й паралельно.

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

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

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

На мою думку, парне програмування найбільше підходить у таких випадках:

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

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


Владислав Фурдак, CEO в Nearshore Devs

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

Справжнє парне програмування я практикував 2019 року, коли працював у невеликій продуктовій компанії на позиції Senior-розробника. Через те, що процес був складний та місцями занадто інженерний, нові люди не могли з ним розібратися одразу ж. Тому там практикували парне програмування, під час якого більш досвідчений розробник, який сам і написав половину коду, пояснював мені як новачку проєкт.

Ми влаштовували зідзвони, використовуючи спеціальну програму для спільного програмування Drovio. Чому не Zoom чи Google Meet? Вони надто викривлюють зображення під час дзвінка, геть не видно рядків коду. Тож ми знайшли програму, яка дає змогу виділяти необхідні рядки та брати під свій контроль курсор. Зображення також було набагато кращим.

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

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

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

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

Мабуть, найважливіше під час парного програмування — робити перерви. Коли ти кілька годин безупинно працюєш, сильно втомлюєшся. Краще планувати сесії хвилин на 40 з перервами. Зараз я не маю завдань, де парне програмування буде доцільним. Але якби знову входив до складного проєкту з нуля, це було б доброю ідеєю. Якщо нічого надто складного немає, зазвичай парне програмування не потрібне. Крім того, це може бути занадто витратно для бізнесу.

Все про українське ІТ в Телеграмі — підписуйтеся на канал редакції DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn



9 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Гарантированно очень быстрое выгорание от регулярного ПП

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

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

Раніше часто дивився канал Fun Fun Function. Пригадалося що там були сессії парного програмування, ось знайшов одну з них, може комусь буде цікаво подивитися як відбувається парне програмування (але англійською) youtu.be/zFO1cRr5-qY

За багато років використання (з 2011). Якщо 100% часу бути на парному програмуванні за парною станцією — це згаяний час. Трівіальний фікс багів, по типу змінити текст з такого на такий з додаванням коми — згаяний час. Два джуніори — майже згаяний час. Нема ротацій у парах по команді — згаяний час. Коли діє — введення новачка в команду (один має знати проект), стажування та тренування на level-up, складні завдання з незрозумілими вимогами, старт проекту.

Нісенітниця! Неможливо сконцентруватись, коли хтось дивиться на тебе та/або дихає біля/на тебе.

Вам неможливо. Іншим можливо. Вопрос бажання/вміння/тренувань.

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

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