Парное программирование: преимущества и недостатки - [4]

После выполнения нескольких заданий двое программистов, работавших в паре, стали жаловаться, что дескать, задания назначаются несправедливо: "парам" приходится работать больше, чем "одиночкам". Инструктор тут же предложил этим студентам перейти в группу "индивидуалов" и работать по одному, но оба даже слышать об этом не хотели. Больше никаких жалоб на "несправедливость" от них не поступало.

Нам кажется, что такое поведение свидетельствует о том, что разработчикам нравится работать вдвоем.

Качество дизайна системы

Ниже мы приводим слова руководителя одной из команд разработчиков, который и слыхом не слыхал о парном программировании. Здесь он объясняет, почему все его проектировщики-программисты работают вместе за одним терминалом.

Во время работы над проектом я заметил, что одна из наших команд всегда разрабатывает дизайн более высокого качества. Я спросил у ребят, как это им удается.

Они сказали, что это происходит потому, что они стали работать вместе - как над дизайном программы, так и над его реализацией в коде. В результате, и дизайн, и код становятся лучше. Я согласился с ними и перевел все остальные команды на тот же стиль работы. Теперь качество дизайна стало намного лучше.

[из архивов Алистэра Коуберна]

В 1991 году Ник Флор (Nick Flor), занимавшийся в то время когнитологией (Cognitive Science), сделал интересный вывод о распределенности знаний у программистов, работавших в паре, которых он изучал. Распределенное знание - это один из разделов когнитологии, основное положение которого можно выразить словами: "Все, кому приходилось изучать процесс осмысления, были поражены тем фактом, что "разум" очень редко работает в одиночку. Вся данные, которые человек поднимает во время этого процесса, оказываются распределенными - по различным умам, людям, а также символическому и физическому окружению, в котором этот человек находится."

С помощью видео и аудио аппаратуры Флор фиксировал все виды обмена мнениями между двумя программистами, которые работали над одной задачей. В этом исследовании Флор установил соотношения между вербальным и невербальным поведением программистов. Для этого он использовал известные когнитологические теории, касающиеся распределенного знания. Одна из таких теорий - "Поиск в более обширном пространстве возможностей" ("Searching Through Larger Spaces of Alternatives.")

"С точки зрения генерации разнообразных планов, система со многими действующими лицами обладает большим потенциалом. Можно назвать, по крайней мере, три причины: во-первых, все действующие лица привносят в разработку свой уникальный личный опыт; во-вторых, каждый из них обладает своим подходом к информации, касающейся выполняемой задачи; в-третьих, все они находятся в разных отношениях к проблеме, поскольку выполняют разные функциональные роли… Главным следствием попытки свести воедино все имеющиеся цели и планы является то, что в такой конфликтной, по сути, ситуации программисты должны открыто договориться, какую последовательность действий необходимо будет предпринять. Вырабатывая, таким образом, единое общее решение, они перебирают гораздо большее количество альтернативных вариантов, чем мог бы в такой ситуации программист-одиночка. Именно это обстоятельство и ведет к снижению риска выбора плохого плана действий."

Посмотрите, что говорит программист, работающий в паре с партнером, и как это совпадает с тем, что мы прочли у Флора:

Часто все мы имели разные идеи относительно того, как должен выглядеть дизайн системы. Как правило, пока мы спорили, какой из вариантов лучше, мы действительно приходили к самому лучшему решению, которое являлось гибридом всех предложенных вначале.

Во время количественных исследований, проведенных в университете Юта, работающие попарно программисты не только разрабатывали программы высокого качества, но и реализовывали необходимую функциональность в меньшем количестве строк кода, чем программисты-одиночки. Более подробно эти данные представлены на рисунке 4. Нам кажется, что краткость программного кода свидетельствует о более качественном дизайне всей системы.

Рисунок 4: Количество строк кода

Непрерывность проверки кода

Уже двадцать лет тому назад было установлено, что визуальная проверка кода - это эффективный, с точки зрения стоимости, метод исправления дефектов в программных продуктах. Это подтверждают и эмпирическими исследованиями, однако несмотря на это, большинство программистов не любят проверок и не считают это занятие ни приятным, ни стоящим. В результате о проверках, как правило, забывают (за исключением тех случаев, когда их выполнение требуется официально). Зачастую проверку кода осуществляют неподготовленные к этой задаче программисты.

"Несмотря на положительные результаты исследований в течение более 20 лет, процедура проверки кода очень плохо приживается в индустрии производства программных продуктов. Точных данных у нас нет, однако согласно неформальному обзору USENET-групп, 72 из 90 опрошенных программистов практикуют проверку кода крайне редко, или вообще ей не занимаются."

Идея проверки кода базируется на известном постулате: чем раньше обнаружен дефект, тем проще и дешевле его исправить. Существует много исследований на эту тему, в некоторых даже утверждается, что исправление дефекта будет стоить в десять раз дороже на каждой последующей ступени развития проекта.