О Windows из первых рук : Нельзя ли просто дружно работать?

С документом о совместимости систем связана определенная опасность: может оказаться, что никто не захочет реализовывать изложенные в нем спецификации.

Раймонд Чен

Несколько лет тому назад за ланчем я разговорился с сотрудниками из другой проектной группы в Microsoft. Это была незапланированная встреча, которая случилась из-за спонтанно принятого решения съесть ланч вместе с пришедшим в гости коллегой.

Подобные встречи за ланчем — замечательная вещь. Я узнаю о других людях и проектах, над которыми они трудятся. Если повезет, мне удается разжиться парой-тройкой новых историй.

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

Представитель Microsoft сказал, что члены группы разделились на два лагеря. Члены первого хотели, чтобы в документе были изложены все возможные запросы и предложены схемы для их описания. «Что если клиент захочет бульбулировать фробулятор, если поток демодулируется? Надо предусмотреть мероприятия на случай демодуляции».

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

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

И овцы целы, и волки сыты

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

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

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

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

В шутку я предложил добавить в расширенный документ следующий параграф: «Если будет получен пакет с запросов, обработка которого никогда не принесет результата (потому что если сервер попытается его выполнить, он станет недоступным для других клиентов), сервер должен отказать в запросе с ошибкой типа “Риск Зависания”». Иначе говоря, надо сделать так, чтобы в отраслевой группе поручили серверам решать проблему останова.

Мой собеседник улыбнулся: «Я бы с удовольствием это сделал». Не знаю, выполнил ли он свое обещание, но это уже неважно.

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

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

Раймонд Чен его веб-сайт и одноименная книга «Old New Thing», вышедшая в издательстве Addison-Wesley в 2007 году, рассказывает об истории Windows, программировании с использованием интерфейса Win32 и непреднамеренном воровстве из автомобилей.