Недавно попробовали на работе использовать парное программирование. Я к этому относился довольно скептически, поэтому все получалось спонтанно и дало неожиданные результаты. Вместо того, что бы каждый решал свою задачу, два человека делают одно и тоже да еще за одним компьютером. Но полученное решение получилось намного лучше, чем каждый предлагал в отдельности (все началось со спора, когда каждый отстаивал свое). И большинство ошибок было выявлено сразу - пока один пишет, у другого есть возможность проверять. Так что дополнительные затраты, связанные с привлечением другого человека, окупаются значительно меньшим количеством ошибок и меньшей вероятностью рефакторинга. Самое главное в этом процессе - не отстаивать только свою точку зрения, так как это заведомо проигрышный вариант. Если приструнить свои амбиции (лично для меня, это довольно не легко), можно получить синергетический результат. Не зря говорят, что одна голова хорошо, а две - лучше. Этот принцип прекрасно работает в программировании.
Заинтересовавшись этим вопросом, почитал главу Совершенного кода, посвященную совместной разработке. Оказывается парное программирование и другие подобные методы (обзор кода), действительно дают большие преимущества, позволяют выявлять огромный процент ошибок, даже больший чем тестирование. В книге указанны конкретные цифры, но это очень специфично для каждого конкретного проекта.
Из этого можно сделать несколько выводов. Во-первых, командная работа, это не только когда несколько человек работают над различными подзадачами общей задачи. Командная работа - это еще коммуникация которая, если она хорошо налажена, позволяет достигать синергии. А методы совместной разработки способствуют этому. Во-вторых, стоит время от времени экспериментировать.
Самореклама: мой второй блог
суббота, 20 декабря 2008 г.
1+1=4
Автор: sash_ko на 15:51
Ярлыки: Программизм
Подписаться на:
Комментарии к сообщению (Atom)
6 комментариев:
Таким образом вы избавились от юнит-тестирования? Если да, чем вы гарантируете работоспособность приложения, если не на словах? Если нет, то почему тесты настолько плохи, что не способны конкурировать с обычным code review, сделанным еще на этапе кодирования? Я нахожу полезным перечитывать письма, которые пишу, что уж говорить про код...
Предполагаю, вопросы покажутся несколько вызывающими, но я не увидел никаких сравнительных цифр, или хотя бы условий, для решения каких именно задач парное программирование подходит. Нет никакой конкретики, к сожалению, просто чье-то там мнение.
Как там у классика - "Не верю!".
Предполагаю, вопросы покажутся несколько вызывающими
это точно :)
Перечитал свой пост еще раз, не так и не нашел, где я писал про отказ от юнит-тестирования или то, что тесты плохи. Хотя возможно я не ясно изложил свои мысли. Все что я хотел сказать - парное программирование позволяет найти значительно лучшее решение некоторых задач, чем если бы это делал один человек. И как дополнительный бонус - довольно много ошибок выявляется уже на этапе кодирования.
Я нахожу полезным перечитывать письма, которые пишу, что уж говорить про код...
Но почему-то в чужом письме или коде ошибки заметнее.
Не думаю, что сравнительные цифры вам чем нибудь помогут, как я написал - все зависит от конкретного проекти и конкретных людей. Тоже самое и с условиями. По крайне мере, мой небольшой опыт парного программирования не позволяет обобщить классы задач, для которых этот метод подходит. Могу только сказать, что врядли стоит на двух программистов выдавать один компьютер :)
Но если конкретные цифры важны - источник я указал...
"Не верю!"
Я не проповедник :)
я еще в универе замечал, что с напарником, которые следит за нитью написания кода, лабы делаются гораздо быстрее чем ротозеями =)
полностью поддерживаю. парное программирование мы практиковали на олимпиадах ACM еще лет 6 назад. там команде из нескольких человек это считалось классикой жанра и никто не придавал этому понятию такого пафоса и не устраивал споров. да, это эффективно.
А я не разу не пробовал программить в паре :( а хочется... Думаю, результат будет хороший, главное - договорится о правилах (2 часа один пишет, другой следит, потом меняются) и клавиатуру друг у друга из рук не вырывать :)
Вообще вдвоем удобно писать. Я сто лет назад работал в конторе, занимавшейся Парусом (бух. программа). Так мне нравилось мелкие заказы ребят-внедренцев решать прямо при них - человек сядет рядом, и хотя он не программист, я вслух проговариваю, что делаю, он меня корректирует, контролирует, мне легче писать, потому что он следит за логикой, мне оставалось просто кодировать :) Достаточно сложные отчеты делали влёт - между перекурами!
Отправить комментарий