8. Вымирающая культура

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

Культура программирования

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

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

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

Повторное использование кода

Как и тот мексиканский строитель, ценивший стоимость проекта выше его дизайна, так и программисты, предоставленные сами себе, поставят эффективность программирования выше, чем потребности пользователя. Лучше всего это утверждение доказывает практика повторного использования кода, написанного ранее для какого-либо другого проекта или приобретенного за символическую цену у сторонних разработчиков. Готовый код не просто экономит время – он уже доказал свою пригодность у других программистов, а кроме того, в нем определенно отсутствуют баги. Для программ характерно одно уникальное свойство – любую процедуру в них можно вызвать с помощью всего лишь одной команды, при этом размер процедуры значения не имеет. Получается, что, если процедура уже написана, требуется лишь одна строка кода, чтобы осуществить ее вызов. Таким образом, любой готовый программный модуль представляет собой отличное подспорье для разработчиков. Они могут подключать такие блоки кода к своим программам, рассматривая их как черные ящики, в работу которых нет необходимости вмешиваться. Такой подход влечет значительную экономию не только во времени программирования, но и во времени обдумывания задачи и ее тестирования. Большинство программистов придают повторному использованию кода невероятную важность – выше, чем любому другому техническому соображению. Идеолог открытого программного обеспечения Эрик Рэймонд как-то сказал: «Хороший программист знает, как писать код. Великий программист знает, где взять готовый».

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

Вот пример: наши настольные приложения состоят из такого большого количества меню и диалоговых окон с вводом текста из-за того, что во всех операционных системах с оконным интерфейсом – Microsoft Windows, Мас OS, OS/2, Linux – имеются готовые блоки кода для обеспечения функционирования этих компонентов. И напротив, ни в одной из этих систем не существует достаточного количества готового кода для работы с элементами посредством операций drag-and-drop, оттого в приложениях так редко используется технология непосредственного манипулирования (direct manipulation). Диалог создается за 6–8 строк простого декларативного кода, в то время как для описания механизма drag-and-drop требуется около 100 строк весьма замысловатого процедурного кода. Для программиста выбор очевиден. Выгода для конечного пользователя в погоне за этой экономией как-то упускается.

Я постоянно наблюдаю, как снова и снова в разработке программного обеспечения возникает эта история с мексиканским строителем; по большей части это происходит из-за того, что программисты вынуждены прибегать к повторному использованию кода. Так, Эд Форман, руководитель разработки программного обеспечения в компании Elemental Software, создает детализированный и точный набросок того, что он хотел бы видеть на экране, и делает это до того, как отдать задачу в работу программистам. И все равно, по словам Эда, программа, которую он получает в итоге, всегда представляет собой лишь блеклое подобие того, что он набросал.

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

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

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

* * *

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

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

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

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

* * *

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

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

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

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