Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 178

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

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

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

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

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

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

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

Возрастающая формальность языка/обозначений при выражении проекта дает проектировщику возможность восполъзоваться подобнымн средствами, но этого не следует делать за счет выхолащивания используемого для реализации языка программирования Я 24.3.1), К тому же формальные обозначения могут сами внести путаницу и проблемы. Такое случается, когда: формализм плохо подходит к той практической проблеме, к которой он приложен; строгость формализма превышает математическую подготовку и зрелость проектировщиков и программистов; формальное описание системы неадекватно системе, которую оно предположительно описывает.

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

Такое идсальное проектирование и/или проверка программы, чтобы она заработала с первого раза, достижимы разве что в самых тривиальных случаях. Мы должны стремиться к идеалу, но не следует думать, что тестировать легко. «Как тестировать?» — па этот вопрос нет общего ответа. Однако на вопрос «Когл« тестировать?» можно дать общий ответ: как можно раныпе и как можно чаще.

Стратегия тестирования должна быть частъю проекта и реализации, или по крайней мере должна разрабатываться параллельно с ними. Как только система может быть запущена, должно начинаться тестирование. Откладывание серьезного тестирования до тех пор, «пока не завершится реализация» — это верный рецепт срыва календарного графика и получения изъянов в конечном продукте. Когда представляется возможность, систему следует специально проектировать так, чтобы ее было относительно легко тестировать, В частности, механизмы для тестирования часто могут встраиваться в саму систему. Иногда этого не делают из опасения получить слишком расточительную программу во время исполнения или из опасения, что избыточность, необходимая для проверки, чрезмерно расширит структуры данных. Такие страхи, как правило, неуместны, поскольку большую часть тестирующего кода и избыточности при необходимости можно убрать из программы перед выпуском системы. Иногда здесь полезен механизм утверждений Я 24.3.7.2).

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

Голи на стадии проектирования вопросы тестирования были совершенно забыты, то возникнут проблемы с тестированием, сроками сдачи и сопровождением. Обычно хорошим местом для начала работы над стратегией тестирования являются интерфейсы классов и взаимозависимость между классами (как описано в Э 24.3 и Э 244.2), Обычно трудно определить, сколько нужно тестировать систему. Однако нехватка тестирования — более распространенная проблема, чем избыток. Точное количество ресурсов, которые должны быть выделены для тестирования по сравнению с проектированием н реализацией, естественно зависит от природы системы и методов ее конструирования.

Однако, в качестве эмпирического правила я могу предположить, что на тестирование системы следует потратить больше времени, усилий и та- Глава 23. Разработка и проектирование 784 ланга, чем на конструирование первоначальной реализации. Тестирование должно сосредото ситься на проблемах, которые могут повлечь за собой ужасныс последствия, и тех, которые встречаются чаще всего. 23.4.6. Сопровождение программ «Сопровождение программ» вЂ” это недоразумение. Слово «сопровождение» (ша1пгепапсе) вызывает ассоциацию с обслуживанием техники. Но программу не нужно смазывать, заменять износившиеся части, в ней не появляются трещины, куда затекает вода, вызывая ржавчину. Программу можно скопировать один к одному и передать на большие расстояния в течение нескольких минут.

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

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

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

Только такой проект может остаться относительно стабильным за время жизни системы н послужить базой для улучшения быстродействия. Очень важно избегать гаргантюанизма, который губит большие проекты. Слишком часто люди добавляют возможности к системе «просто на всякий случай» Я 23А.3.2, ч 23.5.3) и заканчивают тем, что рэди сохранения архитектурных излишеств вдвое или даже вчетверо увеличивают размеры программы при таком же снижении быстродействия.

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

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