Человеческий фактор в программировании - Ларри Константин

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

Компьютеры, на которых работают встроенные приложения, могут выглядеть маленькими и незначительными, будучи скрытыми внутри CD-плейеров или детских игрушек. Другое дело программы. Цветной лазерный копир может содержать миллионы строк на С, а в лабораторном осциллографе тысячи классов, написанных на Smalltalk, ждут своей инициализации. Большинство этих приложений предъявляют высокие требования к точности, безошибочности, повторяемости и надежности. Ошибки могут проявляться самым очевидным образом. Они могут сбивать с толку и даже быть опасными, например в программном обеспечении рентгенологического аппарата, промышленного робота или автомобиля. Добавьте к этому необходимость работы в реальном масштабе времени, что характерно для многих приложений, и планка поднимается еще выше.

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

Стоимость апгрейда

На этот вопрос ответить довольно легко. Например, одна-единственная ошибка во встроенном обеспечении одного из принтеров Hewlett-Packard может помешать этой компании достичь новых успехов. Если достаточно серьезная ошибка обнаруживается после выпуска продукта, то расходы на апгрейд ПЗУ будут больше, чем прибыль, полученная за весь период существования данной серии. Это серьезный стимул не допускать ошибок с самого начала. Так они и делают. Ни одна большая программа не бывает идеальной, однако некоторые программисты встроенных систем создают огромные программы с качеством, настолько близким к безупречному, насколько это вообще возможно. Дальнейшее снижение количества ошибок просто-напросто потребовало бы слишком больших затрат.

Может быть, в этом отчасти и состоит проблема компаний вроде Microsoft и IBM: нет достаточного стимула для того, чтобы делать все правильно, особенно когда покупатели согласны мириться с нелепым программным обеспечением, содержащим ошибки. Поставщики программного обеспечения всегда могут незаметно внести исправления в выпускаемые продукты, или просто выпустить исправленную версию 6.0а по цене CD-дис-ка, или же выложить ее в Интернете, чтобы каждый мог самостоятельно ее скачать.

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

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

Рутина

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

Программисты, создающие такой код, склонны работать тщательно и скрупулезно. В первую очередь они стремятся сократить количество ошибок. С точки зрения качества программного обеспечения такие программисты имеют низкий «изначальный уровень» программных багов. Конечно, дешевле всего найти и исправить те ошибки, которым вы не позволяете проникнуть в код. Программисты встроенных систем широко применяют тактику выявления изъянов непосредственно во время рабочего цикла, вылавливая ошибки как можно раньше — пока их легко найти и просто исправить. Для сокращения количества ошибок проводятся тщательные многократные проверки расчетов и кода. Такой метод требует намного меньше затрат и является более эффективным, чем тестирование и отладка на завершающей стадии проекта.