19 июня 2012 · Комментарий

Без заголовка

я немного знаком с тем как проводят эксперименты по социальной психологии, а парное программирование и ХР вообще - это социальная психология однозначно дык вот тут очень много факторов, которые надо учесть и компенсировать соответственно тут надо очень много провести экспериментов, чтобы получить надежные данные вообще особенно, это касается реальных проектов, ибо обычно эксперименты проводят над студентами я немного погуглил обозрел результаты экспериментов, хотя и поверхностно, но в целом: 1 в основном результаты на студентах 2 часто исследуется скорость выполнения какой-то задачи парными и соло программерами 3 конечно есть и индустриальные результаты и на тему кол-ва дефектов, но их относительно мало 4 скорость кодинга варьируется во времени, то бишь поначалу пары могут работать медленее, но потом эффективность возрастает 5 еще есть подразделение на стадии - дизайн, кодинг, багофиксы/сопровождение - по сопровождению достаточно мало данных 6 данные противоречивые - где-то парное программирование лучше, где-то нет Вобщем самые интересные - это как раз индустриальные проекты, в частности сопровождение кода (чаще встречается чем написание новой хрени с нуля). Лично мне интереснее кол-во дефектов, нежели скорость программинга. А вот таких исследований не так много, по понятным причинам. Ибо индустриальные программеры не шибко озабочены замерами. А тесты на студентах на скорость написания с нуля известной задачи проводить сильно легче, но они не очень показательны для промышленных сеттингов. Поясню почему мне лично важнее кол-во дефектов, пусть даже в ущерб скорости. Я лично когда с ХР познакомился, считал что парное программирование будет медленее. Тем не менее это не обязательно плохо. Ибо баг может сильно затянуть релиз проекта. Кодинг на самом деле занимает в районе 5-15% ну может 20% издержек проекта (конечно зависит от того как считать, ибо программер может и кодить и дизайнить и тестить). Так что если ускорить кодинг, то выигрыш от этого не велик. А вот если в результатет будет баг то его найдут на тестировании, ну и вернут на доделку. А поскольку передача ответственности и оформление занимает много времени, прежде всего календарного, то это может ощутимо задержать релиз. Особенно, если при фиксе вылезет еще баги. Ну а если серьезная бага дойдет до кастомера, то может быть еще хуже. Отсюда вывод - в индустриальном сеттинге, общая эффективность зависит не от скорости кодинга, а от кол-ва багов. Ну и исследований именно на эту тему - как парное программирвоание влияет на сроки релиза проекта - я упоминаний о таковом не нашел. Как я и подозревал. А вот исследования на тему кол-ва дефектов в индустриальных сеттингах есть к примеру http://www.google.com/url?sa=t&rct=j&q=pair%20programming%20measurement&source=web&cd=4&ved=0CGAQFjAD&url=http%3A%2F%2Fwww.inf.unibz.it%2F~gsucci%2Fpublications%2Ffull%2520text%2Fc.240.pdf&ei=1LXgT_eyJ42g-waIo_X_DA&usg=AFQjCNFNs6XUZXmLbbUcnuJ_mwmtaB4uTA&cad=rja оно кагбэ подтверждает мою мыслю - парное программирование производит меньше дефектов, не во всех ситуациях значимо, но иногда - сильно меньше в частности, сильно меньше новых багов добавляется во время багофикса - вот это очень существенный результат хотя интуитивно это и так понятно - если я один кодил, то я обнаружил и предотвратил N багов, а если мы вдвоем - то я N, а коллега - M. Так что вдвоем мы обнаружим и предотвратим больше багов. Если конечно не будем друг другу мешать :).

К записи · К обсуждению