Ларри Константин - Человеческий фактор в программировании

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

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

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

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

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

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

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

Из журнала Object Magazine, декабрь, 1997 г.

Помню, как я писал свою первую программу. Это было упражнение по Фортрану в рамках курса, известного под названием 6.41. В те дни в Мас-сачусетском технологическом институте все шло под своими номерами, в том числе и моя программа. Написать ее не составило труда — она всего лишь не скомпилировалась с первого раза. Или со второго. Я был подавлен и опустошен. Когда мне все-таки удалось ее скомпилировать, я был просто шокирован тем, что она не работала. Я не мог понять, почему — мне казалось, что все написано правильно. Я показал ее своему соседу по комнате. Маршалл специализировался на математике. Я думаю, что он начал писать алгоритмы еще до появления компьютеров, на которых их можно было применять.

«Никак не могу понять, где ошибка в этой программе. Посмотри, может быть, это…» Он хватал распечатки, которые мы с любовью называли листингами 80–80 (те, кто помнят, что такое перфокарты, меня поймут).

«А это что?» — спрашивал Маршалл, тыча своим корявым бруклинским пальцем.

«Похоже, что С.»

«Здесь это не нужно.» И он был прав. Этот оператор компилировался, однако компьютер прочитывал его не так, как я предполагал. Маршалл возвращался к чему-то, связанному с градиентами и операторами Гамильтона, и оттачивал свою интерпретацию песни Марлона Брандо (Marlon Brando) из «А Streetcar Named Desire». Из всего этого я уяснил, что Маршаллу никогда нельзя показывать то, что я написал, особенно если это код. Он всегда найдет в нем что-нибудь неправильное, а мне придется на-ходить в себе силы, чтобы отнестись к этому, как к одолжению. Кроме того, это неизменно вызывало у него очередной приступ музыкального мычания: «Стелла! Стелла!». Скоро начало занятий, а я все еще не был готов. Конечно, со временем я понял, что обсуждение проблемы с приятелем-программистом часто оказывается самым эффективным способом обнаружения какого-нибудь незаметного бага или составления какого-нибудь мудреного алгоритма. На самом деле многие из нас знают, что изложение своих идей коллеге, играющему роль «звукового экрана», или выяснение его мнения по поводу чего-то неясного может быть не только полезной и ценной процедурой для конечного продукта, но и веселым занятием, помогающим построить хорошие рабочие отношения.