Парне програмування

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

Два робочих місця програмістів, котрі займаються парним програмуванням

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

Переваги
  • Обмін досвідом: Співпрацюючи у парі, можна дізнатися багато цікавої і корисної інформації від партнера.
  • Знання про систему: Постійна зміна пар сприяє поширенню знань про різні частини системи всередині команди. Це дає можливість розуміти як система розвивається, покращувати дизайн системи, не дублювати логіку.
  • Колективне володіння кодом: Коли всі програмісти задіяні у написанні всіх частин системи, то не може йти мови про персональне володіння класом або складанням.
  • Наставництво: Кожен, навіть починаючий програміст, знає щось, чого не знають інші. Парне програмування — безболісний спосіб розповсюдити ці знання.
  • Більше спілкування: Спілкування всередині команди допомагає вибудовувати довірчі відносини. Парне програмування додає спілкування в повсякденну роботу.
  • Стандарти кодування: Сидячи в парі, постійно передаючи клавіатуру і міняючи пари, програмісти поширюють знання про те, які стандарти кодування прийняті на проекті, що в майбутньому може скоротити час на рефакторинг коду.
  • Поліпшення дисципліни: Програмісти, працюючі в парі, більше часу проводять за вирішенням поставлених завдань і рідше влаштовують довгі перерви і займаються сторонніми справами, аніж програмісти, що працюють поодинці.
  • Якість результату: В результаті парного програмування код одержується набагато якіснішим і містить на близько 60% менше помилок.

Недоліки

Парне програмування може бути набагато цікавішим і результативнішим, ніж програмування поодинці, якщо організоване правильно. І навпаки, може бути жахливим і нудним у порівнянні з роботою поодинці, якщо - неправильно. За спостереженнями, люди програмують в парі правильно дуже рідко. Велика частина спроб парного програмування губиться одним з перерахованих нижче анти-патернів.

  • Спостерігай за Майстром: Присутній, коли в парі є програміст, досвідчений в своїй області. Питання менш досвідченого розробника про код, який генерується Майстром, не отримують відповіді. Майстер не поспішає віддавати клавіатуру напарнику, а коли віддає - втрачає інтерес до процесу.
  • Диктатор: Один з розробників у парі завжди займає жорстку ультимативну позицію з приводу всіх рішень, які стосуються поточних завдань. У такій ситуації не може йти мови про взаємну допомогу або навчання в парі.
  • Сходи за кавою: Один з розробників самостійно пише код і в процесі написання відволікає напарника сторонніми справами. Це порушує базову ідею про взаємну залученість програмістів у процес.
  • Мовчазні партнери: Напарники не спілкуються один з одним, не коментують свої дії і рішення по ходу роботи. При відсутності зворотного зв'язку сенс пари втрачається.
  • Поділ завдань за одним столом: Програмісти в парі паралельно працюють за двома комп'ютерами(настільний і ноутбук) на одному столі.
  • Незручно сидіти: Найчастіша причина втоми при роботі в парі - незручне положення клавіатури і монітора для того, хто зараз генерує код. Коли процес написання коду переходить від одного програміста до іншого, останній не переміщається в центр столу, а нагинається до клавіатури, тим самим створюючи собі труднощі при роботі.
  • Партнер зайнятий своїми справами: Під час роботи один з програмістів займається сторонніми справами.
  • Свої налаштування оточення: Щоразу при переході управління від одного програміста до іншого, останньому потрібно переналаштовувати оточення для себе.
  • Свій стиль: Кожен з партнерів дотримується своїх стандартів кодування, що викликає бурхливі дискусії і жахливо відформатований код.

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

Найпоширеніші стилі парного програмування

«Командир і Буркун» або «докучливий пасажир, який радить водію, як треба їхати»

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

«Ралі»

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

Як водій програміст повинен:

  • Думати вголос
  • Озвучувати очікування
  • Питати очевидне
  • Ділитися інформацією, попереджати

Як штурман програміст повинен:

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

«Екскурсія»

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

«Роз'єднана пара» або «Сплячий штурман»

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

Межі застосування

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

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

Покращення продуктивності розробки

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

  • невеликі перерви кожних 45 хвилин (краще кожних 20)
  • вода (більшість головних болів викликана зневодненням)
  • глюкоза
  • нормальний сон
  • кофеїн

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

Див. також

Посилання

Програми та плагіни для підтримки віддаленого парного програмування
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.