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

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

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

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

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

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

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

Отчасти успех программирования встроенных систем связан с культурой и контекстом, а также, как я убедился, с применяемым подходом и профессиональной подготовкой. Многие годы я веду мастер-классы по высокопроизводительной командной работе и обучаю методам проектирования с учетом юзабилити на проводимой два раза в год Конференции по встроенным системам (Embedded Systems Conference). Когда я высказывался по поводу того, насколько быстро команды программистов встроенных систем находили действительно хорошие решения учебных задач, почти всегда кто-нибудь объяснял это тем, что большинство из них — инженеры.

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

Из журнала Software Development, том 3, № 7, июль 1995 г.

56

Заметки из итальянского ресторана

Культурным сердцем Тосканы является город великого искусства и великолепной еды. Для американцев это Флоренция, для итальянцев — Firen-ze. Колонны часто встречаются в архитектуре Firenze. При написании этой колонки [46] я черпал вдохновение в одном ресторане. На мой взгляд, он может служить образцом самых лучших методов работы, на котором мы все можем учиться.

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

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

Он был совершенным и идеальным. Его нель-зя было улучшить, не превратив во что-нибудь другое, чем он не должен быть и для чего не предназначался.

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

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