Алистэр Коуберн - Парное программирование: преимущества и недостатки

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

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

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

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

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

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

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

Экспоненциальный рост стоимости дефектов легко объяснить. Во время проверки, программист говорит: "У оператора "if", что на 450 строке кода, должен быть оператор "else"." После этого ему понадобится несколько минут, чтобы быстро исправить эту ошибку на своем компьютере. Если же программный продукт уже находится в эксплуатации, то в один прекрасный день раздается звонок разъяренного клиента: "Новый год на носу, а у меня ни одна касса не работает! Я ни-че-го не могу продать! Вы меня разоряете!"

Итак, в первом случае программист имеет дело с ошибкой, на которую ему только что указали. Во втором случае, группа технической поддержки должна потратить время на диагностику проблемы (все кассовые аппараты не работают), затем обратиться к самой системе и определить, где нужно вносить исправления (в какой строке кода не хватает оператора "else"). На этом примере всякий может убедиться - работа группы поддержки, которой надо проанализировать проблему и выявить дефект, стоит гораздо дороже, чем те несколько минут, которые должен затратить программист на исправлении ошибки в своем собственном коде. Если программисты работают парами, то такие проверки кода происходят непрерывно. А непрерыная проверка кода не только опережает спорадические "инспекции" как по качеству, так и по скорости нахождения ошибок, но и не вызывает у программистов отрицательных эмоций.

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

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

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

[со слов Рона Джеффриза]

И наконец, еще одним преимуществом постоянных проверок кода является то, что с их помощью разработчики узнают новые способы и стили кодирования, особенности языка и лучше представляют себе всю систему.

Непрерывная проверка кода при совместном программировании создает уникальные условия для обучения, поскольку оба программиста постоянно учатся друг у друга. "Проверка кода - это уникальная возможность для обучения: процесс анализа и критики программных артефактов, которые создал кто-то другой, представляет собой замечательный по эффективности способ изучения языков, техники проектирования, предметной области и т.д."

В том же ключе выдержаны и другие высказывания программистов, занимающихся проверкой кода:

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

Горазо легче соблюдать стандарты кодирования, если за этим следит сразу две пары глаз.

Команда разработчиков учится общению и совместной работе.

Было время, когда мы чувствовали, что уже готовы уже все бросить, все, кроме работы "в связке". Когда я был ведущим, я старался описать проблему таким образом, чтобы мой партнер мог как можно лучше вникнуть в ее суть. Затем в бой вступал он и боролся, до тех пор, пока не доходил до мертвой точки… затем у меня появлялась какая-нибудь хорошая идея… и так далее. Наверное, многие назовут этот метод "мозговым штурмом", но у меня остается после него совсем другое ощущение.

[- Дэвид Уагстафф (David Wagstaff), Salt Lake City]

Мы называем описанный Дэвидом Уагстаффом эффект парной эстафетой (pair relaying). Работающие парами программисты часто сообщают о том, что благодаря этому методу могут решать проблемы гораздо быстрее, а также о том, что этот метод отличается от таких процессов как улучшение качества дизайна системы, обнаружение ошибок при наборе или проведение "мозгового штурма". Под словами "Решение проблем" мы понимаем ту ситуацию, когда оба программиста озадачены сбоями в работе программы или же просто не могут решить, как им следует разрабатывать ее дальше.