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

Рассмотрим, к примеру, случай с ошибкой, которую нельзя воспроизвести. "Один-два раза в год мы получаем от недовольных пользователей уведомления о том, что наша программа неверно выводит информацию на печать, - пишет один из разработчиков. - Все остальные программы печатают прекрасно. Ни один из других пользователей, у которых установлен тот же самый принтер, ни разу не сообщал о подобных затруднениях. Мы не в состоянии воспроизвести подобную ситуацию. Чья это ошибка? Наша? Производителя принтера? Windows? Нужно ли изучать или исправлять подобную ситуацию всего из-за двух жалоб за целый год? Ни в коем случае. Лучше предложить этим пользователям забрать назад свои деньги - так выйдет дешевле. Но могу поспорить, что в данном случае эти двое будут возмущаться так, словно их двести".

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

Какая у вас системная плата, с каким набором микросхем, какой графический адаптер, звуковая плата, контроллер жесткого диска, какая версия операционной системы и какие обновления для нее установлены? И так далее, и так далее. При вероятности возникновения тысяч потенциальных конфликтов в одном компьютере разве может разработчик быть уверен в том, что его программа работает устойчиво? Разве сообществу разработчиков под силу определить стандарты, которые обеспечат совместимость с будущими версиями своих программ и программ конкурентов? А если нет, то каждое исправление одной ошибки тут же порождает другую.

Даже представители тех кругов, в которых программное обеспечение тщательнейшим образом тестируется, соглашаются с тем, что несмотря ни на что ошибки остаются. "Я, разработчик систем управления технологическими процессами, убежден, что наши программы бывают действительно хорошо протестированы, прежде чем передаются пользователям, - написал другой читатель. - Готовое ПО проходит четыре стадии тестирования: инженером-разработчиком, специалистом в области проектирования, инженером отдела технического контроля и наконец апробирование в качестве бета-версии. Даже если эта процедура предусматривает очень серьезное тестирование, в окончательной версии все равно присутствуют ошибки. Эти ошибки проявляются лишь в тех случаях, когда инструмент используется в несвойственной для него манере или же возникает какая-то строго определенная последовательность событий. Воспроизвести каждую из возможных ситуаций просто нереально".

При эксплуатации ПО иногда проявляются ошибки, которые могли и не являться таковыми на этапе проектирования. "Большая часть наших ошибок возникает, когда пользователи выполняют трудно предсказуемые на момент разработки действия и обращаются к программе с запросами, которые не позволяют точно понять, что же на самом деле им нужно, - написал один из разработчиков приложений для телекоммуникационной отрасли. - Иногда мы самостоятельно должны находить решение в тех областях, где являемся первопроходцами. В некоторых случаях очень сложно выявить ошибки, о которых мы ранее не задумывались и которые практически невозможно вычислить до столкновения программы с реальной жизнью. Если проводить аналогию с автомобилем, то понятно, что производители никак не могут уберечь клиента от последствий вождения в пьяном виде или от попадания в дорожно-транспортное происшествие после проезда на красный свет. Единственное, что они в состоянии сделать, - это спасти его от последствий выполнения непредсказуемых действий. Пользователя можно контролировать путем ограничения предоставляемых ему возможностей и поставки ‘свободного от ошибок ПО’, функциональность которого сильно ограничена. Однако для пользователя это, как правило, неприемлемо, а потому поступать так все же не следует".

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

Итак, я думаю, все согласятся с тем, что некоторые ошибки очень трудно, а иногда и просто невозможно обнаружить. Но где находится та грань, через которую не следует переступать? Клиент может быть неправ, полагая, что определенное поведение программы является ошибкой конкретного разработчика, но тем не менее пользователю необходимо найти какое-то решение. ПО с ошибками вызывает гораздо меньше осложнений, если оно не поставляется со слабой технической поддержкой, его приобретение не влечет за собой необходимости чрезмерно дорогого технического сопровождения, а обновление версий не добавляет новых ошибок к уже имеющимся старым.

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

С Эдом Фостером, работающим с почтой читателей еженедельника InfoWorld, можно связаться по адресу gripe@infoworld.com.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам