Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 179

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 179)

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

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

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

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

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

Отметим, что проект и проектные спецификации столь же подвержены ошибкам, что и реализация. И по сути дела даже больше подвержены, ибо они менее конкретны, определенно менее точны, их нельзя исполнить и, как правило, они не поддержаны столь изощренными средствами, которые доступны для тестирования и анализа реализации. Увеличение уровня абстракции (формализации) языка/обозначений для изложения проекта, способствует применению специальных программных инструментов для поддержки проектирования, что может в определен- 836 Глава 23. Общий взгляд на разработку программ.

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

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

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

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

Здесь особо удобен механизм проверочных утверждений (аззегГ(опз) (324.3.7.2). Но еше более важным, чем конкретные тесты, является разработка такой структуры системы, в рамках которой можно быть уверенным в том, что ошибки будут устранены путем комбинации статических проверок, статического анализа и тестирования. Когда разрабатывается общая стратегия устойчивости к ошибкам (514.9), стратегия тестирования может разрабатываться как дополнительный и тесно связанный с ней аспект общего проектирования. Если на стадии проектирования вопросы тестирования были забыты, то готовьтесь к тому, что процесс тестирования затянется, сроки сдачи продукта сорвутся, а поддержка продукта усложнится. Обычно хорошим местом для начала работы над 23.4. Процесс разработки 837 стратегией тестирования является этап проектирования, связанный с определением интерфейсов классов и их зависимостями 524.3, 524.4.2).

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

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

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

Характеристики

Список файлов книги