Хотел спросить общественность, а что вы думаете о парном программировании? Пробовали ли? Какие результаты? Как отнеслись бы к предолжению коллеги попробовать? Как отнеслись бы если бы этим занялись ваши подчинённые?
Я вот задумался о том что никогда за свою профессиональную карьеру и не пробовал, хотя и хотелось бы. Как-то оно не принято в наших аутсорсах. У всех свои задачи, не дай бог 2 программера окажутся за одной клавиатурой.
Привіт, шукаю пару для live-програмування php.
Парное программирование придумали чтобы программисты следили за друг другом и не сидели вконтакте. Стыдно же перед друг другом.
Если серьезно, то использовали в случаях research, но просто работали парами. Никак не связано с TDD, меняться клавиатурой и прочим
Ну или для того чтобы более продуктивно писать в вк-фб обоих.
использовали в случаях researchА пробовали сравнивать с исследованием поодиночке?
Необходимо общаться — за обедом, в курилке, за кодом. Продуктивность это действительно повышает.
Зависит от напарника.
С некоторыми ребятами продуктивность увеличивалась в разы.
Но в основном толку мало. То кто-то тупит, и это все дело превращаеться в «один пишет, второй втычет», то просто характером и взглядами не сходишся, и работа совсем не идеть.
Очень хотелось бы попробовать поработать в таком режиме.
Я лично впервые использовал это в 1988м году, естественно никаких теорий на эту тему не зная.
Сказать «Работает отлично» — это ничего не сказать. Работает — БОМБА.
Два человека наперебой и наперегонки генерят идеи, клавиатура дымится, код получается чуть ли не идеальным. В сравнении с обычным режимом полусна перед монитором — производительность может быть и в 10 и в 100 раз выше. И код получается сразу «поревьювленный».
Правда это об опыте парного программирования с человеком такого же уровня как и я. А вот программируя на пару с более слабым получается плохо — я диктую он пишет (может я что-то делаю не так?). Но, хотя, даже в этом случае есть много преимуществ — человек учится, ты сам более мотивирован, дело идёт быстро, итп.
может я что-то делаю не так?Нарушаете концепцию — уровень владения технологией должен различаться незначительно.
Можно считать такой вид деятельности — экспресс вхождением в проект.
Я лично впервые использовал это в 1988м году,
Правда это об опыте парного программирования с человеком такого же уровня как и я.Ещё бы уровень решаемой задачи добавить сюда для понимания ситуации.
Много всего было. Запомнилась программка для выбора алгоритма хеширования паролей. :)
вот программируя на пару с более слабым получается плохо — я диктую он пишет (может я что-то делаю не так?).Да, вы делаетет что-то не так :)
Два человека наперебой и наперегонки генерят идеи, клавиатура дымитсяНекоторые люди думают что если они собираютсо раз в день на 15 минут и бросаютсо мячиком, то у них Скрам.
И код получается сразу «поревьювленный».Но не в полной степени. Тут открывается основная проблема того что вы «наперебой и на перегонки что-то делаете»: пропадает «холодный взгляд».
пропадает «холодный взгляд»В глубокой шахте который год
Тут открывается основная проблема того что вы «наперебой и на перегонки что-то делаете»: пропадает «холодный взгляд».Ни один «холодный взгляд» не заменит:
Ни один «холодный взгляд» не заменит:Я этого и не говорил. Мало того тесты, например, это как раз часть «холодного взгляда», но для этого они должны появляться до кода, при том из понимания задачи, а не «наперегонки с соседом».
— юнит тестов
— хорошо определённой архитектуры
— код ревюОт как раз код ревью — это и есть «холодный взгляд».
И, кстати, когда один пишет а второй смотрит, код-ревю происходит автоматически.Код ревью не происходит, особенно когда:
Два человека наперебой и наперегонки генерят идеи, клавиатура дымится,
Отлично работает с TDD: первый пишет тесты, второй сразу же код, потом меняются.
С тестами кстати отличная идея. Их можно писать когда голова не пашет писать код. Кто хочет попробовать стоит начать именно с такого разделения. Не удивлюсь если тестерам не останется работы :)
Кстати, по собственному опыту, писать тесты тяжелее чем код.
Если не ставить за цель покрыть всё стадо 100% кода, а тестить только круплноблочно и только внешние связи — не так и сложно. А вот когда уже багу словил в тесте — тогда начинается написание тестов «кто виноват».
Только это не парное программирование
Отлично работает с TDD: первый пишет тесты, второй сразу же код, потом меняются.Это и не парное программирование, и не TDD.
это каноническое XP прям по Кенту Беку, хорош морозить то
Да ладно! Я ж его читал совсем недавно, года 3 назад. :)
Парное — это когда двое сидят за одним компом (что и мотивацию повышает, и темп, и сразу код-ревю).
: первый пишет тесты, второй сразу же код, потом меняются.брр а почему они меняются? не потому ли что за одним компом не?
В оригинале:
Отлично работает с TDD: первый пишет тесты, второй сразу же код, потом меняются.Следуя вот такой методологии в точности, получаем:
Короче был конец рабочего дняя тупил. Да в таком виде это ересь.
Надо все за одним компьютером. Один пишеттест второй тут же реализацию. Потом меняються когда припарятся. Правда отлично работает
За одним и сидим.
Над критическими учатками проекта очень хорошо работать в паре.
В своё время надо написать нетривиальный расчет деформации трехмерных объектов. Писали код в две головы, 4 руки. Интересный эффект наблюдается- как будто ясней и глубже мыслишь в это время.
Помню потом, просматривал код- и долго не мог понять- как это всё работает.
Вообщем парное программирование классная штуку- но устаёшь быстро.
Много лет работали «в парах» — опыт исключительно положительный. Намного проще и быстрее решать любые проблемы, дизайн системы в результе существенно лучше. Но главное — просто веселее работать! :) Когда стал снова писАть код в одиночестве — сразу как-будто поглупел...
Это очень действенная методика, чувствуешь себя двухъядерным пнем. Выматывает.
Парное программирование как постоянная практика работы двух специалистов одинакового уровня? Можно сказать что практически не видел такого. Разве что при дебаге очень сложной и критичной проблемы.
А вот совместная работа за одним компом в процессе обучения новичка на проекте — это очень распространенная практика. При этом периодически приходится быть как в роли «наблюдателя» — обучаемого, так и в роли обучающего.
Потому что в аутсорсах писать само-документирующися понятный код а тем более документацию или схемы менеджеры обычно не позволяют. В итоге самый быстрый способ разобраться в чужом куске — это пойти к автору и пусть он покажет. Или если автор свалил — то обращаться к «коллективному разуму» — авось кто-то что-то вспомнит. Так что иногда бывает и не только «парное», но и «общекомандное» программирование.
Даже удаленно, даже при постоянных фейлах или разнице в знаниях это выглядит круто.
Очень круто, если нужно человека ввести в проект. И вообще, ускоряет обмен знаниями.
И да, чтоб воркало лучше, нужно чтоб программеры были похожи. Рационал и иррационал вместе не уживутся.
если девочка выглядит как мальчик — то все ок
если девочка выглядит как мальчик — то все окТезис не сказать что оригинальный или шокирующий, но от Вас, коллега — абсолютно неожиданный.
Дык вам работа или размножение надо? :)
И имеют неплохие шансы попасть в микрософт или гугл между прочим.
Я так понимаю мы уже не о програмировании говорим?
А какая разница, мы всё равно друг друга не слушаем.
Ну если уж в оффлайне та же самая проблема в глобальных масштабах, то что говорить за онлайн.
Все привели с собой своих тараканов, но если в оффлайне они хотя бы расползаются, то здесь кэшируются гуглем и иммортализируются в промышленных масштабах.
Мне почему-то кажется что всё далеко не так трагично
Не «похожи», а тождественные, дуальные или миражные партнёры, например. Активатор или деловой тоже сойдёт, но скорее не для ввода в курс, а для разруливания песцов.
К счастью — у нас разработка, а не соционический кружок :). Хватит уже в каждый пост пытаться эту теорию втулить.
Как минимум до проведения серии эксперементов в среде разработчиков.
Пока безграмотность не ликвидирована — не хватит. Я провожу свои эксперименты, а кто лично вам мешает их проводить?
Ну и где результаты, или хотябы условия проведения «ваших» эксперементов?
А то большинство подобных «эксперементов» проводится по принципу — «должно быть сладким. Так что буду жрать, и говорить что сладко, даже если оно нифига не сладкое и кислое».
Результаты вполне соотносятся с теорией, которую вы, судя по саркастическим ответам на мои комментарии, не признаёте. Видимо, у вас в рукаве есть другая более правильная. Расскажите нам.
Ещё раз, условия эксперемента. Не сьезжайте с темы.
«наблюдаю за коллегами» — не катит, т.к. из-за оссобенности психологии человека, нам свойственно замечать только то, что мы хочем.
P.S. Абсолютно не важно, признаю я что-либо или нет. На реальность обсуждаемого это не влияет
Эксперимент (через И, кстати) — метод познания, основанный на чувственно-предметной деятельности исследователя. В чём общественная ценность признания/непризнания лично вами научной теории, если вы её основ не знаете, а другой теории у вас тоже нет? Не проще ли было бы просто «не замечать» мои комментарии без риска для ЧСВ?
Где условия эксперимента? Вам ваша теория мешает прямо на поставленный вопрос отвечать?
Вы о каком-то определённом эксперименте толкуете? Какую теорию или гипотезу вам бы хотелось, чтобы он подтвердил или опроверг? А то этот ваш «прямой вопрос» очень напоминает «не читал, но осуждаю».
Я провожу свои эксперименты
Результаты вполне соотносятся с теорией,Рассказывайте уже, хватит шлангом прикидываться
Есть общеизвестная теория информационного метаболизма, она же соционика. Мои наблюдения ей не противоречат, всё в порядке. Если у вас что-то не сходится, расскажите и обсудим, желательно в отдельном топике. Или может вы хотите, чтоб я разорвал тельняшку и бросился вам начитывать матчасть и шлангами меряться? Гугл в помощь.
Такс, экспериментов небыло, только наблюдения. Т.е. Вы сейчас на уровне жрецов, гадающих по звездам. (У них тоже, и общеизвестная теория есть, и наблюдения)
Так бы сразу и сказали, чего выпендриваться было?
Чем отличается наука от мантики, тоже надо разжёвывать? А угомонить свою археопсихическую субличность и самостоятельно изучить матчасть слабо?
На свете много всякой фигни есть, если все изучать — мало времени на полезные вещи останется :).
В данный момент кроме криков «а чо, почитать слабо», я ничего конструктивного не получил.
P.S. Заикаться про науку, при этом путая эксперимент с наблюдениями — это сильно.
Не кроме криков, а кроме указания на невозможность конструктивного обсуждения темы, в которой один из участников не рубит, компенсируя невежество юродством, ничего и не получите. С какой целью вы встряли в тред, когда могли и не тратить вообще время на эту «фигню»?
Стоп, вы тут кичились «эксперементами» и результатами, которых нет, а теперь обвиняете меня в невежестве?
Неет, уважаемый, у вас не наука, у вас религия. Отсюда фанатизм, тяга к «просвещению», и дикий батхерт в спорах.
Религия состоит из веры и поклонения, это раз. А ваше упорное нежелание выучить слово «эксперимент» весьма показательно, ведь соционика всё-таки более сложна для гугления и понимания, чем правописание какой-то там буквы. И поскольку фанатизмом я не страдаю, мы останемся при своих интересах: я с теорией и практикой, а вы с риторикой. И это природно, поскольку люди различаются как минимум по четырём дихотомическим признакам. :)
В смысле, это когда вдвоём один код пишут? Ничего сложного, но преимущества никакого. Особенно когда код сырой, и ещё не прошёл первого редакторинга.
Основная проблема — сырой код чрезвычайно избыточен. А уж о нейминге лучше не говорить... каждый будет считать второго дебилом.
В старые добрые времена, когда файлы были большие — это работало. Сейчас задачи легко разбиваются на мелкие кусочки, притом настолько элегантно что если кто-то из пары втихаря отдаст на аутсорс — можно не заметить разницы, и только читая каменты о чём-то догадаться.
Есть однако вариант, о котором мало кто знает — работа в 2 смены. Когда за одним компом в разное (!!!) время пишут один и тот же код. И хотя чаще всего зонами воздейстивя не сталкиваются, редактирование чужого кода допустимо и приветствуется по обстоятельствам. Преимущество — нет овертаймов, отсюда ускорение работы. Недостаток — требуется арбитраж раз в пару-тройку месяцев. Для фриланса просто идеальная схема — заказчик и не догадывается что вас двое.
Выгоды парного программирования — горячий резерв. Если кто-то вышел посреди проекта, отряд не заметит потери бойца.
Кстати, одна обязательная мелочь: передача полномочий и зон отвественности в письменном виде. Будь это общий todo-лист или более серьёзное ПО управления проектами, но чтобы факт создания-разрушения задач был всегда отражён. Иначе концов не сыщешь, а это чревато.
В смысле, это когда вдвоём один код пишутНет, это когда один думает об архитектуре, а другой о реализации.
Код получается, лучше чем у «суммы» программеров.
Обучение — на лету.
и тп
Минусы:
— не все к этому способны
— не всегда можно в офисе найти подходящую пару.
— нужно меняться партнерами
xD как-то так
Пожди, двойная избыточность что-ли?
Кстати, в супружеских парах то же самое. 61% распадается. Может оттого что надо меняться партнёрами, а они этого не делают?
Пожди, двойная избыточность что-ли?С точки зрения менеджера — да.
Может оттого что надо меняться партнёрами, а они этого не делают?Возможно, но ревность и собственичество сложно будет побороть.
А значит что в случае равенства такая система провальна. Должно быть НЕравенство. Изначально зарыт топор войны, позволяя единству и борьбе противоположностей раскрутить систему.
Кроме того, это не будет работать на двусторонних отношениях. Нужны ТРЁХсторонние. Третья сторона, [важно] слабее этих двоих технически, но оказывающая решающее значение на ограничение разшатывания системы. Если двое не могут договориться, определяет вектор или приоритет времени.
Стоит ошибиться с конфигурацией — будет лебедь рак и щука.
Есть и другое последствие — широкая специализация обеих будет разрушаться. а третей стороны — расти. Оба станут узкими специалистами, экспертами в своей области. Третья сторона — зависит только от себя (и это опасно). Потому что поощрения и наказания которые ей достанутся — всегда будут незаслуженными, а реальных заслуг никто и не заметит.
И только специалист готовый заварить такую кашу — может запускать парное программирование. С меньшей квалификацией в области отношений — не стоит и начинать, будет двойной велосипед без седла.
Хорошо работает когда оба специалиста достаточно высокого уровня, и когда они могут найти общий язык между собой. Ибо если люди не особо ладят между собой, то беда.
Имел опыт работы в парном программировании со своим архитектом — впечатления очень позитивные.
Можно очень много чего перенять у друг друга + на выходе обычно очень толковые решения и код.
В этой методике есть плюсы и минусы.
К плюсам могу отнести огромную продуктивность, т.к. когда кто-то сидит рядом на доу тяжковато отвлечься. Качество кода тоже на достаточно высоком уровне. Еще это был огромнейший профит для меня, как для джуна (мои коллеги были сильно опытнее).
Минусы — дико устаешь. Работать в паре более 6 часов в день просто невозможно. Но за эти 6 часов мы успевали больше, чем каждый по отдельности. Ну и как было сказано выше — если для менее опытного программиста ПП несомненно плюс, то более опытному будет скучно. Имхо, чтобы такая практика работала, программисты должны быть более-менее равными.
А вообще мы пробовали ввести такую практику на постоянной основе, но из 3х пар у нас сложилась только одна. Остальные просто-напросто перегрызлись.
но из 3х пар у нас сложилась только одна. Остальные просто-напросто перегрызлись.А вы не пробовали чередовать пары, в случайной последовательности например?
пробовали. Один человек так ни с кем и не ужился.
работает очень хорошо если нужно додавить что-то сложное. Постоянно так работать напряжно откровенно говоря.
Но важное замечание — надо что бы кто то в паре имел опыт такого, парное програмирование это не один педалит а другой спит
Как по мне слишком много времени уходит на коммуникации со своим альтер эго, иногда проще некоторые вещи сделать полностью самому. Парное программирование хорошо только, если оба программера занимаются разными вещами.
Я вот с Вами не согласен, когда нужно именно кодировать (педалить), то подобная практика определенно дает результаты. Хотя, случаи бывают разные, думаю Вам парное программирование не подходит из за сложной предметной области, где надо сидеть и думать, разбираться.
Парное программирование дает хорошие результаты когда нужно ускориться, но оно очень выматывает и постоянно так работать нельзя, — сгоришь.
С джунами полезно практиковать кстати, приучать к хорошим практикам, подавать пример.
Если ускорился, программирование даёт хорошие результаты.
Только постоянно такое практиковать не нужно.
«Hовые районы — дома, как коробки,
Хочешь жить — набивай кулаки.
Кто-то жрёт таблетки, а кто-то — колется.
Лично я бухаю, но могу ускориться.»
© Ленинград
Только с условием, что напарник джуна будет тоже джуном.
Нельзя брать двух людей с большим разрывом в опыте — это в итоге превратиться в урок.
Только с условием, что напарник джуна будет тоже джуном.Я это и подразумевал.
Нельзя брать двух людей с большим разрывом в опыте — это в итоге превратиться в урок.Ценное замечание, иначе они им будет тяжело говорить на одном языке.
Нельзя брать двух людей с большим разрывом в опыте — это в итоге превратиться в урок.
А в чем проблемма если это действительно превратится в урок?
Да проблемы нет — просто это уже не будет парным программингом.
Просто при выборе партнеров нужно будет еще и это учитывать — некоторые не любят учить, а некоторые не умеют.
ни в чем, если это всех устраивает.
Программировать парно, это для нубов. А вот
если у тебя не пара чудаков на букву м на ревью. Я знавал людей которые из 4 часового задания могли выдавить 2 дня убитых на ревью.
У ревью много целей, это может быть и нормальным в определенной ситуации.
Anton Katrus
Igor Petruk
idOne Арбузный
Sergii Surskykh
Grez
Maksym Shysha
Iaroslav Voitovych
Nobody
Iaroslav Voitovych
Bogdan Shyiak
Alexey Milokhov
Олексій Пєніє
Alexey Milokhov
Нестор Иванович
Lyova Zi
Matvey Maslov
Александр Колосов
Beaver Green
idOne Арбузный
Pavel Kruchina
Pavel Kruchina
anonymous
Дмитрий Пинский
Олексій Пєніє
Ivan Skripka
Oksana Chuiko
Oksana Chuiko
Нестор Иванович
Mike Gorchak
Ivan Pomidorov
Ivan Pomidorov
Антон Харуйманов
Sergii Surskykh
83 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів