Программист-прагматик. Путь от подмастерья к мастеру
Шрифт:
Прототипы разрабатываются для того, чтобы ответить лишь на несколько вопросов, поэтому их разработка намного дешевле и быстрее, чем приложения, которые идут в производство. Программа может игнорировать незначительные подробности – незначительные в данный момент, но позже могущие оказаться для пользователя очень важными. Если, к примеру, вы создаете прототип графического интерфейса пользователя, то можете смириться с неправильными результатами или данными. С другой стороны, если вы просто исследуете характеристики вычислений или производительности, можете обойтись скудным графическим интерфейсом пользователя или вообще без него.
Но если вы работаете в среде, где нельзя отказаться от подробностей, тогда необходимо спросить
Для чего создаются прототипы
Какие объекты можно изучать при помощи прототипов? Все, что характеризуются наличием риска. Все, что не подвергались тестированию ранее или являются абсолютно критичными для конечного варианта системы. Вес, что является недоказанным, экспериментальным или сомнительным. Вес то, с чем вы еще не освоились. Вы можете создавать прототипы:
• Архитектуры
• Новой функциональной возможности уже существующей системы
• Структуры или содержания внешних данных
• Инструментальных средств или компонентов, выпущенных фирмами-субподрядчиками
• Рабочих характеристик
• Дизайна интерфейса пользователя
Создание прототипов способствует приобретению опыта. Значение этого опыта заключается не в созданной программе, а в полученных уроках. В этом и состоит смысл создания прототипов.
Подсказка 16: Создавайте прототипы, чтобы учиться на них
Как использовать прототипы
Какими деталями можно пренебречь при построении прототипа?
• Корректность. Там, где это приемлемо, вы сможете использовать фиктивные данные.
• Завершенность. Прототип может функционировать лишь в ограниченном смысле, возможно, лишь с одним наперед заданным фрагментом входных данных и одним пунктом меню.
• Надежность. Процедура проверки ошибок, вероятно, будет неполной или будет отсутствовать полностью. Если вы отклоняетесь от определенного пути, то прототип может выйти из строя и сгореть, как ракета. Это нормально.
• Стиль. Неприятно признавать это, но прототип программы не имеет большого значения для комментариев или документации. При работе с прототипом можно написать горы документации, но сравнительно малая ее часть будет посвящена собственно прототипу системы.
Поскольку в прототипе детали отодвигаются на второй план, а в центре рассмотрения оказываются определенные аспекты системы, вам может показаться реальным создание прототипов с использованием языка очень высокого уровня – выше уровня языка остальной части проекта (язык типа Perl, Python или Tel). Язык сценариев высокого уровня позволяет опускать многие детали (включая указание типов данных) и при этом создавать функциональный (хотя и неполный и медленный) фрагмент программы [11] . Если вам необходимо создать прототип интерфейсов пользователей, изучите инструментальные средства типа Tcl/Tk, Visual Basic, Powerbuilder или Delphi.
11
При исследовании абсолютной (в противовес относительной) рабочей характеристики, необходимо придерживаться некоего языка, близкого по характеристикам к целевому языку.
Языки сценариев хороши для использования в качестве «клея» при соединении низкоуровневых фрагментов в новые сочетания. При работе в системе Windows язык Visual Basic может «скреплять» средства управления
СОМ. В более общем смысле вы можете использовать языки типа Perl и Python для связывания воедино низкоуровневых библиотек языка С – вручную или автоматически при помощи инструментов наподобие бесплатного SWIG [URL 28]. Используя этот подход, вы можете быстро собрать существующие компоненты в новые конфигурации, чтобы посмотреть, как они работают.Создание прототипов архитектуры
Многие прототипы создаются, чтобы смоделировать рассматриваемую систему в целом. В отличие от подхода типа "стрельба трассирующими", ни один из отдельных модулей в прототипе системы не должен быть особенно функциональным. На самом деле вам даже не нужно писать программу для создания прототипов – вы можете создать прототип на лекционной доске, при помощи памятных записок или каталожных карточек. Вы пытаетесь понять то, как система выглядит в собранном виде, опуская детали. Вот некоторые из конкретных областей, которые вы можете обнаружить в архитектурном прототипе:
• Четко ли определены обязанности основных компонентов, и являются ли они приемлемыми?
• Четко ли определена совместная работа основных компонентов?
• Сведено ли к минимуму связывание?
• Можно ли идентифицировать потенциальные источники дублирования?
• Можно ли применить определения интерфейсов и ограничения?
• Обладает ли каждый из модулей путем доступа к данным, требуемым ему в ходе выполнения? Может ли он получить такой доступ в случае необходимости?
Последний пункт приносит большинство сюрпризов и наиболее ценных результатов, основанных на опыте создания прототипов.
Как не надо использовать прототипы
Перед тем как вы займетесь созданием любого прототипа, основанного на программе, убедитесь, что все понимают – вы пишете одноразовую программу. Прототипы могут быть обманчиво привлекательными для людей, которые не знают, что это всего лишь прототипы. Вы должны очень четко уяснить – эта программа одноразовая, незавершенная и не может быть завершена.
Легко впасть в заблуждение из-за очевидной завершенности демонстрационного прототипа, и спонсоры проекта или менеджмент могут настаивать на развертывании прототипа (или его потомства), если вы заранее не определите, что можно ожидать от прототипа. Напомните им, что вы, конечно, можете создать великолепный прототип новой модели автомобиля из бальзовой древесины и клейкой ленты, но вы же не поедете на нем в час пик!
Если вы полагаете, что в вашей среде или культуре существует большая вероятность того, что назначение прототипа программы может быть истолковано неправильно, вам лучше воспользоваться подходом "стрельба трассирующими". Вы получите некий жесткий каркас, на котором можно основывать будущие разработки.
При надлежащем использовании прототип может сэкономить вам огромное количество времени, денег, головной боли и мучений за счет идентификации и исправления потенциальных проблем в самом начале цикла разработки – затраты на устранение ошибок будут недорогими и не вызовут затруднений.
• Мой исходный текст съел кот Мурзик
• Общайтесь!
• Стрельба трассирующими
• Большие надежды
4. Специалисты по маркетингу хотели бы сесть и вместе с вами провести мозговой штурм по дизайну нескольких интернет-страниц. Они думают об активных картах ссылок – для перехода к другим страницам. Но они не могут определиться с моделью ссылки: это могут быть изображения автомобиля, телефона или дома. У вас имеется перечень целевых страниц и содержания; они хотели бы увидеть несколько прототипов. Да, кстати, в вашем распоряжении 15 мин. Какими инструментами вы могли бы воспользоваться? (Ответ см. в Приложении В.)