Программист-прагматик

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

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

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

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

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

Мы полагаем, что единственно надежным способом разработки программ и облегчения их понимания и сопровождения является следование принципу «Не повторяй самого себя» (Далее DRY = Don't Repeat Yourself. – Прим. пер.):

КАЖДЫЙ ФРАГМЕНТ ЗНАНИЯ ДОЛЖЕН ИМЕТЬ ЕДИНСТВЕННОЕ, ОДНОЗНАЧНОЕ, НАДЕЖНОЕ ПРЕДСТАВЛЕНИЕ В СИСТЕМЕ.

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

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

В этом разделе мы обрисуем проблемы, связанные с дублированием, и предложим общие стратегии по тому, как с ним справиться.

Как возникает дублирование?

Большинство наблюдаемых явлений дублирования подпадают под одну из следующих категорий:

• Навязанное дублирование. Разработчики чувствуют, что у них нет выбора – им кажется, что дублирования требует среда окружения.

• Неумышленное дублирование. Разработчики не осознают, что они тиражируют информацию.

• Нетерпеливое дублирование. Разработчики ленятся и осуществляют дублирование, потому что им кажется, что так проще.

• Коллективное дублирование. Фрагмент информации тиражируются несколькими членами одной команды разработчиков (или нескольких команд)

Рассмотрим эти четыре категории дублирования более подробно.

Навязанное дублирование

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

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

Немного изобретательности – и дублирование вам не понадобится. Зачастую ответ сводится к написанию простого фильтра или генератора текста программы. Конструкции с использованием нескольких языков можно собрать из обычного представления метаданных, применяя простой генератор текста программ всякий раз при осуществлении сборки программы (пример этого показан на рисунке 3.4). Определения класса могут быть сгенерированы автоматически из интерактивной схемы базы данных или из метаданных, используемых для построения схемы изначально. Фрагменты программ в этой книге вставлялись препроцессором всякий раз при форматировании текста. Уловка состоит в том, чтобы сделать процесс активным: это не может быть однократным преобразованием, в противном случае мы опять окажемся в положении людей, тиражирующих данные.

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

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

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

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

Языковые аспекты. Многие языки навязывают значительное дублирование в исходном тексте программы. Зачастую это происходит, когда язык отделяет интерфейс модуля от его реализации. Языки С и С++ используют файлы заголовка, которые тиражируют имена и печатают информацию о переменных экспорта, функциях и классах (для С++). Язык Object Pascal даже тиражирует эту информацию в том же самом файле. Если вы используете удаленные вызовы процедур или технологию CORBA[URL 29], то при этом происходит дублирование интерфейсной информации в спецификации интерфейса и тексте программы, его реализующей.

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

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

Неумышленное дублирование

Иногда дублирование происходит в результате ошибок в проекте.

Рассмотрим пример из области транспорта. Пусть аналитик установил, что, наряду с прочими атрибутами, грузовик имеет тип, номерной знак и водителя. Аналогично, маршрут доставки груза представляет собой сочетание маршрута, грузовика и водителя. Мы создаем программы для некоторых классов, основанных на этом представлении.

Но что происходит, если водитель по имени Салли заболевает и приходится менять водителя? Классы Truck и DeliveryRoute содержат описание водителя. Какой из них мы должны изменить? Ясно, что это дублирование неудачно. Нормализуйте его в соответствии с базовой бизнес-моделью – необходим грузовику водитель как часть базового набора атрибутов? А маршрут? Возможно, необходим третий объект, который связывает воедино водителя, грузовик и маршрут. Каким бы ни было окончательное решение, стоит избегать этого типа ненормализованных данных.

Есть не столь очевидный тип ненормализованных данных, который имеет место при наличии множественных взаимозависимых элементов данных. Рассмотрим класс, представляющий отрезок:

class Line {

public:

Point start;

Point end;

double length:

};

На первый взгляд, этот класс может показаться разумным. Отрезок явно имеет начало и конец и всегда будет иметь длину (даже если она нулевая). Но происходит дублирование. Длина определяется начальной и конечной точками: при изменении одной из точек длина меняется. Лучше сделать длину вычисляемым полем:

class Line {

public:

Point start;

Point end;

double length() {return start.distanceTo(end);}

};

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

class Line {

private:

bool changed;

double length;

Point start;

Point end;

public:

void setStart(Point p) {start = p; changed = true;}

void setEnd(Point p) {end = p; changed = true;}

Point getStart(void) {return start;}

Point getEnd(void) {return end;}

double getLength() {

if (changed) {

length = start.distanceTo(end);

changed = false;

}

return length;

}

};

Этот пример также иллюстрирует важный аспект для объектно-ориентированных языков типа Java и С++. Там, где это возможно, всегда используются функции средства доступа – для чтения и записи атрибутов объектов [6]. Это облегчает добавление функциональных возможностей (типа кэширования) в будущем.

Нетерпеливое дублирование

Каждый проект испытывает давление времени – силы, которая может двигать лучшими из нас, заставляя идти напролом. Вам нужна подпрограмма, подобная уже написанной вами? Вас соблазнит возможность копирования и внесения лишь нескольких изменений? Вам нужно значение, чтобы представить максимальное число точек? Если я изменю файл заголовка, целый проект должен быть перестроен. Может, мне просто использовать константы в этом месте?… и в этом… и в том… Нужен класс, подобный тому, который есть в системе поддержки Java? У вас в распоряжении имеется исходный текст, так почему бы просто его не скопировать и не внести необходимые изменения (несмотря на лицензионное соглашение)?

Если вы чувствуете, что поддаетесь искушению, вспомните банальный афоризм: «Тише едешь – дальше будешь». Экономя несколько секунд в данный момент, вы потенциально теряете целые часы. Подумайте об аспектах, относящихся к «проблеме 2000 года». Многие из них были вызваны ленью разработчиков, которые не сделали параметризацию размера полей даты (или не внедрили централизованные библиотеки служб доступа к дате).

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

Коллективное дублирование

Самый трудный в обнаружении и обработке тип дублирования – коллективный – возникает между различными разработчиками проекта. Целые наборы функциональных возможностей могут тиражироваться по неосторожности, и это дублирование может оставаться незамеченным на протяжении многих лет, что приводит к возникновению проблем при сопровождении. Нам известно, как в одном из штатов США компьютерные системы, установленные в правительственных учреждениях, проверялись на наличие «проблемы 2000 года». Аудиторы обнаружили свыше 10000 программ, каждая из которых по-своему осуществляла проверку правильности номера карточки социального страхования.

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

Мы полагаем, что лучший способ справиться с этим – поощрять активное и частое взаимодействие между разработчиками. Устраивайте форумы для обсуждения общих проблем. (При работе над предыдущими проектами мы организовывали конференции в сети, чтобы позволить разработчикам обмениваться идеями и задавать вопросы. Этим обеспечивается ненавязчивый способ общения – даже на нескольких сайтах – при сохранении непрерывной хронологии всего высказанного). Назначьте одного из членов команды библиотекарем проекта, чьей обязанностью будет обеспечение обмена знаниями. Организуйте специальное место в каталоге с исходными текстами, в котором будут сохраняться сервисные подпрограммы и скрипты. Обратите особое внимание на чтение исходного текста и документации других членов команды, неформально или при анализе текста программы. При этом вы отнюдь не шпионите за ними – вы учитесь у них. И помните, что доступ к тексту программы осуществляется по взаимной договоренности – вас не должно коробить, если и другие члены команды сосредоточенно изучают (или вынюхивают?) ваш текст программы.

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

• Ортогональность

• Работа с текстом

• Генераторы исходных текстов

• Реорганизация

• Команды прагматиков

• Вездесущая автоматизация

• Все эти сочинения

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

Что такое ортогональность?

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

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

Перед тем как рассмотреть преимущества ортогональных систем, познакомимся с неортогональной системой.

Предположим, вы находитесь в экскурсионном вертолете, совершающем полет над Гранд-Каньоном, когда пилот, который совершил ошибку, наевшись рыбы за обедом, внезапно вскрикивает и теряет сознание. По счастливой случайности это происходит, когда вы парите на высоте 30 метров. Вы догадываетесь, что рычаг управления общим шагом несущего винта [7] обеспечивает подъем машины, так что, если его слегка опустить, вертолет начнет плавно снижаться. Однако когда вы пытаетесь сделать это, то осознаете, что жизнь – не такая уж простая штука. Вертолет клюет носом, и вас начинает вращать по спирали влево. Внезапно вы понимаете, что управляете системой, в которой каждое воздействие имеет побочные эффекты. При нажатии на левый рычаг вам придется сделать уравновешивающее движение назад правым рычагом и нажать на правую педаль. Но при этом каждое из этих действий вновь повлияет на все органы управления. Неожиданно вам приходится жонглировать невероятно сложной системой, в которой любое изменение влияет на все остальные управляющие воздействия. Вы испытываете феноменальную нагрузку: ваши руки и ноги находятся в постоянном движении, пытаясь уравновесить все взаимодействующие силы.

Органы управления вертолетом определенно не являются ортогональными.

Преимущества ортогональности

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

Мы хотим спроектировать компоненты, которые являются самодостаточными: независимыми, с единственным, четким назначением; в книге Йордона и Константина [YC86] это явление называется сцеплением (cohesion). Когда компоненты изолированы друг от друга, вы уверены, что можно изменить один из них. не заботясь об остальных. Пока внешние интерфейсы этого компонента остаются неизменными, вы можете быть спокойны, что не создадите проблем, которые распространятся по всей системе.

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

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

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

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

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

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

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

• Ортогональная система способствует повышению качества тестирования, поскольку облегчается проектирование и тестирование отдельных ее компонентов.

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

Рассмотрим некоторые из способов, при помощи которых вы сможете внедрить принцип ортогональности в вашу работу.

Проектные группы

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

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

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

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

Проектирование

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

Рис. 2.1. Типичная диаграмма иерархической структуры

Существует простой тест на ортогональность проектирования. Как только вы составили схему компонентов, спросите себя: «Сколько модулей подвергнутся воздействию, если я резко изменю требования по конкретной функции?» В ортогональной системе ответ должен быть «один» [8]. Перемещение кнопки на панели графического интерфейса пользователя не должно требовать внесения изменений в схему базы данных. Добавление контекстно-зависимой справки не должно изменить подсистему выставления счетов.

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

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

Инструментарии и библиотеки

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

Однажды авторы работали над проектом, в котором требовалось, чтобы некий фрагмент программы на языке Java выполнялся автономно – на сервере и в удаленном режиме – на клиентской машине. В этом случае возможными вариантами распределения классов были технологии RMI и CORBA. Если удаленный доступ к классу обеспечивался при помощи RMI, то в этом случае каждое обращение к удаленному методу в этом классе могло бы привести к генерации исключения, означающей, что эта наивная реализация потребовала бы от нас обработки этого исключения всякий раз при использовании удаленных классов. В данном случае использование RMI явно не ортогонально: программа, обращающаяся к удаленным классам, не должна зависеть от их физического расположения. Альтернативный способ – технология CORBA – не налагает подобного ограничения: мы можем написать программу, для которой не имеет значения, где физически находятся классы.

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

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

Другой интересной проверкой на ортогональность является технология Aspect-Oriented Programming (АОР) – исследовательский проект фирмы Xerox Pare ([KLM+97] и [URL 49]). Технология АОР позволяет выразить в одном-единственном месте линию поведения, которая в противном случае была бы распределена по всему исходному тексту программы. Например, журнальные сообщения обычно генерируются путем явных обращений к некоторой функции записи в журнал по всему исходному тексту. Используя технологию АОР, вы реализуете процедуру записи в журнал ортогонально к записываемым данным. Используя версию АОР для языка Java можно записать сообщение журнала при входе в любой метод класса Fred, запрограммировав аспект:

aspect Trace {

advise * Fred.*(…) {

static before {

Log.write("-» Entering « + thisJoinPoint.methodName);

}

}

}

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

Написание текста программы

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

Есть ряд методик, которые можно использовать для поддержки ортогональности:

• Сохраните вашу программу «несвязанной». Напишите «скромную» программу – модули, которые не раскрывают ничего лишнего для других модулей и не полагаются на их внедрение. Попробуйте применить закон Деметера [LH89], который обсуждается в разделе «Несвязанность и закон Деметера». При необходимости изменения состояния объекта это должен делать сам объект. В таком случае программа остается изолированной от реализации другой программы, а вероятность того, что система останется ортогональной, увеличивается.

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

Шаблон Singleton, упомянутый в книге «Design Patterns» [GHJV95], представляет собой способ подтвердить существование единственного представителя объекта определенного класса. Многие используют эти объекты типа Singleton как своего рода глобальную переменную (особенно при работе с языками типа Java, которые иначе не поддерживают технологию глобальных переменных). Будьте внимательны с шаблонами Singleton – они также могут приводить к ненужному связыванию.

• Подобные функции. Зачастую вы сталкиваетесь с набором функций, похожих друг на друга; возможно, они используют общий фрагмент в начале и конце программы, но в ее середине каждая пользуется своим алгоритмом. Дублированная программа является признаком структурных проблем. Для того чтобы составить программу лучше, следует обратить внимание на шаблон Strategy в книге «Design Patterns».

Пусть постоянное критическое отношение к вашей программе войдет у вас в привычку. Ищите любые возможности реорганизации для усовершенствования ее конструкции и повышения уровня ортогональности. Этот процесс называется реорганизацией, и он важен настолько, что в книге ему посвящен целый раздел (см. «Реорганизация»).

Тестирование

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

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

Момент устранения ошибки также подходит для оценки ортогональности системы в целом. Когда вы сталкиваетесь с проблемой, оцените, насколько локален процесс ее устранения. Нужно изменить лишь один модуль, или изменения должны происходить по всей системе? Когда вы меняете что-либо, устраняются ли при этом все ошибки или происходит загадочное появление новых? Это удачный момент для внедрения автоматизации. Если вы применяете систему управления исходным текстом (что вы будете делать, прочитав раздел «Средства управления исходным текстом»), комментируйте устранение ошибок, когда вы осуществляете возвращение измененного модуля в библиотеку после тестирования. Затем вы можете генерировать ежемесячные отчеты, где анализируются тенденции в ряде исходных файлов, в которых производилось устранение ошибок.

Документация

Что удивительно, ортогональность применима и к документации. Координатами являются содержание и представление. Если документация действительно ортогональна, вы можете существенно изменить внешний вид, не изменяя содержания. Современные текстовые процессоры содержат стили и макрокоманды, которые помогают в этом (см. «Все эти сочинения»).

Жизнь в условиях ортогональности

Ортогональность тесно связана с принципом DRY («Не повторяй самого себя»). Используя этот принцип, можно свести к минимуму дублирование в пределах системы, а при помощи ортогональности уменьшить взаимозависимость между компонентами системы. Звучит неуклюже, но если вы используете принцип ортогональности в тесной связи с принципом DRY, вы обнаружите, что разрабатываемые вами системы становятся более гибкими, более понятными и более простыми в отладке, тестировании и сопровождении.

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

• Пороки дублирования

• Средства управления исходным текстом

• Проектирование по контракту

• Несвязанность и закон Деметера

• Метапрограммирование

• Всего лишь представление

• Реорганизация

• Программа, которую легко тестировать

• Злые волшебники

• Команды прагматиков

• Все эти сочинения

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

• Язык С++ поддерживает множественное наследование, а язык Java позволяет классу реализовывать множественные интерфейсы. Как влияет на ортогональность использование этих средств? Есть ли различие в воздействии, которое оказывается в ходе использования множественного наследования и множественных интерфейсов? Есть ли разница в применении делегирования и наследования?

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

class Split 1 {

public Splitl(InputStreamReader rdr) {…

public void readNextLine() throws IOException {…

public int numFields() {…

public String getField(int fieldNo) {…

}

class Split2 {

public Split2(String line) {…

public int numFields() {…

public String getField(int fieldNo) {…

}

2. Какая конструкция обладает большей ортогональностью: немодальные или модальные диалоговые окна? (Ответ см. в Приложении В.)

3. Сравним процедурные языки и объектно-ориентированные технологии. Что дает более ортогональную систему? (Ответ см. в Приложении В.)

Технические специалисты предпочитают простые и однозначные решения задач. Математические тесты, позволяющие с большой уверенностью сказать, что х = 2, намного лучше, чем нечеткие, но страстные очерки о миллионах причин Французской революции. К техническим специалистам присоединяются и менеджеры: однозначные и несложные ответы хорошо вписываются в электронные таблицы и проектные планы.

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

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

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

К тому времени, когда многие важные решения уже приняты, цель уменьшится настолько, что, если она двинется с места или ветер изменит направление, или же бабочка в Токио взмахнет своими крылышками, вы промахнетесь [9]. И здорово промахнетесь.

Проблема состоит в том, что непросто дать задний ход важным решениям.

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

Многие из тем, затронутых в данной книге, нацелены на создание гибкого, легко адаптируемого программного обеспечения. Следуя их рекомендациям – в особенности принципу DRY, принципу несвязанности и использованию метаданных (см. ниже), нет нужды в принятии многих важных необратимых решений. Это и хорошо, поскольку вначале мы не всегда принимаем наилучшие решения. Мы придерживаемся некоторой технологии лишь для того, чтобы в один прекрасный день обнаружить, что не в состоянии нанять достаточное количество людей, обладающих необходимыми навыками. Стоит нам остановить свой выбор на некоторой фирме-субподрядчике, как ее сразу перекупают конкуренты. Требования, пользователи и аппаратные средства изменяются быстрее, чем мы разрабатываем программное обеспечение.

Предположим, что в начале проекта вы решили использовать реляционную базу данных, производимую фирмой А. Позже, во время нагрузочного тестирования, вы обнаруживаете, что база данных слишком медленная, а объектная база данных фирмы В работает быстрее. В большинстве случаев, вам не везет. Большую часть времени обращения к программам фирм-субподрядчиков запутываются в тексте программ. Но если вы действительно вычленили идею базы, поместив ее снаружи – в точку, где она просто обеспечивает сохранение состояния объектов (как служба), тогда вы обладаете достаточной гибкостью, чтобы менять коней на переправе.

Предположим, что проект начинается по модели «клиент-сервер», но затем, когда карты уже сданы, отдел маркетинга решает, что для некоторых заказчиков серверы слишком дороги и они хотят сделать автономную версию. Насколько сложным будет для вас этот переход? Поскольку речь идет о развертывании, для этого потребуется минимум несколько дней. Если бы времени требовалось больше, вы бы и не думали об обратимости. Обратная задача еще интереснее. Что будет, если возникнет необходимость в развертывании автономной версии разрабатываемого вами проекта по схеме «клиент-сервер» или по n-звенной модели? Это также не должно представлять затруднений.

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

Гибкая архитектура

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

Технологии, подобные CORBA, могут помочь в защите компонентов проекта от изменений, происходящих в языке, на котором ведется разработка, или в платформе. Вдруг производительность Java на этой платформе не соответствует ожиданиям? Еще раз напишите программу клиента на языке С++, и больше ничего менять не нужно. Подсистема правил в С++ не отличается достаточной гибкостью? Перейдите к версии на языке Smalltalk. При работе с архитектурой CORBA вы должны обращать внимание только на заменяемый компонент, другие компоненты трогать не нужно.

Вы разрабатываете программы для Unix? Какой версии? Вы рассмотрели все из аспектов переносимости? Вы пишете для конкретной версии Windows? Какой – 3.1, 95, 98, NT, СЕ или же 2000? Насколько сложно будет обеспечить поддержку других версий? Если ваши решения характеризуются мягкостью и пластичностью, то это будет совсем несложно. Но это будет невозможно, если пакет неудачно сформирован, есть высокий уровень связанности, а в тексты программ встроена логика или параметры.

Вы не знаете точно, как отдел маркетинга собирается развертывать систему? Подумайте об этом заранее, и вы сможете обеспечить поддержку автономной модели, модели «клиент – сервер» или n-звенной модели только за счет изменений в файле конфигурации. Мы создавали программы, которые действуют подобным образом.

Обычно вы можете просто скрыть продукт фирмы-субподрядчика за четким, абстрактным интерфейсом. На самом деле мы могли это сделать с любым проектом, над которым мы работали. Но предположим, что вы не смогли изолировать его достаточно четко. Вам пришлось раскидать некоторые инструкции по всей программе? Поместите это требование в метаданные и воспользуйтесь автоматическим механизмом, наподобие Aspect (см. «Инструментарии и библиотеки») или Perl для вставки необходимых инструкций в саму программу. Какой бы механизм вы ни использовали, сделайте его обратимым. Если что-то добавляется автоматически, то оно может и удаляться автоматически.

Никто не знает, что может произойти в будущем, в особенности мы! Дайте вашей программе работать в ритме рок-н-ролла: когда можно – качаться, а когда нужно – энергично крутиться.

• Несвязанность и закон Деметера

• Метапрограммирование

• Всего лишь представление

• Немного квантовой механики – пример с кошкой Шрёдингера. Предположим, что в закрытом ящике сидит кошка, и в нем же находится радиоактивная частица. Вероятность распада частицы на две равна 50 %. Если распад произойдет, кошка умрет. Если не произойдет, кошка останется жива. Итак, умирает кошка или остается жива? Согласно Шрёдингеру, верно и то, и другое. Всякий раз, когда происходит ядерная реакция, у которой имеются два возможных результата, происходит клонирование мира. В одном из двух миров данное событие произошло, а в другом – нет. Кошка жива в одном из миров и мертва в другом. Лишь открыв ящик, вы осознаете, в каком из миров находитесь вы.

Не удивительно, что программировать на перспективу так трудно.

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

Хватит ли у вас смелости открыть ящик?

Существует два способа стрельбы из пулемета в темное время суток [10]. Вы можете выяснить точно, где находится ваша цель (расстояние, высота и азимут). Вы можете определить погодные условия (температура, влажность, давление, направление ветра и так далее). Вы можете точно определить характеристики используемых вами патронов и пуль и их взаимодействие с реальным пулеметом, из которого вы стреляете. Затем вы можете воспользоваться таблицами или компьютером для вычисления точного азимута и угла возвышения ствола пулемета. Если все работает в точном соответствии с характеристиками, таблицы корректны, а погодные условия не меняются, то пули должны лечь близко к цели. Можно также использовать трассирующие пули.

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

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

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

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

Однако программисты-прагматики предпочитают стрелять трассирующими.

Программа, которую видно в темноте

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

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

Однажды мы работали над сложным маркетинговым проектом с базой данных «клиент-сервер». Частью требований была способность определять и выполнять промежуточные запросы. Серверами являлся ряд реляционных и специализированных баз данных. Клиентский графический интерфейс пользователя, написанный на языке Object Pascal, использовал набор библиотек С для обеспечения интерфейса с серверами. Запрос пользователя хранился на сервере с использованием системы обозначений, подобной Lisp, до момента преобразования в оптимизированный SQL-запрос, предшествующего его выполнению. При этом возникло много неизвестных и много различных сред, и никто не знал наверняка, как же поведет себя графический интерфейс пользователя.

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

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

Разработка программ трассировки находится в согласии с той идеей, что проект никогда не кончается: всегда будет потребность в изменениях и добавлении функций. Это – инкрементальный подход.

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

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

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

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

• У вас есть что продемонстрировать. Спонсоры проекта и руководство стремятся увидеть демонстрационные версии в самое неподходящее время. При наличии программы трассировки у вас всегда будет то, что можно им продемонстрировать.

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

При стрельбе трассирующими вы не всегда попадаете в цель

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

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

Программа трассировки и создание прототипов

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

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

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

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

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

• Приемлемые программы

• Прототипы и памятные записки

• Западня спецификации

• Большие надежды

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

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

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

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

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

Для чего создаются прототипы

Какие объекты можно изучать при помощи прототипов? Все, что характеризуются наличием риска. Все, что не подвергались тестированию ранее или являются абсолютно критичными для конечного варианта системы. Вес, что является недоказанным, экспериментальным или сомнительным. Вес то, с чем вы еще не освоились. Вы можете создавать прототипы:

• Архитектуры

• Новой функциональной возможности уже существующей системы

• Структуры или содержания внешних данных

• Инструментальных средств или компонентов, выпущенных фирмами-субподрядчиками

• Рабочих характеристик

• Дизайна интерфейса пользователя

Создание прототипов способствует приобретению опыта. Значение этого опыта заключается не в созданной программе, а в полученных уроках. В этом и состоит смысл создания прототипов.

Как использовать прототипы

Какими деталями можно пренебречь при построении прототипа?

• Корректность. Там, где это приемлемо, вы сможете использовать фиктивные данные.

• Завершенность. Прототип может функционировать лишь в ограниченном смысле, возможно, лишь с одним наперед заданным фрагментом входных данных и одним пунктом меню.

• Надежность. Процедура проверки ошибок, вероятно, будет неполной или будет отсутствовать полностью. Если вы отклоняетесь от определенного пути, то прототип может выйти из строя и сгореть, как ракета. Это нормально.

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

Поскольку в прототипе детали отодвигаются на второй план, а в центре рассмотрения оказываются определенные аспекты системы, вам может показаться реальным создание прототипов с использованием языка очень высокого уровня – выше уровня языка остальной части проекта (язык типа Perl, Python или Tel). Язык сценариев высокого уровня позволяет опускать многие детали (включая указание типов данных) и при этом создавать функциональный (хотя и неполный и медленный) фрагмент программы [11]. Если вам необходимо создать прототип интерфейсов пользователей, изучите инструментальные средства типа Tcl/Tk, Visual Basic, Powerbuilder или Delphi.

Языки сценариев хороши для использования в качестве «клея» при соединении низкоуровневых фрагментов в новые сочетания. При работе в системе Windows язык Visual Basic может «скреплять» средства управления СОМ. В более общем смысле вы можете использовать языки типа Perl и Python для связывания воедино низкоуровневых библиотек языка С – вручную или автоматически при помощи инструментов наподобие бесплатного SWIG [URL 28]. Используя этот подход, вы можете быстро собрать существующие компоненты в новые конфигурации, чтобы посмотреть, как они работают.

Создание прототипов архитектуры

Многие прототипы создаются, чтобы смоделировать рассматриваемую систему в целом. В отличие от подхода типа «стрельба трассирующими», ни один из отдельных модулей в прототипе системы не должен быть особенно функциональным. На самом деле вам даже не нужно писать программу для создания прототипов – вы можете создать прототип на лекционной доске, при помощи памятных записок или каталожных карточек. Вы пытаетесь понять то, как система выглядит в собранном виде, опуская детали. Вот некоторые из конкретных областей, которые вы можете обнаружить в архитектурном прототипе:

• Четко ли определены обязанности основных компонентов, и являются ли они приемлемыми?

• Четко ли определена совместная работа основных компонентов?

• Сведено ли к минимуму связывание?

• Можно ли идентифицировать потенциальные источники дублирования?

• Можно ли применить определения интерфейсов и ограничения?

• Обладает ли каждый из модулей путем доступа к данным, требуемым ему в ходе выполнения? Может ли он получить такой доступ в случае необходимости?

Последний пункт приносит большинство сюрпризов и наиболее ценных результатов, основанных на опыте создания прототипов.

Как не надо использовать прототипы

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

Легко впасть в заблуждение из-за очевидной завершенности демонстрационного прототипа, и спонсоры проекта или менеджмент могут настаивать на развертывании прототипа (или его потомства), если вы заранее не определите, что можно ожидать от прототипа. Напомните им, что вы, конечно, можете создать великолепный прототип новой модели автомобиля из бальзовой древесины и клейкой ленты, но вы же не поедете на нем в час пик!

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

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

• Мой исходный текст съел кот Мурзик

• Общайтесь!

• Стрельба трассирующими

• Большие надежды

4. Специалисты по маркетингу хотели бы сесть и вместе с вами провести мозговой штурм по дизайну нескольких интернет-страниц. Они думают об активных картах ссылок – для перехода к другим страницам. Но они не могут определиться с моделью ссылки: это могут быть изображения автомобиля, телефона или дома. У вас имеется перечень целевых страниц и содержания; они хотели бы увидеть несколько прототипов. Да, кстати, в вашем распоряжении 15 мин. Какими инструментами вы могли бы воспользоваться? (Ответ см. в Приложении В.)

Сколько времени потребуется для пересылки «Войны и мира» по модемной линии в 56 байт? Какое место займет на диске миллион имен и адресов? Сколько времени понадобится для прохождения 1000-байтового блока через маршрутизатор? Сколько месяцев потребуется, чтобы завершить ваш проект?

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

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

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

Насколько точной является «приемлемая точность»?

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

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

• Каково значение числа «пи»? Если вас интересует, какое количество бордюрного камня понадобится для оформления цветочной клумбы, то цифра 3 вероятно будет приемлемой [15]. На школьном уровне хорошим приближением является 22/7. Ну а если вы работаете в NASA, то двенадцати цифр после запятой будет вполне достаточно.

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

Продолжительность == Оценка (порядок)

1-15 дней == дни

3-8 недель == недели

8-30 недель == месяцы

30 и более недель == перед тем, как оценить, стоит хорошенько подумать

Так, если после всей необходимой работы, вы придете к решению, что проект займет 125 рабочих дней (25 недель), он может быть оценен как «примерно за шесть месяцев».

Те же принципы применимы к оценкам любых количеств: выберите единицы, в которых будет дан ответ, чтобы отразить точность, которую вы намерены передать.

Из чего исходят оценки?

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

Понимание сути заданного вопроса

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

Построение модели системы

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

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

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

Декомпозиция модели

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

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

Присвоение значения каждому параметру

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

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

Вычисление ответов

Только в самом простом случае ваша оценка будет иметь один-единственный ответ. Вы счастливый человек, если можете сказать: «Я могу пройти по городу пять кварталов за 15 минут». Но поскольку системы все усложняются, вам захочется подстраховать ваши ответы. Проведите многократные вычисления, изменяя значения критических параметров, пока не выясните, какие из них действительно управляют моделью. Серьезную помощь в этом может оказать электронная таблица. Затем сформулируйте ваш ответ с точки зрения этих параметров. «Время отклика составляет (грубо) три четверти секунды, если система имеет шину SCSI и объем памяти 64 Мбайт; и одну секунду при объеме памяти 48 Мбайт». (Заметьте, что «три четверти секунды» дает иное ощущение точности, нежели 750 мс.)

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

Отслеживание уровня мастерства

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

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

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

• Проверить требования

• Проанализировать риск

• Осуществить проектирование, реализацию, интеграцию

• Проверить правильность при работе с пользователями

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

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

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

Что сказать, если вас просят оценить что-либо

Говорите «Я вернусь к вам с этим позже».

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

• Скорость алгоритма

• Заведите журнал регистрации сделанных вами оценок. Для каждой оценки укажите, насколько точной она оказалась. Если отклонение превысило 50 %, постарайтесь выяснить, где была допущена ошибка.

9. Спрашивается: какой из двух каналов обладает более широкой полосой пропускания: линия связи со скоростью 1 Мбайт/сек или человек, двигающийся от компьютера к компьютеру со стриммерной кассетой объемом 4 Гбайт в кармане? Какие ограничения накладываются на ответ, чтобы гарантировать его корректность в определенной области? (Например, можно указать, что временем доступа к ленте можно пренебречь.) (Ответ см. в Приложении В.)

10. Так какой же из двух каналов обладает более широкой полосой пропускания? (Ответ см. в Приложении В.)