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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение проблем

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

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

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

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