Парне програмування, коли водій та спостерігач мають різний рівень кваліфікації та досвід

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

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

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

Не могли б ви запропонувати стратегію парного програмування у наведеному вище випадку?

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

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

Саме для цього було використано програмування парних випадків для: обміну досвідом між старою бородою та молодим коником.

Це двосторонній обмін: спритні комахи мають багато чого навчити ревматизувати мізки.

Коли я отримав підвищення в своїй команді, я був новачком в J2EE, але я був знавцем цієї галузі. Мій старший (новий керівник команди) був досвідченим J2EE, але не в платформі.

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

Розрив у досвіді між ними є ключовим фактором для створення програми imho.

Я опишу свій досвід і спробую вийняти з нього якусь «стратегію».

Я колись пару програмував з повним непрограмістом. Він був експертом у галузі розробленого нами програмного продукту. Навпаки, у мене не було досвіду в проблемній галузі. І він також був моїм керівником на даний момент (я знаю, це може здатися дивним :)

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

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

Однак часом це було досить заляканим, оскільки навіть перерва на чай стала цілком «відволіканням на роботу» (не з його точки зору; просити перерви тощо було просто незручно).

Отже, це насправді не є програмуванням пари, оскільки він майже не міг переглянути код під час введення. Однак, здавалося, це була розумна стратегія (принаймні на деякий час). Зрештою, це взагалі спрацювало через відносну простоту як методології розробки (я маю на увазі, ніяких складних методик розробки програмного забезпечення, як OOP Patterns, не було залучено), так і теми. Це не спрацює у випадку, якщо нам доведеться розробити компілятор, я думаю. Я вважаю, що це все-таки може спрацювати, якщо спостерігач непрограміст бере участь у процесі розробки невеликих чітко визначених творів. Скажімо, це нормально, щоб він спостерігав за програмуванням функції "обчисли параметр X з Y і Z за заданим алгоритмом", але це може бути не так добре, щоб він спостерігав за загальним процесом проектування системи (мається на увазі розвиток архітектури програмного забезпечення, тобто ієрархія класи,

Я думаю, що це би спрацювало ще краще, якби він мав якісь основні навички програміста, тому що мені не доведеться пояснювати "що таке масив".

Сподіваюся, це допомагає :)

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

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

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

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