Парное программирование
Хотел спросить общественность, а что вы думаете о парном программировании? Пробовали ли? Какие результаты? Как отнеслись бы к предолжению коллеги попробовать? Как отнеслись бы если бы этим занялись ваши подчинённые?
Я вот задумался о том что никогда за свою профессиональную карьеру и не пробовал, хотя и хотелось бы. Как-то оно не принято в наших аутсорсах. У всех свои задачи, не дай бог 2 программера окажутся за одной клавиатурой.
83 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівПривіт, шукаю пару для live-програмування php.
Парное программирование придумали чтобы программисты следили за друг другом и не сидели вконтакте. Стыдно же перед друг другом.
Если серьезно, то использовали в случаях research, но просто работали парами. Никак не связано с TDD, меняться клавиатурой и прочим
Ну или для того чтобы более продуктивно писать в вк-фб обоих.
А пробовали сравнивать с исследованием поодиночке?Необходимо общаться — за обедом, в курилке, за кодом. Продуктивность это действительно повышает.
Зависит от напарника.
С некоторыми ребятами продуктивность увеличивалась в разы.
Но в основном толку мало. То кто-то тупит, и это все дело превращаеться в «один пишет, второй втычет», то просто характером и взглядами не сходишся, и работа совсем не идеть.
Очень хотелось бы попробовать поработать в таком режиме.
Я лично впервые использовал это в 1988м году, естественно никаких теорий на эту тему не зная.
Сказать «Работает отлично» — это ничего не сказать. Работает — БОМБА.
Два человека наперебой и наперегонки генерят идеи, клавиатура дымится, код получается чуть ли не идеальным. В сравнении с обычным режимом полусна перед монитором — производительность может быть и в 10 и в 100 раз выше. И код получается сразу «поревьювленный».
Правда это об опыте парного программирования с человеком такого же уровня как и я. А вот программируя на пару с более слабым получается плохо — я диктую он пишет (может я что-то делаю не так?). Но, хотя, даже в этом случае есть много преимуществ — человек учится, ты сам более мотивирован, дело идёт быстро, итп.
Можно считать такой вид деятельности — экспресс вхождением в проект.
Много всего было. Запомнилась программка для выбора алгоритма хеширования паролей. :)
Некоторые люди думают что если они собираютсо раз в день на 15 минут и бросаютсо мячиком, то у них Скрам.
Но не в полной степени. Тут открывается основная проблема того что вы «наперебой и на перегонки что-то делаете»: пропадает «холодный взгляд».
Таится чудище-змей.
Стальные нервы, стальная плоть,
Стальная хватка когтей.
Он копит силы, лениво ждет,
Направив в небо радар.
Одна ошибка, случайный взлет -
И неизбежен удар.
— юнит тестов
— хорошо определённой архитектуры
— код ревю
И, кстати, когда один пишет а второй смотрит, код-ревю происходит автоматически.
От как раз код ревью — это и есть «холодный взгляд».
Код ревью не происходит, особенно когда:
Отлично работает с TDD: первый пишет тесты, второй сразу же код, потом меняются.
С тестами кстати отличная идея. Их можно писать когда голова не пашет писать код. Кто хочет попробовать стоит начать именно с такого разделения. Не удивлюсь если тестерам не останется работы :)
Кстати, по собственному опыту, писать тесты тяжелее чем код.
Если не ставить за цель покрыть
всё стадо100% кода, а тестить только круплноблочно и только внешние связи — не так и сложно. А вот когда уже багу словил в тесте — тогда начинается написание тестов «кто виноват».Только это не парное программирование
это каноническое XP прям по Кенту Беку, хорош морозить то
Да ладно! Я ж его читал совсем недавно, года 3 назад. :)
Парное — это когда двое сидят за одним компом (что и мотивацию повышает, и темп, и сразу код-ревю).
В оригинале:
Следуя вот такой методологии в точности, получаем:— раздельное написание кода и юнит-тестов разными людьми (совсем не TDD)
— двух людей, сидящих за разными компами и кодящих разные штуки (совсем не парное программирование)
Короче был конец рабочего дняя тупил. Да в таком виде это ересь.
Надо все за одним компьютером. Один пишеттест второй тут же реализацию. Потом меняються когда припарятся. Правда отлично работает
За одним и сидим.
Над критическими учатками проекта очень хорошо работать в паре.
В своё время надо написать нетривиальный расчет деформации трехмерных объектов. Писали код в две головы, 4 руки. Интересный эффект наблюдается- как будто ясней и глубже мыслишь в это время.
Помню потом, просматривал код- и долго не мог понять- как это всё работает.
Вообщем парное программирование классная штуку- но устаёшь быстро.
Много лет работали «в парах» — опыт исключительно положительный. Намного проще и быстрее решать любые проблемы, дизайн системы в результе существенно лучше. Но главное — просто веселее работать! :) Когда стал снова писАть код в одиночестве — сразу как-будто поглупел...
Это очень действенная методика, чувствуешь себя двухъядерным пнем. Выматывает.
Парное программирование как постоянная практика работы двух специалистов одинакового уровня? Можно сказать что практически не видел такого. Разве что при дебаге очень сложной и критичной проблемы.
А вот совместная работа за одним компом в процессе обучения новичка на проекте — это очень распространенная практика. При этом периодически приходится быть как в роли «наблюдателя» — обучаемого, так и в роли обучающего.
Потому что в аутсорсах писать само-документирующися понятный код а тем более документацию или схемы менеджеры обычно не позволяют. В итоге самый быстрый способ разобраться в чужом куске — это пойти к автору и пусть он покажет. Или если автор свалил — то обращаться к «коллективному разуму» — авось кто-то что-то вспомнит. Так что иногда бывает и не только «парное», но и «общекомандное» программирование.
Даже удаленно, даже при постоянных фейлах или разнице в знаниях это выглядит круто.
Очень круто, если нужно человека ввести в проект. И вообще, ускоряет обмен знаниями.
И да, чтоб воркало лучше, нужно чтоб программеры были похожи. Рационал и иррационал вместе не уживутся.
а мальчик и девочка?
если девочка выглядит как мальчик — то все ок
Дык вам работа или размножение надо? :)
И имеют неплохие шансы попасть в микрософт или гугл между прочим.
Я так понимаю мы уже не о програмировании говорим?
А какая разница, мы всё равно друг друга не слушаем.
И ИМХО это пичально
Ну если уж в оффлайне та же самая проблема в глобальных масштабах, то что говорить за онлайн.
Все привели с собой своих тараканов, но если в оффлайне они хотя бы расползаются, то здесь кэшируются гуглем и иммортализируются в промышленных масштабах.
Мне почему-то кажется что всё далеко не так трагично
Не «похожи», а тождественные, дуальные или миражные партнёры, например. Активатор или деловой тоже сойдёт, но скорее не для ввода в курс, а для разруливания песцов.
К счастью — у нас разработка, а не соционический кружок :). Хватит уже в каждый пост пытаться эту теорию втулить.
Как минимум до проведения серии эксперементов в среде разработчиков.
Пока безграмотность не ликвидирована — не хватит. Я провожу свои эксперименты, а кто лично вам мешает их проводить?
Ну и где результаты, или хотябы условия проведения «ваших» эксперементов?
А то большинство подобных «эксперементов» проводится по принципу — «должно быть сладким. Так что буду жрать, и говорить что сладко, даже если оно нифига не сладкое и кислое».
Результаты вполне соотносятся с теорией, которую вы, судя по саркастическим ответам на мои комментарии, не признаёте. Видимо, у вас в рукаве есть другая более правильная. Расскажите нам.
Ещё раз, условия эксперемента. Не сьезжайте с темы.
«наблюдаю за коллегами» — не катит, т.к. из-за оссобенности психологии человека, нам свойственно замечать только то, что мы хочем.
P.S. Абсолютно не важно, признаю я что-либо или нет. На реальность обсуждаемого это не влияет
Эксперимент (через И, кстати) — метод познания, основанный на чувственно-предметной деятельности исследователя. В чём общественная ценность признания/непризнания лично вами научной теории, если вы её основ не знаете, а другой теории у вас тоже нет? Не проще ли было бы просто «не замечать» мои комментарии без риска для ЧСВ?
Где условия эксперимента? Вам ваша теория мешает прямо на поставленный вопрос отвечать?
Вы о каком-то определённом эксперименте толкуете? Какую теорию или гипотезу вам бы хотелось, чтобы он подтвердил или опроверг? А то этот ваш «прямой вопрос» очень напоминает «не читал, но осуждаю».
Есть общеизвестная теория информационного метаболизма, она же соционика. Мои наблюдения ей не противоречат, всё в порядке. Если у вас что-то не сходится, расскажите и обсудим, желательно в отдельном топике. Или может вы хотите, чтоб я разорвал тельняшку и бросился вам начитывать матчасть и шлангами меряться? Гугл в помощь.
Такс, экспериментов небыло, только наблюдения. Т.е. Вы сейчас на уровне жрецов, гадающих по звездам. (У них тоже, и общеизвестная теория есть, и наблюдения)
Так бы сразу и сказали, чего выпендриваться было?
Чем отличается наука от мантики, тоже надо разжёвывать? А угомонить свою археопсихическую субличность и самостоятельно изучить матчасть слабо?
На свете много всякой фигни есть, если все изучать — мало времени на полезные вещи останется :).
В данный момент кроме криков «а чо, почитать слабо», я ничего конструктивного не получил.
P.S. Заикаться про науку, при этом путая эксперимент с наблюдениями — это сильно.
Не кроме криков, а кроме указания на невозможность конструктивного обсуждения темы, в которой один из участников не рубит, компенсируя невежество юродством, ничего и не получите. С какой целью вы встряли в тред, когда могли и не тратить вообще время на эту «фигню»?
Стоп, вы тут кичились «эксперементами» и результатами, которых нет, а теперь обвиняете меня в невежестве?
Неет, уважаемый, у вас не наука, у вас религия. Отсюда фанатизм, тяга к «просвещению», и дикий батхерт в спорах.
Религия состоит из веры и поклонения, это раз. А ваше упорное нежелание выучить слово «эксперимент» весьма показательно, ведь соционика всё-таки более сложна для гугления и понимания, чем правописание какой-то там буквы. И поскольку фанатизмом я не страдаю, мы останемся при своих интересах: я с теорией и практикой, а вы с риторикой. И это природно, поскольку люди различаются как минимум по четырём дихотомическим признакам. :)
В смысле, это когда вдвоём один код пишут? Ничего сложного, но преимущества никакого. Особенно когда код сырой, и ещё не прошёл первого редакторинга.
Основная проблема — сырой код чрезвычайно избыточен. А уж о нейминге лучше не говорить... каждый будет считать второго дебилом.
В старые добрые времена, когда файлы были большие — это работало. Сейчас задачи легко разбиваются на мелкие кусочки, притом настолько элегантно что если кто-то из пары втихаря отдаст на аутсорс — можно не заметить разницы, и только читая каменты о чём-то догадаться.
Есть однако вариант, о котором мало кто знает — работа в 2 смены. Когда за одним компом в разное (!!!) время пишут один и тот же код. И хотя чаще всего зонами воздейстивя не сталкиваются, редактирование чужого кода допустимо и приветствуется по обстоятельствам. Преимущество — нет овертаймов, отсюда ускорение работы. Недостаток — требуется арбитраж раз в пару-тройку месяцев. Для фриланса просто идеальная схема — заказчик и не догадывается что вас двое.
Выгоды парного программирования — горячий резерв. Если кто-то вышел посреди проекта, отряд не заметит потери бойца.
Кстати, одна обязательная мелочь: передача полномочий и зон отвественности в письменном виде. Будь это общий todo-лист или более серьёзное ПО управления проектами, но чтобы факт создания-разрушения задач был всегда отражён. Иначе концов не сыщешь, а это чревато.
Пишет код только один,
Ролями меняются регулярно.
Ревью кода на месте.
Код получается, лучше чем у «суммы» программеров.
Обучение — на лету.
и тп
Минусы:
— не все к этому способны
— не всегда можно в офисе найти подходящую пару.
— нужно меняться партнерами
xD как-то так
Пожди, двойная избыточность что-ли?
Кстати, в супружеских парах то же самое. 61% распадается. Может оттого что надо меняться партнёрами, а они этого не делают?
С точки зрения качества — хз ибо непонятно как проверять. Возможно, но ревность и собственичество сложно будет побороть.
А значит что в случае равенства такая система провальна. Должно быть НЕравенство. Изначально зарыт топор войны, позволяя единству и борьбе противоположностей раскрутить систему.
Кроме того, это не будет работать на двусторонних отношениях. Нужны ТРЁХсторонние. Третья сторона, [важно] слабее этих двоих технически, но оказывающая решающее значение на ограничение разшатывания системы. Если двое не могут договориться, определяет вектор или приоритет времени.
Стоит ошибиться с конфигурацией — будет лебедь рак и щука.
Есть и другое последствие — широкая специализация обеих будет разрушаться. а третей стороны — расти. Оба станут узкими специалистами, экспертами в своей области. Третья сторона — зависит только от себя (и это опасно). Потому что поощрения и наказания которые ей достанутся — всегда будут незаслуженными, а реальных заслуг никто и не заметит.
И только специалист готовый заварить такую кашу — может запускать парное программирование. С меньшей квалификацией в области отношений — не стоит и начинать, будет двойной велосипед без седла.
Хорошо работает когда оба специалиста достаточно высокого уровня, и когда они могут найти общий язык между собой. Ибо если люди не особо ладят между собой, то беда.
Имел опыт работы в парном программировании со своим архитектом — впечатления очень позитивные.
Можно очень много чего перенять у друг друга + на выходе обычно очень толковые решения и код.
В этой методике есть плюсы и минусы.
К плюсам могу отнести огромную продуктивность, т.к. когда кто-то сидит рядом на доу тяжковато отвлечься. Качество кода тоже на достаточно высоком уровне. Еще это был огромнейший профит для меня, как для джуна (мои коллеги были сильно опытнее).
Минусы — дико устаешь. Работать в паре более 6 часов в день просто невозможно. Но за эти 6 часов мы успевали больше, чем каждый по отдельности. Ну и как было сказано выше — если для менее опытного программиста ПП несомненно плюс, то более опытному будет скучно. Имхо, чтобы такая практика работала, программисты должны быть более-менее равными.
А вообще мы пробовали ввести такую практику на постоянной основе, но из 3х пар у нас сложилась только одна. Остальные просто-напросто перегрызлись.
ИМХО если у кого и возникают какие-то несовместимости с текущим партнёром, то смена партнёра может, и даже должна, дать новый взгляд на вещи.
пробовали. Один человек так ни с кем и не ужился.
работает очень хорошо если нужно додавить что-то сложное. Постоянно так работать напряжно откровенно говоря.
Но важное замечание — надо что бы кто то в паре имел опыт такого, парное програмирование это не один педалит а другой спит
Как по мне слишком много времени уходит на коммуникации со своим альтер эго, иногда проще некоторые вещи сделать полностью самому. Парное программирование хорошо только, если оба программера занимаются разными вещами.
Я вот с Вами не согласен, когда нужно именно кодировать (педалить), то подобная практика определенно дает результаты. Хотя, случаи бывают разные, думаю Вам парное программирование не подходит из за сложной предметной области, где надо сидеть и думать, разбираться.
Парное программирование дает хорошие результаты когда нужно ускориться, но оно очень выматывает и постоянно так работать нельзя, — сгоришь.
С джунами полезно практиковать кстати, приучать к хорошим практикам, подавать пример.
Если ускорился, программирование даёт хорошие результаты.
Только постоянно такое практиковать не нужно.
«Hовые районы — дома, как коробки,
Хочешь жить — набивай кулаки.
Кто-то жрёт таблетки, а кто-то — колется.
Лично я бухаю, но могу ускориться.»
© Ленинград
Только с условием, что напарник джуна будет тоже джуном.
Нельзя брать двух людей с большим разрывом в опыте — это в итоге превратиться в урок.
Ценное замечание, иначе они им будет тяжело говорить на одном языке.
А в чем проблемма если это действительно превратится в урок?
Да проблемы нет — просто это уже не будет парным программингом.
Просто при выборе партнеров нужно будет еще и это учитывать — некоторые не любят учить, а некоторые не умеют.
ни в чем, если это всех устраивает.
Программировать парно, это для нубов. А вот«4-хглазый код ревью» — это штука полезная.
если у тебя не пара чудаков на букву м на ревью. Я знавал людей которые из 4 часового задания могли выдавить 2 дня убитых на ревью.
У ревью много целей, это может быть и нормальным в определенной ситуации.