Заработают ли когда-нибудь программы?

Можно ли считать сегодняшнее программное обеспечение каким-то показателем — безусловно нет; в большинстве сегодняшних программ содержится огромное количество ошибок. Большие, сложные продукты типа Microsoft Word выпускаются, даже когда их производитель знает, что в них тысячи ошибок. Классический пример — неверно поставленная запятая в программе на Фортране, из-за которой в 1962 году сорвалась космическая миссия Mariner 1 Venus. Компьютеры ломаются или зависают, а приложения теряют данные или файлы, казалось бы, безо всяких причин. Загадочные сообщения об ошибках только запутывают пользователей.

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

Проблема не в том, как полагают многие, что проектировщики систем и программисты делают ошибки. Это неизбежно. Человеку свойственно ошибаться. Разумеется, нам известны многие приемы разработки программ, которые могут и должны уменьшать вероятность и масштабы ошибки — приемы систематического проектирования, хороший стиль программирования, использование «безопасных» языков программирования и качественное тестирование перед выпуском. Вряд ли можно надеяться на то, чтобы полностью избавиться от ошибок в программном продукте до его выпуска. Действительная проблема на самом деле заключена в том, что когда возникает ошибка, у нас нет подходящих способов выяснить, что именно пошло не так и как это исправить. Именно это мы и должны изменить.

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

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

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

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

Экономические противовесы

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

Надежные продукты вытесняются продуктами, предоставляющими больше возможностей. Другая проблема — регулярные выпуски программных продуктов и сопутствующая этому путаница с версиями, когда продукт А зависит от версии 1 продукта B, но версия 2 продукта B уже не работает с продуктом А. Нельзя просить пользователей отслеживать эти зависимости и разбираться с ними вручную. Эти условия практически гарантируют ненадежность современного программного обеспечения.

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

Мачо-программисты

Другим препятствием является самоуверенность, лежащая в основе программистской культуры. «Настоящим программистам» не нужны отладчики. Люди, в силу своей психологии, не любят признавать, что в их программах множество ошибок, и в силу этого им не хочется тратить время и деньги на улучшение процесса их исправления. Профессор Джон Гуттаг из Массачусетского технологического института, специалист в области разработки программного обеспечения, говорит: «Обнаружить в своей программе ошибку — все равно, что найти на кухне таракана; если есть один, возможно, есть и еще, и в этом нет ничего приятного», — намекая такой неприятной метафорой на то, что причиной появления ошибки является небрежность разработчика. Нам кажется, что именно неприятие того факта, что в ошибках и отладке нет ничего ненормального, привело к тому, что программы ненадежны.

Инструменты отладки для конечного пользователя

Это может прозвучать глупо, но программное обеспечение будет работать только, если мы будем предоставлять инструменты, позволяющие исправить его в случае ошибки. Сейчас этого не происходит. Предоставление конечным пользователям отладочного инструментария кажется нам важным новым направлением развития ПО. Пользователи сами смогут использовать его для того, чтобы исправлять или улучшать программы. Ненормально, что мы не можем в любой момент времени спросить у компьютера: «Что ты делаешь?» или «Зачем ты это сделал?» Если мы не можем получить простейшую информацию такого рода, мы не сможем объяснить программистам, что пошло не так. Новая интересная технология, дающая конечным пользователям процедурный контроль, ранее доступный только профессиональным программистам, — это технология «программирование через примеры», также известная как «программирование путем демонстрации» (пользователь показывает компьютеру примеры требуемого поведения) [2]. Когда пользователь хочет научить компьютер делать что-то новое или необычное, он пошагово показывает пример через пользовательский интерфейс, а компьютер реагирует на это и создает программу.

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

Корпорация Boeing потратила больше 100 млн. долл. на разработку приборной панели в своем самолете «Боинг-777», хотя ее пользователями являются всего несколько сотен пилотов. Эти расходы были оправданы, поскольку те сотни пилотов переправляют по всему свету миллионы пассажиров, которые в случае катастрофы платят за последствия.

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

Инструменты отладки представляют собой приборную панель в программировании. Но в основе хороших инструментов должен лежать язык программирования, спроектированный так, чтобы облегчать отладку. Язык должен быть динамическим (должна быть возможность легко изменить что угодно в любой момент времени) и интроспективным (предоставлять широкий доступ к своим внутренним механизмам). Одна из причин, по которой за последние годы процесс отладки не улучшился, заключается в том, что программисты в погоне за эффективностью застряли в неудобных для отладки языках наподобие Cи или C++. Закон Мура гласит, что быстродействие компьютеров удваивается каждые 18 месяцев. Закон Фрая гласит, что производительность программных сред удваивается раз в 18 лет, если не реже. Речь идет не просто о скорости, с которой выполняется приложение, а, что более важно, о скорости разработки надежной функциональности программного обеспечения, независимо от того, с какой скоростью оно работает.

Не будем вдаваться подробно в то, сколькими способами можно улучшить отладчики; в [1] и [3] описываются мириады новых интересных разработок и направлений развития. Важной составляющей отладочных программ является визуализация программы, позволяющая при помощи немалых графических возможностей современных компьютеров и наших могучих аналитических способностей быстро пространственно и в динамике видеть, что происходит в программе. Другие типы инструментов позволяют локализовать ошибки, диагностировать и анализировать проблемы и позволяют частям программной среды следить за своим поведением.

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

Литература

Генри Либерман (lieber@media.mit.edu) — ученый-исследователь из лаборатории Media Lab Массачусетского технологического института. Кристофер Фрай (cfry@bowstreet.com) — старший программный инженер компании Bowstreet.

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

Henry Lieberman and Christopher Fry, Will Software Ever Work? Communications of the ACM, March of 2001, vol. 44, no. 3