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

Подобно мексиканскому строителю, который ставил стоимость выше соображений проектирования, предоставленные сами себе инженеры ценят эффективность программирования больше, чем это необходимо пользователю. Лучшим свидетельством в пользу этого тезиса является практика повторного использования кода, то есть кода, который был ранее создан для какого-то иного проекта или же мог быть приобретен за определенную сумму у сторонней фирмы. Написанный код не просто экономит время; очевидно, что и другие программисты могут его использовать, и к тому же код не содержит ошибок. Одно из уникальных свойств программ состоит в том, что любую процедуру можно выполнить всего одной командой, но при этом размер процедуры не ограничен. Иначе говоря, если процедура уже написана, ее можно задействовать одной командой. Следовательно, любой уже написанный модуль кода оказывается значительным подспорьем для программистов. Они могут включать его в свои программы в качестве черного ящика, внутреннее устройство которого никогда не требует их вмешательства. Программист таким способом экономит время не только непосредственно на этапе программирования, также и на размышлениях и тестировании. Для большинства программистов повторное использование кода становится более важным, чем практически любое другое соображение. Знаменитый идеолог UNIX Эрик Реймонд (Eric Raymond) говорит:

«Хорошие программисты знают, что писать, великие – что надо использовать повторно».

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

К примеру, приложения для настольных компьютеров содержат так много меню и текстовых диалоговых окон потому, что все оконные системы Мiсrоsоft Windows, Мас OS, OS/2, Solaris – предоставляют готовые модули кода, обеспечивающие работу таких функций. И наоборот, ни одна из этих систем не содержит большого количества кода для механизмов drag-and-drop; вот почему в приложениях так мало непосредственного манипулирования (direct manipulation). Диалог можно создать при помощи шести-восьми строк простого декларативного кода. Идиома drag-and-drop требует примерно сотни строк весьма запутанного процедурного кода. Выбор программиста здесь очевиден. Выгоды конечного пользователя в контексте такой экономии обычно не рассматриваются.

История с мексиканским строителем все время повторяется в разработке программного обеспечения, в основном благодаря стремлению программистов повторно использовать код. Эд Форман (Ed Forman), руководящий разработкой ПО в Elemental Software, прежде чем загрузить программистов работой, создает подробный и точный набросок внешнего вида экрана. Несмотря на это, говорит Эд, экран готовой программы являет собой лишь бледную тень этого эскиза.

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

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

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

* * *

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

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

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

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

* * *

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

Недавно на конференции я встретил Джеффа Безоса (Jeff Bezos), основателя Amazon.com, и рассказал ему, как мне нравится интерфейс «в один щелчок» (1-Click) на его веб-сайте. Этот интерфейс позволяет посетителю заказать книгу – большой сюрприз – в один щелчок. Интерфейс действительно хорош, поскольку избавляет посетителя от докучающих деталей: можно просто нажать кнопку и не указывать повторно адрес и информацию по оплате.

Джеффри было приятно слышать, что мне понравился 1-Click, и он рассказал, что разработал идею со своими проектировщиками, после чего идею показали программистам. Те, разумеется, покивали и согласились, что задача решаема. Программисты удалились, и какое-то время писали код, а затем показали результаты Джеффу. Он нашел желаемую книгу и нажал кнопку 1-Сlick. И тут программа отобразила сообщение, требующее подтверждения! Программисты превратили интерфейс «в один щелчок» в интерфейс «в два щелчка». Для программистов это был лишь один дополнительный щелчок (делов-то?). Для Джеффа, как и для любого пользователя, это все равно что стопроцентный рост инфляции. Джеффу пришлось действовать кнутом и пряником, прежде чем программисты создали интерфейс 1-Click, позволяющий делать заказ в один щелчок. Джефф не скажет мне, насколько 1-Click увеличил продажи книг, но лично я благодаря этому интерфейсу трачу на покупку книг вдвое меньше времени.

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

Дата добавления: 2015-07-19