Comments 8
Ну, как описано выше, парным программированием занимался где-то в 1984-м, на большом советском калькуляторе Д3-28 (по слухам она же 15ВСМ-5). А конкретно, я "сеньор" и мой напарник "джун" писали игру "биржа" на бейсике (да, да он там только что появился) .. именно в таком ключе:
Мой кодинг, его наблюдение. Ловля описок, переназвания переменных (ну потерял, что такая похожая уже есть) в 4 глаза сильно ускорила разработку. Его ковыряние в доках на этот "бейсик" (ну .. какие были) пока я стучал код тоже было очень даже в тему. А вот постоянные вопросы "А почему так? Ты же хотел .." .. мало ли что я "хотел"! В процессе написания кода появляются оптимизации как структур данных, так и алгоритмов .. машинка с 32кб "всего" (тогда это было за глаза конечно).. В итоге, меня чуть не выперли из института, т.к. написанный биржевой бот к игре честно обставлял преподавателей, в т.ч. и по экономике, в результате чего они стали постоянно опаздывать на начало лекций и практических занятий.. декан возмутился и стал выяснять "кто такой умный на потоке?" :)
Второй случай, наоборот. 2009год, обучение работе на Paradox 4.5 после недели штудирования двухтомника документации. Тупо сидел и смотрел как сеньор дополняет код новым кейсом и попутно рефакторит старое .. в книжку - на экран - в книжку .. ты эт--та .. тут написано .. -"А, отстань, смотри лучше.." или "Да? Ну как покажь.. а точно, забыл уже".. Не знаю чего больше помог или помешал, но на третий день уже сидел один и кодил..
Мне больше зашел метод "Хирургическая бригада", вот как сию: уже наполовину сделан сервис со своим АПИ, БД .. в то время как коллега общается на совещаниях и .. вырабатывает ТЗ к задаче. Да, оно ещё дышит, меняется но .. я делаю свою версию по первоначальному варианту, заодно всплывают нестыковки, неожиданные дополнения к требованиям, открываются новые подкейсы .. меняется основное ТЗ. Закончу или нет свой вариант? А пофиг. Он начнет или поверх или по новой, а уже я буду показывать и согласовывать.. :)
Парное программирование - неввероятно эффективный инструмент. Но только если вы умеете им пользоваться. Обратная сторона - это очень большой стресс для программиста который находится в роли "ведомого". Умение снизить этот стресс - это самый большой навык для ведущего программиста.
Я очень люблю этот подход на самом деле. В моей практике его использование на начальном этапе позволяет гораздо быстрее ввести в проблемную область нового программиста. Правда здесь ведущий ведомый программист должен быть по квалификации выше, он и показывает что и как нужно делать руками и глазами.
Также бывает перехожу к парному программированию после code-review когда не достаточно просто написать в чём заключается проблема в коде, когда нужно чтобы человек "прочувствовал" к чему приводит то или иное его решение. При парном программировании это проще и быстрее/дешевле.
Также мне нравится парное программирование когда оба программиста сильные. Но только, на моей практике, это обосновано только в ситуации когда нужно передать владение частью домена от одного к другому и только после ознакомления "ведомым" документации.
Парное программирование - секс втроем. В "слаженном коллективе", так сказать, всё круто и все участники получают результат и удовольствие. А если просто ПП ради ПП... То кроме суеты и бестолкового движения ничего на выходе не будет.
Парное программирование хорошо, когда один пишет функционал, второй модульные тесты или диагностику.
Потом наоборот как в мульте "Вовка в Тридевятом царстве".
Парное программирование, несомненно, может быть невероятно эффективно как и любой другой правильно примененный инструмент. Но на мой взгляд, оно работает не для всех и только в очень частных случаях.
Например, программист может 90% времени может проводить в состоянии потока. Максимальный фокус, цельная картина кода/мира в голове. Достижимо ли состояние потока в парном программировании? Сомневаюсь.
ПП очень ситуативно. Отладить какой-то сложный баг в Продакшене? Вполне. Решить тикет средней сложности? Нет, парно может быть в 2-3 раза дороже и бесполезнее, если речь, конечно о ПП, а не о менторстве.
Философия, история, практика и интуиция говорит, что эффективность команды интенсивно повышается только при включении в нее специфично развитых членов. Это и в марвеловских фильмах очень хорошо показано.
Добавление в команду точно такого-же члена, как в команде были, не увеличивает производительность в два раза (экстенсивное развитие). Даже если у каждого по компьютеру и они работают ПАРАЛЛЕЛЬНО. Тем более, если они работают на одном компе и второй по-сути, простаивает.
Интенсивное развитие достижимо только в том случае, если в команду добавляются специфичные по скиллам участники (при этом работают параллельно и совместно).
Суть интенсификации любого производства - в специализации участников. В промпроизводстве это известно уже триста лет. И только в ИТ предлагается добавлять в команду однородных участников.
Парная работа (как частный случай командной работы) может быть эффективен, когда оба участника очень специфичны в скиллах и направлениях.
Например, я вижу смысл, когда очень сильный постановщик (специалист по бизнесу) сидит бок о бок (буквально на одном столе, но каждый со своим ноутом) с бекэндером, и они работают практически над одним и тем-же, постоянно и плотно обмениваясь информацией. После завершения задачи пара разбегается и бэкендер подсаживается (или наоборот) к другому постановщику и начинают работать над другой задачей.
Игра в планирование с карточками - по сути попытка приблизиться к описанному сейчас идеалу, но у создателей Экстр. Пр. не хватило смелости и мужества довести задумку до конца.
Единственный плюс парного программирования - что оба человека стесняются друг перед другом бакланить и начинают работать.
Начальник принёс документ с требованиями к новому приложению мастеру-программисту и спросил: "Сколько времени займёт проектирование этой системы, если я назначу на проект пять программистов?"
"Это займёт год", — не задумываясь, ответил мастер.
"Но система нужна вчера! Сколько это займёт, если я назначу десять программистов?"
Мастер-программист нахмурился: "В этом случае проектирование займёт два года."
"А если я назначу 100 программистов?"
Мастер-программист пожал плечами: "Тогда проект никогда не будет закончен".
Когда парное программирование не работает