О Windows из первых рук: Важность причин чересчур преувеличена

Если вы обнаружили в продукте нечто загадочное, подумайте, как поступить более рационально.

Раймонд Чен

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

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

Как логически объяснить, что разработчики решили проверять имя пользователя перед именем файла? Скорее всего, никак. Просто так сложились обстоятельства при написании кода. Проверки запросто могли бы идти в обратном порядке.

Мы периодически получаем запросы от клиентов, сталкивающихся с поведением такого рода. Если что-то их не устраивает или сбивает с толку, они задают вопрос: «В чем причина такого поведения?»

Как программисты, мы с вами понимаем, что особенности работы могут объясняться какими угодно причинами. Возможно, это дефект кода. Возможно, это упущение при проектировании. Возможно, группа разработчиков собиралась сделать нечто иное, но не сделала из-за недостатка времени или ресурсов или по соображениям управления рисками и приоритетами. Также возможно, что это осознанное решение. И только в последнем случае поведение программы будет иметь какое-то логическое обоснование.

Что сделано, то сделано

После приобретения продукта поиск причины или логического обоснования, по большому счету, не имеет смысла. Продукт работает так, как он работает. Вы можете затребовать изменения в будущих версиях, но текущая версия — это нечто завершенное. Объяснение, почему продукт работает таким образом (даже если оно существует) не изменит ни продукт, ни его поведение. Оно может разве что успокоить или, наоборот, разозлить вас. Вы получите ответ на вопрос, но не решите проблему.

Во многих случаях клиент, спрашивающий: «В чем причина такого поведения?», — имеет в виду кое-что еще. Чаще всего он подразумевает: «Я столкнулся с поведением, которое не ожидал и которое мне не нравится».

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

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

Почему информация на мониторе показывается от левого верхнего угла? Почему нельзя писать \\сервер\..\другой_сервер\каталог? На самом деле, не важно, каким будет ответ — исчерпывающим объяснением или чем-то наподобие «потому что я не выспался». Ваша проблема все равно никуда не уйдет.

Как реагировать на проблему

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

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

Гораздо честнее и полезнее рассказать об обнаруженной проблеме и сценарии, при выполнении которого она возникла. Тогда ваш запрос изменений программы будет более понятным. С другой стороны, требование рассказать, о чем думали, реализуя такое поведение, могут воспринять как придирку, на которую, возможно, даже не стоит отвечать.

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