tag:blogger.com,1999:blog-8596733192274108952.post1060601522953466427..comments2024-03-12T06:00:18.305+02:00Comments on Programming stuff: О парном программированииSergey Teplyakovhttp://www.blogger.com/profile/14300835272589262297noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-8596733192274108952.post-61807106744302041522016-10-23T16:45:56.570+03:002016-10-23T16:45:56.570+03:00Если я правильно понимаю автор этой статьи заявляе...Если я правильно понимаю автор этой статьи заявляет, что если целью парного программирование является не обучение молодого работника, то в данном случаи это не эффективно Anonymoushttps://www.blogger.com/profile/04371652727398137349noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-84389515990158571732016-10-18T23:34:18.091+03:002016-10-18T23:34:18.091+03:00По моему опыту для отладки никакого парного програ...По моему опыту для отладки никакого парного программирования не нужно. <br /><br />А вот построение архитектуры - самое то. Начинали новый проект и в течении двух недель только и делали что рисовали возле доски и писали интерфейсы. Отличный опыт, который сэкономил кучу времени.Anonymoushttps://www.blogger.com/profile/18428765460246712796noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-67250545392473177772016-10-18T16:34:15.865+03:002016-10-18T16:34:15.865+03:00@Oleksiy Davidich
Я просто сказал про ситуацию, ко...@Oleksiy Davidich<br />Я просто сказал про ситуацию, когда от парного программирования есть ощутимый и легко отслеживаемый положительный эффект. То, что это противоречит определению Бека -- ну это, наверное, проблемы Бека. Или мои :)<br />eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-79244621117458439732016-10-18T06:17:10.389+03:002016-10-18T06:17:10.389+03:00Тоже имею примерно такой же опыт, поэтому считаю,ч...Тоже имею примерно такой же опыт, поэтому считаю,что для продакшна плохо подходит, особенно если еще и опыт разный у программистов. На мой взгляд просто потеря времени.<br />А вот для отладки очень хорошо подходит. Здесь как раз опыт положительный.Anonymoushttps://www.blogger.com/profile/07219585538414539901noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-49825817992722187362016-10-17T21:43:30.379+03:002016-10-17T21:43:30.379+03:00Отладка - однозначно. Разбор легаси кода тоже рабо...Отладка - однозначно. Разбор легаси кода тоже работает.<br />Ну и имплементация-отладка какого-нибудь хитрого куска (либо алгоритмически либо структурно) + последующие размышления как это сделать человеко-читаемым.Anonymoushttps://www.blogger.com/profile/03999939535124861861noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-51544970839448627592016-10-17T19:54:19.895+03:002016-10-17T19:54:19.895+03:00> Единственное, что вызывает сомнение в вышеска...> Единственное, что вызывает сомнение в вышесказанном, это фраза:<br />Да, вполне возможно, что дело в отсутствии положительного опыта... и мое мнение изменится в случае наличие оного:)<br /><br />> Бертран Мейер говорил, что в своё время были эксперименты, которые доказали равнозначность "парного программирования" и "одиночного + код ревью" в отношении эфективности.<br /><br />Да, слышал от него такое же.Sergey Teplyakovhttps://www.blogger.com/profile/14300835272589262297noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-68530542981627912372016-10-17T19:49:06.764+03:002016-10-17T19:49:06.764+03:00Отличное дополнение. Спасибо.Отличное дополнение. Спасибо.Sergey Teplyakovhttps://www.blogger.com/profile/14300835272589262297noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-18528742637346272082016-10-17T19:46:54.310+03:002016-10-17T19:46:54.310+03:00Евгений, я полностью согласен, что работа в паре р...Евгений, я полностью согласен, что работа в паре ради менторства - это хорошее дело, но, как правильно заметил Алексей, эта тактика не покрывает те цели, которые ставил Кент Бек, описывая эту технику.<br /><br />Да, с точки зрения обучения - это будет полезно, но на качество результирующего продукта (а именно в этом заключалась цель) это не повлияет.<br /><br />Ну и тут модель работы должна быть совсем не такая (что не хорошо и не плохо)...<br /><br />И да, у опытного товарища должно быть большое желание именно делиться, а не просто делать... <br /><br />З.Ы. Я менторил довольно много, но это скорее обратный процесс: менее опытный человек пишет, а более опытный - смотрит и "наставляет". Работает, но у меня всегда это было в форме "shoulder code review", а не в форме парной работы.Sergey Teplyakovhttps://www.blogger.com/profile/14300835272589262297noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-2510436641141423392016-10-17T11:43:10.665+03:002016-10-17T11:43:10.665+03:00Во многом согласен с плюсами и минусами.
На работе...Во многом согласен с плюсами и минусами.<br />На работе часто выносим на командное обсуждение какие-то новые решения, а так же с удовольствием ковыряем вместе мистические проблемы на продакшене.<br />Совместный кодинг используется редко. <br />Но вот совсем недавно всё таки прибегнули именно к кодингу в рамках решения задачи для нового проекта. Новый продукт должен стать придатком к уже существующей экосистеме, о которой у команды очень отдалённое понимание. Над одной из задач один программист пыхтел почти неделю и мало куда продвинулся. А после 4-5 часов совместных усилий с человеком, который в курсе нюансов "экосистемы", задача была закомичена и он с лучшим пониманием происходящего ринулся эфективно решать остальные задачи.<br /><br />Единственное, что вызывает сомнение в вышесказанном, это фраза:<br />> Писать же код продакшн качества мне показалось совершенно излишним. С точки зрения продуктивности – это не эффективно, а вопросы с качеством и шарингом знаний легко решаются с помощью рецензирования кода.<br /><br />Чисто гипотетически, рискну предположить, что эфективность сложно измерить на короткой дистанции. Это как с юнит тестами - сначаала вроде дольше, а в итоге быстрее. В парном программировании нужно учесть время на код-ревью, переделку кода, которую прийдётся сделать из-за того что одному программисту сразу не пришло в голову правильное решения, и т.д.<br />Бертран Мейер говорил, что в своё время были эксперименты, которые доказали равнозначность "парного программирования" и "одиночного + код ревью" в отношении эфективности.Oleksiy Davidichhttps://www.blogger.com/profile/06798005643408616225noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-68576675232346608432016-10-17T11:19:42.115+03:002016-10-17T11:19:42.115+03:00Тут не совсем понятно, правильно ли понимается пар...Тут не совсем понятно, правильно ли понимается парное программирование. В процессе должно быть два человека - driver & navigator. Driver только набирает код, решает текущую задачу, navigator следит за направлением и думает об архитектуре и куда дальше пойдет код. Он не следит за стилем. И это не постоянные роли, пара постоянно меняет роли. В день человек должен быть не более, чем 70% в одной роли. Оптимально 50/50.<br /><br />>> Психологическая и рабочая несовместимость<br />Не все люди могут быть в паре. Надо не боятся спрашивать вопросы. Надо постоянно говорить и объяснять, зачем это происходит. Надо говорить иногда теперь моя очередь программировать.<br />Есть неадекваты. В Украине их было очень много, за рубежом значительно меньше. Ответ один не нанимать и увольнять неадекватов.<br /><br />>> Несоответствие в опыте<br />Тяжело, но все равно можно. Первый шаг для джуниора - пинг-понг программирование. Маленький тест, а второй человек его чинит. Потом второй пишет тест, а первый чинит. Идет по принципу " делай как я". Потом спрашивать про рефакторинг. Тормозить во время слишком преждевременного рефакторинга и объяснять почему. Второй шаг - давать джуниору писать код. Как можно больше. Заставлять его спрашивать вопросы, учить его искать код в текушем проекте, в параллельных проектах, в старых проектах. Показывать, где можно спросить.<br /><br />>> Парная работа не подходит для любых задач<br />Идеальная работа, чтоб показывать, как что устроено в проекте. По поводу стиля - можно написать вместе какую-нибудь программку, которая исправляет код. Или падает во время тестов.<br />Очень хорошо протись с человеком, который не был на текущей задаче и объяснить, как код работает и обсудить с ним граничные условия.<br /><br />>> Парная работа утомляет<br />Перерывы каждые полтора часа. Постоянная смена ролей. Через месяц становится проще<br /><br />>> Парная работа требует погружения в контекст<br />Убивает поток и это хорошо. Потому что каждый день надо возвращаться назад и объяснять почему что-то было сделано и зачем. Как в анекдоте про Эйнштейна - объяснять так много раз, что и понять самому. У нас был очень контекстноемкий баг в начале прошлого года. Третий человек, которому я это объяснял, увидел ошибку в воспроизведении этого бага локально. Благодаря этому , мы поняли, что все время работали над неправильным местом. Через два месяца детали этого бага уже знало двадцать человек.Олександр С.https://www.blogger.com/profile/13856177394805109077noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-82032176743286437162016-10-17T10:52:16.449+03:002016-10-17T10:52:16.449+03:00Если я не ошибаюсь, то термин "парное програм...Если я не ошибаюсь, то термин "парное программирование" берёт свои истоки из XP. Так вот автор этой методологии у обязательные условия ставит равенство опыта. То что можно усадить "разноопытных" людей вместе и от этого будет толк - возможно, но это уже будет скорее менторство, введение в проект и т.п., но не парное программирование в понимании автора.Oleksiy Davidichhttps://www.blogger.com/profile/06798005643408616225noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-82321256951159947152016-10-17T09:40:48.790+03:002016-10-17T09:40:48.790+03:00Мне парное программирование иногда импонирует. Нап...Мне парное программирование иногда импонирует. Например, я могу не знать (точнее, мне лень узнавать) детали кривой реализации в проекте, но вот другому человеку это может нравиться ввиду того, что он знает как оно там работает. Почему бы и не совместить? Или банально иногда бывают дни, когда целый день чувствуешь себя уставшим, и эта вся затея здорово помогает. Но именно иногда. Одним ещё минусом могу назвать проблемы, создаваемые гибким графиком, когда кто-то приходит или слишком рано, или слишком поздно. Или когда "парный" идёт обедать в компании других людей, графики с которыми вряд ли совпадают.<br /><br />Это как сковывание цепью. Вообще считаю, что парное программирование есть ни что иное как ограничение личной свободы. Мне, например, не получалось в то время как-то переключиться на наушники просто для того, чтобы расслабиться (хотя у меня был ещё и отдельный рабочий ноут), или, например, переключиться на другие менее важные задачи, когда эта работа мне просто не идёт.<br /><br />И да, наверное, главным недостатком можно назвать п.1: психологическую несовместимость. Был у нас один разработчик, который не стеснялся просто в офисе (опен-спейс) слово через слово применять ругань и иногда заводился так, что создавал впечатление не совсем уравновешенного. Мне он всегда был неприятен, хотя технически он был вовсе неплох и мы состоим где-то на одном уровне компетенции. Итак, когда тимлид сообщил что эту неделю мы пишем код вместе, у меня мысленно упала челюсть, но, думаю: посмотрим, обменяемся опытом, не умру же и всё такое. В итоге на любые минимальные замечание по поводу его кода он отвечал довольно агрессивно, хотя иногда и принимал во внимание мелкие детали. Ну и мне, как, пожалуй, перфекционисту, такой код резал глаза, сами решения не всегда были оптимальными (хотя, честно говоря, я довольно плохо разбирался в том проекте), но напарник видел в этом красоту. А, и да: я выступал исключительно в роли весьма застенчивого комментатора, что порядком стало скучным вусмерть. И я просто ради того, чтобы не портить отношения с человеком, всё оставшееся время провёл за своим ноутом, пока у коллеги дым из-под пальцев шёл. Т.е., формально мы работали вместе, но никакого парного программирования, обмена опытом и т.д. попросту не было.<br /><br />Спустя некоторое время мне повезло перевестись на другой проект, где я уже мог заниматься вполне привычной для меня разработкой без каких-либо этих "хипстерских методологий". Некоторое время у меня даже тоска возникала по поводу того, что я пишу сам. Но, имея хорошую команду, можно просто попросить тиммейта уделить немного своего свободного времени, когда сам не уверен как решить ту или иную задачу. И это касается как проектирования, так и уже иногда очень мелких деталей реализации. И кстати да, по поводу отладки: так отлаживать действительно куда удобней, и я просил коллег помочь мне в этом, или присоединялся к ним, если у них возникала такая необходимость. Я надеюсь, что коллеги по команде думают так же.yep!https://www.blogger.com/profile/07896874002215268190noreply@blogger.comtag:blogger.com,1999:blog-8596733192274108952.post-44068099371261124972016-10-17T09:26:16.204+03:002016-10-17T09:26:16.204+03:00> Эффективное парное программирование подразуме...> Эффективное парное программирование подразумевает равный опыт.<br /><br />С этим можно поспорить. Для меня одна из реально полезных фишек парного программирования в том, что в пару можно посадить новичка и опытного программиста как раз с целью более быстрого обучения и погружения новичка в проект. Это работает, но для этого нужно, чтобы за клавиатурой сидел новичок, а опытный программист подсказывал и рассказывал.<br /><br />Если же опытный программист все пишет сам лишь изредка давая какие-то комментарии -- вот это плохо.<br /><br />Но чтобы такая схема работала, нужно, чтобы у опытного программиста было желание выступать в качестве наставника. Т.е. приходим к проблеме №1 из твоего списка.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.com