Читать онлайн «Человеческий фактор в программировании». Страница 86

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

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

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

После этого легко вычислить значение параметра визуального сцепления. Необходимо только рассмотреть каждую пару визуальных компонентов в каждой визуальной группе и подсчитать количество пар, в которых оба визуальных компонента связаны с одной и той же смысловой группой. Визуальное сцепление — это просто количество пар, в которых оба объекта связаны с одной смысловой группой. Обычно это количество выражается в процентах от всего количества возможных пар. Вычисление можно продолжить рекурсивно, чтобы учесть группы групп и оценить визуальное сцепление пользовательского интерфейса в желаемом масштабе (Constantine, 1996 [27]).

Теоретически критерий визуального сцепления может показаться превосходным, но вряд ли можно сказать, что на практике он является самоочевидным. К счастью, тема визуального сцепления была хорошо изучена. В одном из исследований (Constantine, 1996 [27]) были старательно сконструированы три различные версии квазистандартного диалогового окна печати. Все три версии имели реалистичный (с виду) дизайн и содержали одинаковое количество визуальных компонентов и визуальных групп. Все они были скомпонованы в соответствии с одинаковыми эстетическими принципами. Различалась только степень визуального сцепления. Один из проектов, так называемая «структурированная» версия, был высокоорганизованным, а его показатель визуального сцепления составлял 62 %. Другой проект, похожий на обычное диалоговое окно печати Windows, имел промежуточный показатель визуального сцепления, равный 42 %. Наибольшую сложность представлял внешне правдоподобный, но концептуально хаотичный вариант дизайна. Показатель визуального сцепления этой «беспорядочной» версии составлял 29 % несмотря на ее разумный внешний вид.

Для оценки проектов привлекались профессиональные разработчики и дизайнеры интерфейсов из Соединенных Штатов и Австралии. Каждый вариант дизайна рассматривался по различным сценариям задач. Критериями служили легкость понимания, изучения и применения. Если не говорить об одном или двух ляпах, которые случаются в любых реальных проектах, результаты во многом соответствовали ожидаемым. Варианты дизайна с большим значением показателя визуального сцепления были признаны более простыми в понимании, изучении и практическом применении. Такими они и были на самом деле.

Дело всего лишь в том, что хорошая визуальная организация имеет значение.

По материалам журнала Object Magazine, март 1997 г.

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

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

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

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

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