Являются ли диски и файловые системы важным конструктивным элементом?

С точки зрения пользователя необходимость дисков ничем не обуслов' лена. С точки зрения инженера'электронщика есть три причины для использования дисков:

• диски дешевле твердотельной памяти;

• диски не теряют записанную на них информацию после выключе' ния питания;

• диски являются физическим средством переноса информации с од' ного компьютера на другой.

Являются ли диски и файловые системы важным конструктивным элементом? 415

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

Первая причина, стоимость, является действительным объяснением существования дисков. Энергонезависимая твердотельная память на' много дороже дисков.1 К сожалению, у жестких дисков множество не' достатков по сравнению с оперативной памятью. Они намного медлен' нее, чем твердотельные носители. Они еще и менее надежные, посколь' ку обладают движущимися частями. Они обычно потребляют больше электроэнергии и занимают больше пространства. Однако самая боль' шая проблема дисков такова: компьютер, а точнее его центральный процессор, не может напрямую читать информацию с диска или запи' сывать ее туда. Вспомогательные программы должны перенести ин' формацию в оперативную память, прежде чем процессор сможет что' либо делать с этой информацией. Когда процессор закончил работу, вспомогательные программы переносят данные обратно на диск. Таким образом, обработка с использованием дисков неизбежно на несколько порядков медленнее и сложнее, чем работа с одной лишь памятью.

 

Диски – технологический трюк, а не конструктивный эле- мент.

 

 

Плата за использование дисков, проявляющаяся в виде медленной ра' боты и повышенной сложности, настолько высока, что ничто, кроме их сравнительно ничтожной стоимости, не может заставить нас поль' зоваться ими. Диски не делают компьютеры лучше, мощнее, быстрее или проще в обращении. Наоборот: они делают компьютеры слабее, медленнее и сложнее. Диски – компромисс, так сказать, «ослабление» архитектуры компьютеров, основанной на твердотельной памяти. Ес' ли бы проектировщики компьютеров имели финансовую возможность использовать оперативную память вместо дисков, они бы сделали это без колебаний. Фактически они это уже делают в новейших моделях коммуникаторов и портативных компьютеров, в которых применяет' ся память Compact Flash и другие твердотельные технологии памяти.

1 Лавинообразный выход на рынок дешевых компактных ноутбуков с твер' дотельными дисками (так называемых нетбуков) свидетельствует о том, что эта разница перестала быть значимой. – Примеч. ред.

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

 

Время перемен

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

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

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

В 80'е годы компания Chrysler продемонстрировала покупателям эс' кизы автомобиля с принципиально новым дизайном – мини'вэна. Публика его единодушно отвергла. Будучи уверенной, что дизайн пре' восходен, компания не послушала пользователей и выпустила свой Caravan. И оказалась права: те же люди, которые поначалу отвергли дизайн, не только помогли этой модели стать одним из самых продава' емых мини'вэнов, но и сделали мини'вэн самым популярным автомо' бильным архетипом со времен появления кабриолета.

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

 

Улучшаем ввод данных

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

 

Целостность данных

И информационный иммунитет

Одно из наиболее важных требований к правильно работающему про' граммному обеспечению – чистота данных. Как гласит поговорка –

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

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

 

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

Проблема того подхода – потребности базы данных ставятся выше ин' тересов пользователя, который подвергается личному досмотру вся' кий раз, когда вводит очередную порцию данных. Заметим, что эта проблема нехарактерна для большинства персональных бизнес'прило' жений. Например, PowerPoint нисколько не заботится (и не имеет ни' какого представления) о том, правильно ли вы отформатировали свою презентацию. Но как только вы начинаете вести дела с большой кор' порацией – будь вы клерк, вводящий информацию в систему управле' ния проектом, или покупатель DVD в интернет'магазине, – вы сталки' ваетесь с таможенным контролем.

Люди, заполняющие по долгу службы множество форм, знают, что данные никогда не поступают к ним в чистом виде, как того требует программа. Такая информация зачастую неполна и иногда неверна. Порой в интересах клиента приходится ускорять обработку. Но, столк' нувшись с системой, жесткой в таких вопросах, клерк, ответственный за обработку информации, оказывается в тупике: он должен либо при' остановить выполнение работы, либо как'то обойти систему, чтобы выполнить порученное. Если бы программа признала наличие челове' ческого фактора и отразила это в своем интерфейсе, все бы только вы' играли.

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

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

Информационный иммунитет

Чтобы реализовать иммунитет к вводимым данным, мы должны обу' чить приложение «смотреть под ноги» и при необходимости просить

 

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

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

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

Да, если пользователь введет «фыва» вместо «9,38», программа не сможет выдать удовлетворительный результат. Однако немедленное прекращение обработки и поза «решите проблему прямо сейчас» – то' же не выход. Процесс ввода так же важен, как и конечный результат. Если пользовательский интерфейс спроектирован правильно, про' грамма обеспечит визуальную обратную связь, когда пользователь вводит «фыва», так что вероятность, что он введет сотню ошибочных записей, очень мала. Вообще говоря, пользователи начинают вести се' бя глупо именно в тех случаях, когда программы считают их глупыми.

Когда пользователь вводит неверные данные, эти данные часто близки к верным. Приложения следует проектировать таким образом, чтобы они как можно эффективнее помогали пользователю исправлять ошибки. Так, если пользователь случайно набрал «TZ» в качестве двухбуквенного обозначения штата, а далее набрал «Dallas» в качестве названия города, то не надо быть семи пядей во лбу, чтобы догадаться, о каком штате идет речь («TX» – сокращение наименования штата Те' хас), и скорректировать ввод.