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

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

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

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

Переваги[ред. | ред. код]

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

Недоліки[ред. | ред. код]

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

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

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

Найпоширеніші стилі парного програмування[ред. | ред. код]

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

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

«Ралі»[ред. | ред. код]

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

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

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

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

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

«Екскурсія»[ред. | ред. код]

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

«Роз'єднана пара» або «Сплячий штурман»[ред. | ред. код]

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

Межі застосування[ред. | ред. код]

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

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

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

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

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

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

Див. також[ред. | ред. код]

Посилання[ред. | ред. код]

Програми та плагіни для підтримки віддаленого парного програмування[ред. | ред. код]

Отримано з https://uk.wikipedia.org/w/index.php?title=Парне_програмування&oldid=39133049