xmlhack.ru logo
>> статьи на xmlhack.ru

Выиграй, отказавшись

Автор: Мика Дубинко
Перевод: А.Скробов
Опубликовано на XML.com (01.02.2006, англ.): http://www.xml.com/pub/a/2006/02/01/the-power-of-no.html
Опубликовано на xmlhack.ru (10.02.2006, рус.): http://xmlhack.ru/texts/06/the-power-of-no/the-power-of-no.html
В закладки:   Del.icio.us   reddit

Я помню, как однажды во время моей поездки в Тихуану мне приглянулся резной набор шахматных фигур. Я некоторое время глядел на него с восхищением, разглядывая причудливый узор прожилок на резном камне. Продавец уверял меня, что этот набор стоит огромные деньги, но так как в тот день он был в хорошем расположении духа, то согласился бы отдать набор всего за 100 долларов. Остальные участники той поездки уже вышли из магазина, и я направился к двери, чтобы присоединиться к ним. Тогда продавец закричал: «Стой! 80 долларов?» Скидка на двадцать долларов — это не так уж плохо, но мне всё равно уже было пора уходить из магазина. Ни слова не говоря, я продолжил идти к двери. Продавец кричал мне вслед: «60 долларов?» Я приостановился. «40 долларов?»

Каждый раз, когда обсуждаются досадные недостатки XML — а я участвовал в большем числе таких дискуссий, чем мне стоило бы, — центром обсуждения неизменно становится оплакивание отдельных деталей: «Зачем же они добавили в XML (название детали)?» — или даже в ещё более резкой форме. Но то, что больше всего досаждает как новичкам, так и профессионалам в области XML, — это, пожалуй, правило «Выиграй, отказавшись», которое я впервые вывел во время той поездки в Мексику. Может быть, это даже один из самых фундаментальных законов природы. Давайте займёмся этим правилом поподробнее, рассматривая его действие на примерах.

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

Каждый отдельный диалект XML тоже основан на правиле «Выиграй, отказавшись». Каждый такой диалект, создаваемый для некоторого узкого круга задач, сужает пространство всех возможных XML-документов до тех из них, которые отвечают определённому набору требований: на имена элементов и атрибутов, их взаимное расположение, используемые пространства имён и т.д. Более того, в правильно спроектированном диалекте XML будет ещё больше ограничений, нередко из числа тех, которым трудно дать простое название, — таких, как разделение интересов или разметка замысла.

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

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

Отказ применительно к естественным системам

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

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

Возьмём ещё один пример — типичный вступительный вопрос на собеседовании, навроде: «Что бы вы делали, если бы не были ограничены в деньгах?» Не стоит уноситься слишком далеко в мечтах о том, как вы их собираетесь тратить: даже если деньги неограничены, за жизнь можно успеть потратить только какое-то ограниченное их количество. Раз ограничено время, которое вам дано на использование этих денег, то нужно тщательно обдумывать уже не от чего отказываться, а когда отказываться.

Я мог бы приводить ещё примеры, такие как случай в Тихуане. Но достаточно сказать, что правило «Выиграй, отказавшись» проявляется практически всюду — нужно лишь приложить достаточно усилий, чтобы обнаружить его действие.

Чем больше выигрыш (от отказа), тем больше ответственность

Возвращаясь в мир веб-стандартов, вспомним о том, как создавалась спецификация XML: этот процесс во многом напоминал и естественный отбор, и управление ограниченными ресурсами, — в существовавший ранее стандарт вносились изменения с тем, чтобы удовлетворить изменившимся требованиям. На сайте W3C доступен исчерпывающе подробный документ, описывающий этот процесс разработки Рекомендаций и других технических отчётов. Главный принцип, лежащий в основе этого процесса, — это единогласие, описываемое в названном документе не менее подробно. Принцип единогласия эффективен потому, что у каждого из участников процесса есть возможность отказа, — так что предложения, поступающие в W3C, наверняка будут перед принятием улучшены настолько, насколько это только возможно.

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

В частности, Рабочие группы с большим числом участников иногда не могут поначалу уследить за целями и задачами проекта. Тогда группа распадается на подгруппки, каждая из которых преследует свои собственные цели и пытается «протолкнуть» те вещи, который кажутся ей наиболее важными. В результате технический отчёт оказывается составленным из многих совершенно различных предложений; если принятый таким образом стандарт и окажется в итоге популярным, то только под нажимом, оказываемым на скрежещущих зубами разработчиков со стороны политических сил.

Может случиться и противоположное — когда группа разработчиков излишне увлекается какой-то одной поставленной перед собой задачей и пренебрегает обязанностью представлять всю широту спектра интересов всех затрагиваемых создаваемым стандартом сторон. Такие группы часто имеют слишком узкое или слишком буквальное представление о вопросе, который они пытаются решить, — и в результате работы таких групп слово «стандарт» стало в определённых кругах чуть ли не оскорблением. Недостаточно обдуманный, «штампованный» стандарт раздражает куда сильнее, чем отсутствие стандарта вообще.

Как можете выиграть, отказавшись, конкретно вы

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

Не стоит и напоминать, что в центре любого большого проекта должен стоять один архитектор, который в идеале способен отделить свои собственные предпочтения и предубеждения от идей, допустимых в разработке продукта, — т.е. правильно поставить перед собой задачу. В качестве мерила способностей архитектора можно взять любую постороннюю группу, т.е. ту, которая не должна бы по идее заниматься этим проектом напрямую: способна ли эта группа понять и принять предложенную архитектуру. Иногда удовлетворить всех без исключения не удаётся; но даже тогда по степени принятия внешней группой можно оценивать уровень предложенного проекта (и его архитектора).

Если вы собираетесь разработать новый диалект XML — вспомните о правиле «Выиграй, отказавшись». Если же разработка нового диалекта вам жизненно необходима, то постарайтесь минимизировать его средневзвешенную неожиданность.

Наконец, если вы не в силах изменить какое-то досадное обстоятельство, то даже частичное понимание того, как оно возникло, может облегчить ваши страдания от столкновения с ним вновь и вновь.

Что же касается тех шахмат в Тихуане: в конце концов, я отказался.



XML.com Copyright © 1998-2007 O'Reilly Media, Inc.
Перевод: xmlhack.ru Copyright © 2000-2007 xmlhack.ru