Які можливі недоліки парного програмування? [зачинено]

Парне програмування зараз досить відоме.

Він має ряд переваг, таких як:

1. Програми з меншою кількістю помилок.
2. Вартість технічного обслуговування після виробництва значно менша.
3. Сформована практика оскаржується, що призводить до появи нових ідей.
4. Програмісти навчаються один у одного.
5. Програмісти розвивають м'які навички.

Але які недоліки парного програмування?

Хоча парне програмування набуло значної репутації, воно також має декілька підводних каменів.

Деякі з них такі:

1. У парному програмуванні ви не можете сидіти і самостійно оцінювати власний код.
2. Одна з пар може перестати активно займатися.
3. Водієві потрібно "програмувати вголос". Мовчазне програмування зменшує перевагу.
4. Для отримання одних і тих же функцій витрачається більше людино-годин. Необхідно підтримувати баланс між якістю коду та підвищеною вартістю кодування.
5. Феномен "спостерігати за майстром" може виникнути, коли досвідчений і початківець програміст з’єднається. Член-початківець може стати спостерігачем, коли досвідчений член виконує більшість кодувань.
6. Коли два досвідчені користувачі з'єднаються між собою, може виникнути явище "его" розробника, кожен член якого намагається підштовхнути власні ідеї.

Я кілька разів намагався програмувати парне програмування, в тому числі в організації, яка (коротко) розглядала його впровадження як обов'язковий процес для всіх інженерів (ви можете здогадатися, наскільки добре ця ідея виправдалася). Особисто я ненавидів це.

Причини, які я перелічу нижче, - це лише мої суб'єктивні переживання, і я не можу «виміряти» їх вплив конкретно. Але тут вони однакові:

1 - Наявність "навігатора" та "драйвера" допомагає лише в тому випадку, якщо перший голосовий, а другий слухатиме.

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

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

2 - Спарювання заважає творчості.

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

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

3 - Найменший дизайн спільного знаменника.

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

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

4 - Відсутність самостійності та жорстокої прозорості.

Насильницька прозорість - це фраза, яку я вирвав із помітно відомої (і досить суперечливої) полеміки проти методології Scrum. Він описує те, як деякі організації інфантилізують розробників та ставляться до них з підозрою, яка зазвичай зарезервована для непрофесійних працівників.

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

5 - Деякі розробники просто не грають добре в парах.

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

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

Залежить від вашої ситуації чи перспективи.

Парне програмування добре для організації. Але чи добре це для людини?

Зрештою, це метод економії витрат (раннього зворотного зв'язку) та продуктивності; Йдеться не про вас, а про проект, продукт, компанію ($$).

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

Ваш (обертовий) партнер буде найкращою камерою спостереження: посилюється інтенсивність роботи.

Або, поширюючи знання, особа стає менш ризикованою для компанії (наприклад, не може залишити компанію необхідними знаннями) і має менше "фішок для торгів".

Я впевнений, що ви знайдете більше балів, читаючи позитивні статті більш критично з ВАШОЇ реальної ситуації / позиції в компанії, а не з точки зору вашого менеджера.

Майже всі методики написані з погляду менеджера.

1. Раптом тепер вам доведеться сказати комусь, коли ви хочете піти в туалет або схопити каву. Принаймні, не потрібно просити дозволу.

2. Ви повинні впоратися з гігієнічними нормами іншої людини.

Окрім інших відповідей:

1. Багато компаній, де я працював над тим, щоб випустити своїх програмістів на ноутбуках (базуючись на сайті клієнтів - легше зберігати обладнання, якщо їх брати додому після роботи, мати можливість виконувати дивну роботу з дому за допомогою VPN за дрібницю тощо) Багато років тому я вже мав проблеми побачити на екрані ноутбука іншої людини ("водія") ноутбук з точки зору плечевого серфінгу - вік цього не покращить (а деякі екрани в будь-якому випадку важко читати поза ідеальним кутом огляду).

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

2. Я також виявив, що відмінності в уподобаннях особистої гігієни (включаючи куріння, вживання їжі та пиття), а також конфлікти особистості неминуче впливають на продуктивність. Досить просто сказати двом програмістам, щоб "висмоктати його і помиритися", часто це призведе до того, що люди швидше зачиняють рот і мовчки саботують один одного за допомогою пасивно-агресивних дій, щоб випромінювати почуття одне одного.
3. Шум. Я, наприклад, як тихе робоче середовище. Я не уявляю постійної балаканини від деяких груп парних програмістів (як вам потрібно поговорити для спілкування). Навіть вокальна музика в моїх навушниках, як правило, заважає моїй зосередженості (чудові інструменти для офісного прослуховування ...). Я думаю, що це можна пом'якшити, віддаляючись від всюдисущого офісу відкритого плану до виділених офісів для двох осіб, але це знову призведе до подорожчання.

Анекдоти для вашого розваги:

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

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

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

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

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

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