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

Для начала следует определить для себя, что можно считать хорошим программным обеспечением. Начнем с того, что оно должно быть недорогим, а лучше - дешевым. Причем недорогим во всех смыслах - и сам продукт не должен стоить больших денег, и затраты на его поддержку должны быть как можно ниже.

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

В программе не должно быть ошибок. Разумеется, это невыполнимое требование - идеальных продуктов не бывает. Его можно перефразировать следующим образом: в программе не должно быть значительных ошибок, с которыми со средней долей вероятности может столкнуться средний пользователь. А исправление ошибок должно происходить максимально безболезненно для пользователя - переустановку новой, «исправленной» версии пакета безболезненной назвать нельзя, равно как и копание в системном реестре, правка значений вручную и множество других способов исправления ошибок, которые предлагают потребителям софтверные компании, движимые чувством вины.

Из предыдущего условия естественно вытекает требование надежности программы и безопасности данных, с которыми она работает.

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

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

Много ли программ мы можем назвать соответствующими этим требованиям? Увы. Даже если отбросить российскую специфику, в рамках которой ненулевая стоимость любой программы считается недостатком.

Microsoft Office? Дорог, довольно сложен в освоении и, как любая продукция Microsoft, мягко говоря, не свободен от ошибок. Не слишком надежен - любая из составных частей пакета может «упасть» в любой момент. О безопасности работы с данными можно даже не говорить. При этом Microsoft Office на сегодняшний день является одним из лучших (если не лучшим) офисным пакетом.

Windows? Разнобой версий операционных систем, объединенных под одной торговой маркой, не позволяет аргументированно облить грязью сразу все. Попробуйте предъявить описанные требования любой из них, наиболее вам знакомой. Как результат? Вдохновляет?

Linux? Не так свободен от ошибок, как принято считать. Не так дешев (если учитывать трудозатраты на обслуживание), как принято считать. Не так, не так, не так… И чудовищно сложен в освоении, если сравнивать его с Windows. Знаменитая фраза «Windows SuXX, Linux Rules» говорит скорее об однобокости подхода, чем о реальных качествах этих систем.

Список, к сожалению, можно продолжать до бесконечности.

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

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

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

С заявленными функциями тоже все нормально. Большинство популярных пакетов вполне соответствует ожиданиям. Функциональность многих из них превосходит самые смелые требования пользователей. Известно, например, что даже продвинутые пользователи Microsoft Word используют не более четверти заложенных в него возможностей. Факт этот был обнародован во времена Microsoft Office 97. Сейчас, скорее всего, дела обстоят так же, если не хуже.

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

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

Почему качество программных продуктов leaves much to be desired ¹? Одной из главных причин, вероятно, является то, что computer science вообще и программирование в частности относительно молоды. Еще недавно программированием занимались по большей части из любви к искусству, ради процесса, - конечный результат программистов интересовал постольку поскольку. Главное - добиться принципиального решения поставленной задачи. Детали никого не интересуют. Другими словами, низкое качество прикладных программ проистекает из того, что программирование до недавнего времени было слишком академической (здесь: мало применяющейся в реальной жизни) дисциплиной. Первые программисты были скорее творцами, чем ремесленниками. Несмотря на то, что творческий элемент на уровне кодера из программирования давным-давно выхолощен, отсутствие критического отношения к результатам своего труда осталось.

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

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

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

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

Иногда, кстати, речь может идти и о сужении функциональности. Заявление Microsoft о том, что из Windows нельзя исключить Internet Explorer без потери части функциональности, многие аналитики считают признанием чудовищности архитектуры (или, скорее, отсутствия архитектуры как таковой) Windows. Разумеется, если допустить, что утверждение Microsoft правдиво, а не есть очередная попытка сохранить свое положение на рынке ПО.

Еще один виновник плохого качества программ - тестировщики. По данным американского Национального института программного обеспечения и технологий ² (NIST), некачественное тестирование софта обходится США почти в 60 млрд. долларов ежегодно. При этом учитывалась только стоимость исправления ошибок - во сколько ошибки обходятся пользователям и какой урон наносят бизнесу, в NIST не знают ³. Конечно, возлагать всю вину на тестеров нельзя - программисты тоже в какой-то степени расхолаживаются, когда знают, что есть люди, в чьи должностные обязанности входит выявление допущенных программистами ошибок.

Последнее приходящее в голову соображение состоит в следующем. Слишком большие возможности современного «железа» провоцируют программистов на некритичное отношение к собственному труду. Память слишком дешева, процессоры слишком быстры… Разумеется, это утверждение относится не ко всем разновидностям ПО - существуют задачи, для которых производительности даже современных процессоров маловато. Однако много ли новых ключевых возможностей появилось в том же Microsoft Excel за последние, скажем, семь лет? А мощности-то выросли изрядно.

«Железная гонка вооружений», спровоцированная в известной степени производителями ПО, привела к тому, что «провокаторы», добившись своего, не слишком озабочены оптимизацией кода и порой стреляют из пушки по воробьям.

Мы коснулись проектирования в предыдущем разделе. Настало время поговорить о нем подробнее.

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

Неправильно поставленная задача вкупе с неправильно спланированным порядком работы приводят к поистине плачевным результатам. Так, по исследованиям Standish Group, до финального релиза доживает лишь три четверти начатых проектов (статистика американская; в России, насколько нам известно, таких исследований не проводилось). При этом, конечно, не учитываются софтверные проекты, изначально обреченные на бесславную смерть - студенческие или любительские ⁴. Речь идет о серьезных, казалось бы, начинаниях - о программных продуктах, в разработку которых были вложены деньги. «Недопетые песни» обошлись производителям в 2000 году в 67 миллиардов долларов. Плюс еще 21 миллиард долларов ушел на дополнительную разработку, когда оказалось, что в поставленные сроки разработчики не уложились. Если вы узнаете, что порядка 80% бюджетов софтверных фирм уходит на поиск и устранение ошибок в собственных программах, возможно, вам захочется помочь им финансово.

Одним из самых известных оправданий плохого качества ПО является его сложность и скорость, с которой рынок требует выдавать новые версии. Понятно, что если бы Microsoft до сих пор вылизывала MS-DOS 3.3, эта ОС была бы в настоящее время близка к совершенству.

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

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

Что нас ждет дальше? С каждым годом роль программного обеспечения в нашей становится неуклонно возрастает. Все больше и больше задач решается только с помощью компьютеров. Усилия специалистов по quality software пока видимых результатов не дают (а может быть, и дают, - ведь неизвестно, что было бы, если б качество ПО оставить на совести программистов). Интересно, что компании, которые должны быть не меньше пользователей заинтересованы в выпуске отличного продукта, очень часто препятствуют обсуждению качества своего ПО. Некоторые даже запрещают публиковать сравнительные тесты производительности своих продуктов, предусмотрев эту ситуацию в лицензии (обосновывается все, конечно, красиво - считается, что для проведения таких тестов нужна определенная классификация, и тесты, проведенные неправильно [а также не устраивающие компанию], могут навредить образу продукта). Довольно часто на внесение исправлений намеренно откладывается - пытаясь объять необъятное, производители программ перед выходом новой версии продукта решают, какие ошибки нужно исправить немедленно, какие отложить до первого сервис-пака, а за какие взяться только после того, как о них сообщат пользователи. Случись подобное в любой другой индустрии (вы можете представить себе такую ситуацию в фармацевтике?), и производитель немедленно был бы засыпан исками. В случае с ПО это считается нормальной практикой и никого не шокирует.