Добавление нового флага для включения поведения, которое раньше было поведением по-умолчанию

Это перевод Adding a new flag to enable behavior that previously was on by default. Автор: Реймонд Чен.

Одно из предложений по решению сетевой проблемы заключалось в том, чтобы забросить "fast mode" и ввести новый "fast mode 2". Это полный эквивалент добавлению нового флага к возможностям сервера, который говорит "Я поддерживаю быстрый режим, я не бажный". Это ещё один пример изменения правил игры после её окончания, добавлением флага для обхода бага в драйвере.

Рассмотрим гипотетическую программу, которая использует быстрый режим на Windows XP. Она работает с сервером Windows Server 2003 и все счастливы. Предположим, что вы изменили Windows Vista, так что она требует, чтобы сервера указывали новый флаг "поддержка fast mode 2", если они поддерживают быстрый режим. Когда клиенты обновляют их клиентские машины с Windows XP на Windows Vista, они обнаруживают, что те стали работать существенно медленнее. Чья это вина? Явно не гипотетической программы, которая использовала быстрый режим на Windows XP; эта программа корректно использует быстрый режим. Не вина это и машины с Windows Server 2003; этот сервер поддерживает быстрый режим. Но тогда получается, что вина - на Windows Vista?

"Эй, не вини меня" - отвечает Vista, - "Это вон тот парень. Тот самый, о котором никто не слышал раньше. Он заставил меня это сделать. Вини его!"

Чтобы описать этот тип поведения, я, пожалуй, позаимствую фразу Альберта Эйнштейна: "Spooky action at a distance" (Эйнштейн использовал её, чтобы описать то, что в современной физике известно как квантовая запутанность). В данном конкретном случае, у нас есть разговор между двумя участниками (клиентское программное обеспечение и программное обеспечение сервера) посредством третьего (Windows), который (разговор) разрушается из-за просто существования четвертой стороны, которая даже не участвует в этом разговоре (бажный сервер - прим.пер.)! Это как если бы ваш проигрыватель компакт-дисков внезапно потерял способность играть все ваши музыкальные компакт-диски, только потому, что какая-то компания, о которой вы никогда раньше не слышали, на другом конце света наделала кучу плохих компакт-дисков за несколько месяцев до этого в этом году.

Некоторые люди предложили: "Почему бы не добавить флаг 'Я поддерживаю быстрый режим'?". Но такой флаг уже существует; в самом деле, именно из-за его наличия Windows Vista и пытается использовать быстрый режим для общения с сервером. Проблема не в том, что сервер не поддерживает быстрый режим. Проблема в том, что на сервере есть баг в реализации быстрого режима.

"Окей, тогда добавьте новый флаг, который говорит 'Мой быстрый режим - не бажный'". Посмотрите, к чему приведёт подобный подход в будущем:

При ответе на QUERY_CAPABILITIES серверу следует вернуть 32-битное значение, состоящее из нуля или нескольких следующих битов: 0x00000001 Этот сервер поддерживает быстрый режим 0x00000002 Этот сервер поддерживает быстрый режим и не имеет бага реализации, при котором перечисление содержимого каталога останавливается на 129-м запросе при 128 файлах 0x00000004 Этот сервер поддерживает быстрый режим и не имеет бага неверного формирования длинных имён файлов в ответах 0x00000008 Этот сервер поддерживает быстрый режим и не имеет бага, при котором каталоги с именем полностью из цифр ошибочно сообщались как файлы 0x00000010 Этот сервер поддерживает быстрый режим и не имеет бага сброса перечисления, если в каталоге создают файл, пока идёт перечисление 0x00000020 Этот сервер поддерживает быстрый режим и не имеет бага, когда FindNext возвращает ошибку, даже если в каталоге ещё остались файлы ...

Если для каждого обнаруженного бага мы создавали бы новый флаг, то маска возможностей сервера очень быстро бы заполнилась этими случайными битами для багов, которые (сегодня) уже много лет как исправлены. И каждый раз, когда находят новый баг в любом сервере, нужно обновить все сервера, чтобы добавить им в возвращаемые значения новый бит, который говорит: "Я не тот бажный сервер, который вы нашли 8-го апреля 2006-го", даже если сервер стоит запертый в чулане и его ОС прошита в EPROM (ПЗУ). Кроме того, если вы пишете свой новый сервер - какие биты вы станете устанавливать? Вы заявите, что у вас нет багов? Наверное, да. Что если, шесть месяцев спустя, кто-то найдёт баг в вашем сервере ровно этого же типа (того, которого, как вы заявили, у вас нет)? Я думаю, что это означает, что в следующей редакции протокола нам придётся добавить новый флаг:

0x00000020 Этот сервер поддерживает быстрый режим и не имеет бага, при котором сервер заявляет, что у него нет бага, при котором FindNext возвращает ошибку, даже если в каталоге ещё остались файлы, но, на самом деле, на сервере есть этот баг, но только более неявный

Или, быть может, вы вообще железно убеждены, что у вас нет и не будет багов в вашей реализации быстрого режима. Вернёте ли вы 0xFFFFFFFF, чтобы сказать: "У меня вообще нет багов, даже тех, которые обнаружат в будущем в других серверах"? Что произойдёт, когда мы найдём 33-й баг? Надо ли нам добавлять функцию QUERY_CAPABILITIES2? Если создавать битовый флаг на каждый баг, когда-либо существовавший в реализации сетевого протокола, то у вас будет несколько тысяч бит, все из которых просто говорят "у меня нет бага, при котором...".

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