Парное программирование: преимущества и недостатки - Страница 9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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