(Эта статья основана на программном докладе на осенней встрече NEPLS в 2002 году.)
Приезжающие в эту страну часто удивляются тому, что американцы любят начинать разговор с вопроса: «Чем вы занимаетесь?» Мне никогда не нравился этот вопрос. У меня редко находился на него внятный ответ. Но, кажется, я наконец-то решил эту проблему. Теперь, когда меня спрашивают, чем я занимаюсь, я смотрю человеку прямо в глаза и говорю: «Я разрабатываю новый диалект Lisp». Рекомендую этот ответ всем, кто не любит, когда его спрашивают о роде занятий. Разговор тут же переходит на другие темы.
Я не считаю, что занимаюсь исследованиями в области языков программирования. Я просто проектирую язык — точно так же, как кто-то проектирует здание, стул или новый шрифт. Я не пытаюсь открыть что-то новое. Я просто хочу создать язык, на котором будет удобно программировать. В некотором смысле такое отношение сильно облегчает жизнь.
Разница между дизайном и исследованиями, похоже, сводится к вопросу: «хорошее» или «новое». Дизайн не обязан быть новым, но он должен быть хорошим. Исследование не обязано быть хорошим, но оно должно быть новым. Думаю, эти два пути сходятся на вершине: лучший дизайн превосходит предшественников за счёт новых идей, а лучшие исследования решают проблемы, которые не просто новы, но действительно заслуживают решения. Так что в конечном счёте мы стремимся к одной и той же цели, просто подходим к ней с разных сторон.
Сегодня я собираюсь поговорить о том, как ваша цель выглядит с обратной стороны. Что именно вы делаете по-другому, когда относитесь к языкам программирования как к задаче дизайна, а не как к теме исследований?
Самое большое отличие состоит в том, что вы больше фокусируетесь на пользователе. Дизайн начинается с вопроса: для кого это предназначено и что им от этого нужно? Хороший архитектор, например, не начинает с создания проекта, который он потом навязывает пользователям, а сначала изучает предполагаемых жильцов и выясняет, что им нужно.
Заметьте, я сказал «что им нужно», а не «что они хотят». Я вовсе не хочу сказать, что работа дизайнера похожа на работу повара в закусочной, который просто готовит всё, что скажет клиент. В искусстве это варьируется от сферы к сфере, но я сомневаюсь, что существует хоть одна область, где лучшие работы создаются теми, кто просто делает в точности то, что говорят клиенты.
Клиент действительно всегда прав в том смысле, что мерилом хорошего дизайна является то, насколько хорошо он работает для пользователя. Если вы написали роман, который навевает скуку на каждого, или сделали стул, на котором ужасно неудобно сидеть, значит, вы сработали плохо, и точка. Бесполезно оправдываться тем, что роман или стул спроектированы в соответствии с самыми передовыми теоретическими принципами.
И тем не менее, делать то, что работает для пользователя, не означает просто делать то, что пользователь вам говорит. Пользователи не знают обо всех существующих вариантах и часто заблуждаются насчёт того, чего они на самом деле хотят.
Ответ на этот парадокс, я думаю, заключается в том, что вы должны проектировать для пользователя, но проектировать то, что пользователю нужно, а не просто то, что он просит. Это очень похоже на работу врача. Нельзя просто лечить симптомы пациента. Когда пациент рассказывает о своих симптомах, вы должны понять, что с ним на самом деле не так, и лечить именно это.
Эта сосредоточенность на пользователе — своего рода аксиома, из которой вытекает большая часть практики хорошего дизайна и вокруг которой вращается большинство вопросов проектирования.
Если хороший дизайн должен удовлетворять потребности пользователя, то кто же этот пользователь? Когда я говорю, что дизайн должен быть ориентирован на пользователей, я не имею в виду, что хороший дизайн нацелен на некий наименьший общий знаменатель. Вы можете выбрать любую группу пользователей. Если вы разрабатываете инструмент, например, вы можете ориентироваться на кого угодно — от новичков до экспертов, и то, что является хорошим дизайном для одной группы, может оказаться плохим для другой. Суть в том, что вам необходимо выбрать определённую группу пользователей. Я думаю, о хорошем или плохом дизайне вообще нельзя говорить без привязки к конкретному предполагаемому пользователю.
Наибольшие шансы получить хороший дизайн возникают тогда, когда среди предполагаемых пользователей оказывается сам дизайнер. Когда вы проектируете что-то для группы, в которую сами не входите, это, как правило, делается для людей, которых вы считаете менее искушёнными, чем вы сами, а не более.
И это проблема, потому что взгляд на пользователя свысока, каким бы доброжелательным он ни был, неизбежно развращает дизайнера. Я подозреваю, что очень немногие жилые комплексы для малоимущих в США проектировались архитекторами, которые рассчитывали сами в них жить. То же самое можно увидеть и в языках программирования. C, Lisp и Smalltalk были созданы для того, чтобы ими пользовались их собственные создатели. Cobol, Ada и Java были созданы для других людей.
Если вы думаете, что разрабатываете что-то для идиотов, велика вероятность, что у вас не получится ничего хорошего даже для идиотов.
Но даже если вы создаёте что-то для самых искушённых пользователей, вы всё равно создаёте это для людей. В научных исследованиях всё иначе. В математике вы выбираете абстракции не потому, что их легко понять человеку; вы выбираете те, которые делают доказательство короче. Я думаю, это справедливо для науки в целом. Научные идеи не обязаны быть эргономичными.
В искусстве же всё совершенно иначе. Дизайн полностью завязан на людях. Человеческое тело — штука странная, но когда вы проектируете стул, именно для него вы и проектируете, и от этого никуда не деться. Всем видам искусства приходится подстраиваться под интересы и ограничения людей. В живописи, например, при прочих равных картина с людьми будет интереснее картины без них. То, что на великих картинах эпохи Возрождения полно людей, вовсе не случайность истории. Если бы это было не так, живопись как выразительное средство не обладала бы тем престижем, которым она обладает.
Нравится нам это или нет, языки программирования тоже создаются для людей, и я подозреваю, что человеческий мозг столь же причудлив и полон изъянов, сколь и человеческое тело. Некоторые идеи людям даются легко, а некоторые — нет. Например, наша способность удерживать в голове детали, судя по всему, весьма ограничена. Именно этот факт изначально делает идею языков программирования хорошей: если бы мы могли справляться со всеми деталями, мы бы просто программировали в машинном коде.
Помните также, что языки — это не просто форма для готовых программ, а то, в чём эти программы разрабатываются. Любой человек искусства скажет вам, что для этих двух ситуаций могут понадобиться разные материалы. Мрамор, к примеру, — прекрасный, долговечный материал для воплощения готовых идей, но совершенно непригодный и негибкий для поиска новых.
Программа, как и доказательство, — это обрезанная версия дерева, от которого в прошлом отходили ветви тупиковых попыток. Так что проверка языка заключается не просто в том, насколько чисто выглядит на нём готовая программа, а в том, насколько чистым был путь к этой готовой программе. Решение в дизайне, обеспечивающее элегантность готовых программ, может не дать элегантного процесса разработки. Например, я написал несколько макросов, определяющих макросы, полных вложенных обратных кавычек; сейчас они выглядят как маленькие шедевры, но их написание заняло часы ужаснейших проб и ошибок, и, честно говоря, я до сих пор не до конца уверен в их правильности.
Мы часто ведем себя так, словно мерило языка — это то, насколько хорошо выглядят написанные на нём готовые программы. Это выглядит столь убедительно, когда вы видите одну и ту же программу, написанную на двух языках, и одна версия оказывается намного короче. Но если подойти к проблеме со стороны искусства, вы вряд ли станете полагаться на подобные тесты. Вам ведь не хочется получить язык программирования, похожий на мрамор.
Например, огромное преимущество при разработке программного обеспечения даёт интерактивный toplevel — то, что в Lisp называют циклом «чтение-вычисление-печать» (read-eval-print loop). И его наличие реально влияет на дизайн языка. Это, к примеру, плохо работало бы для языка, в котором вы обязаны объявлять переменные перед их использованием. Когда вы просто вводите выражения в интерактивную консоль, вам хочется присвоить x какое-то значение и сразу начать что-то делать с x. Вам не хочется сначала объявлять тип переменной x. Можно спорить с любой из этих предпосылок, но если языку для удобства необходим toplevel, а обязательные объявления типов несовместимы с toplevel, то ни один язык с обязательным объявлением типов не сможет быть удобным для программирования.
На практике, чтобы получить хороший дизайн, нужно подобраться ближе к своим пользователям и оставаться рядом с ними. Нужно постоянно проверять свои идеи на реальных пользователях, особенно в самом начале. Одна из причин, почему романы Джейн Остин так хороши, заключается в том, что она читала их вслух своей семье. Вот почему она никогда не скатывается в самолюбование витиеватыми описаниями пейзажей или вычурное философствование. (Философия там есть, но она вплетена в сюжет, а не наклеена сверху, как ярлык.) Если вы откроете средний «литературный» роман и представите, что читаете его вслух своим друзьям как собственное сочинение, вы слишком остро почувствуете, насколько это мучительно для читателя.
В мире разработки ПО эта концепция известна как «Хуже — значит лучше» (Worse is Better). На самом деле в концепции Worse is Better смешано несколько идей, именно поэтому люди до сих пор спорят о том, действительно ли худшее лучше. Но одна из главных мыслей в этой смеси заключается в том, что если вы создаёте что-то новое, прототип нужно показать пользователям как можно скорее.
Альтернативный подход можно назвать стратегией «Аве Мария». Вместо того чтобы быстро выкатить прототип и постепенно дорабатывать его, вы пытаетесь выдать полностью готовый продукт за один отчаянный бросок. Насколько я знаю, это верный путь к катастрофе. Бесчисленное множество стартапов погубило себя таким образом во время интернет-бума. Я не слышал ни об одном случае, когда бы это сработало.
Люди за пределами мира ПО могут не осознавать, что идея Worse is Better встречается во всех видах искусства. В рисунке, например, этот принцип был открыт в эпоху Возрождения. Сегодня почти любой преподаватель рисования скажет вам, что правильный способ сделать точный рисунок — это не медленно вести линию по контуру объекта, потому что ошибки будут накапливаться, и в конце вы обнаружите, что линии не сходятся. Вместо этого следует набросать несколько быстрых штрихов примерно в нужных местах, а затем постепенно уточнять этот первоначальный набросок.
В большинстве областей прототипы традиционно изготавливались из других материалов. Шрифты, которые предстояло отлить в металле, изначально рисовались кистью на бумаге. Статуи, предназначенные для отливки в бронзе, лепились из воска. Узоры для вышивки на гобеленах рисовались тушью на бумаге. Здания, которые должны были строиться из камня, проверялись в уменьшенном масштабе из дерева.
Масляные краски, когда они впервые стали популярны в пятнадцатом веке, вызвали такой восторг именно потому, что готовую работу можно было создавать прямо из прототипа. При желании можно было сделать предварительный рисунок, но вы не были к нему привязаны; вы могли прорабатывать все детали и даже вносить кардинальные изменения по мере завершения картины.
В разработке ПО можно поступать точно так же. Прототип не обязан быть просто макетом — его можно доработать до готового продукта. Я думаю, так следует поступать всегда, когда есть возможность. Это позволяет использовать новые инсайты, приходящие в процессе работы. Но, что, возможно, ещё важнее, это поддерживает боевой дух.
Боевой дух — ключевой фактор в дизайне. Меня удивляет, что люди так мало говорят об этом. Один из моих первых учителей рисования сказал мне: если тебе скучно, когда ты рисуешь, рисунок получится скучным. Представьте, к примеру, что вам нужно нарисовать здание и вы решаете прорисовать каждый кирпич по отдельности. Вы можете это сделать, если хотите, но если на полпути вам станет скучно и вы начнёте штамповать кирпичи механически вместо того, чтобы всматриваться в каждый, рисунок получится хуже, чем если бы вы просто обозначили кирпичную кладку намеком.
Создание чего-либо путём постепенной доработки прототипа полезно для морального духа, потому что это удерживает вас вовлечённым. В программировании моё правило таково: код всегда должен работать. Если вы пишете что-то, что сможете протестировать уже через час, у вас появляется перспектива немедленного вознаграждения, которая вас мотивирует. То же самое верно и для искусства, особенно для живописи маслом. Большинство художников начинают с размытого наброска и постепенно уточняют его. Если работать так, то в принципе вам никогда не придётся заканчивать день с тем, что выглядит откровенно незавершённым. Среди художников даже есть поговорка: «Картина никогда не бывает закончена, над ней просто прекращают работу». Эта мысль покажется знакомой каждому, кто занимался разработкой ПО.
Боевой дух — ещё одна причина, по которой трудно проектировать что-то для неискушённого пользователя. Трудно сохранять интерес к тому, что не нравится тебе самому. Чтобы сделать что-то хорошее, нужно думать: «Ух ты, это действительно здорово», а не «Что за дерьмо; но этим дуракам сойдёт».
Дизайн означает создание вещей для людей. Но человек здесь — не только пользователь. Дизайнер — тоже человек.
Заметьте, всё это время я говорил о «дизайнере» в единственном числе. Дизайн обычно должен находиться под контролем одного человека, чтобы получиться стоящим. И всё же над исследовательским проектом вполне могут сотрудничать несколько человек. Мне это кажется одним из самых интересных различий между исследованиями и дизайном.
В искусстве бывали знаменитые примеры совместной работы, но большинство из них больше походили на молекулярные связи, чем на термоядерный синтез. В опере обычное дело, когда один человек пишет либретто, а другой — музыку. А в эпоху Возрождения подмастерьев из Северной Европы часто нанимали для написания пейзажей на заднем плане итальянских картин. Но это не настоящее сотрудничество. Это скорее примеры поговорки Роберта Фроста: «Хорошие заборы делают хороших соседей». Вы можете соединять вместе отдельные примеры хорошего дизайна, но внутри каждого конкретного проекта контроль должен оставаться у одного человека.
Я не утверждаю, что хороший дизайн требует, чтобы один человек сам до всего додумался. Нет ничего ценнее совета того, чьему суждению вы доверяете. Но после того как обсуждение закончено, решение о том, что делать, должно приниматься одним человеком.
Почему исследования можно делать сообща, а дизайн — нельзя? Это интересный вопрос. Я не знаю ответа. Возможно, если дизайн и исследования сходятся, то лучшие исследования — это тоже хороший дизайн, и на самом деле их нельзя проводить коллективно. Многие из самых знаменитых учёных, похоже, работали в одиночку. Но я знаю недостаточно, чтобы утверждать, что здесь есть закономерность. Возможно, просто многие знаменитые учёные работали в те времена, когда сотрудничество было менее распространено.
Как бы то ни было в науке, настоящее сотрудничество в искусстве встречается исчезающе редко. Коллективный дизайн (design by committee) — синоним плохого дизайна. Почему так происходит? Можно ли как-то преодолеть это ограничение?
Я склонен думать, что нет: для хорошего дизайна нужен диктатор. Одна из причин заключается в том, что хороший дизайн должен быть цельным. Дизайн создаётся не просто для людей, а для конкретного отдельного человека. Если дизайн воплощает идею, которая помещается в голове у одного человека, то эта идея поместится и в голове пользователя.
Связанные ссылки: