Б. Страуструп - Язык программирования С++ (1119446), страница 82
Текст из файла (страница 82)
Например, может оказаться полезным изучение различных зависимостей между классами(см.$$ 12.2), не следует забывать и о таких традиционных вспомогательных средствах реализации, какграф вызовов функций, оценка производительности и т.п.Заметим, что спецификация (результат анализа системы) и проект могут содержать ошибки, как иреализация, и возможно, они даже больше подвержены ошибкам, т.к. являются менее точными, немогут быть проверены на практике и обычно не окружены такими развитыми средствами, как те, чтослужат для анализа и проверки реализации.
Введение большей формализации в язык или запись, спомощью которой изложен проект, в какой-то степени облегчает использования этих средств дляпроектирования. Но, как сказано в $$12.1.1, это нельзя делать за счет ухудшения языка, используемогодля реализации. К тому же формальная запись может сама стать источником трудностей и проблем.Это происходит, когда выбранная степень формализации плохо подходит для конкретных задач, когдастрогость формализации превосходит математическую основу системы и квалификацию разработчиков297Бьерн Страуструп.Язык программирования С++и программистов, и когда формальное описание системы начинает расходиться с реальной системой,для которой оно предназначалось.Заключение о необходимости опыта и о том, что проектирование неизбежно сопровождается ошибкамии плохо поддержано программными средствами, служит основным доводом в пользу итеративноймодели проектирования и реализации.
Альтернатива - это линейная модель процесса развития,начиная с анализа и кончая тестированием, но она существенно дефектна, поскольку не допускаетповторных проходов, исходя из опыта, полученного на различных этапах развития системы.11.3.5 ТестированиеПрограмма, которая не прошла тестирование, не работает. Идеал, чтобы после проектирования и (или)верификации программа заработала с первого раза, недостижим для всех, за исключением самыхтривиальных программ. Следует стремиться к идеалу, но не заблуждаться, что тестирование простоедело."Как проводить тестирование?" - на этот вопрос нельзя ответить в общем случае.
Однако, вопрос "Когданачинать тестирование?" имеет такой ответ - на самом раннем этапе, где это возможно. Стратегиятестирования должна быть разработана как часть проекта и включена в реализацию, или, по крайнеймере, разрабатываться параллельно с ними. Как только появляется работающая система, надоначинать тестирование. Откладывание тестирования до "проведения полной реализации" - верныйспособ выйти из графика или передать версию с ошибками.Всюду, где это возможно, проектирование должно вестись так, чтобы тестировать систему былодостаточно просто. В частности, имеет смысл средства тестирования прямо встраивать в систему.Иногда это не делается из-за боязни слишком объемных проверок на стадии выполнения, или из-заопасений, что избыточность, необходимая для полного тестирования, излишне усложнит структурыданных.
Обычно такие опасения неоправданы, поскольку собственно программы проверки идополнительные конструкции, необходимые для них, можно при необходимости удалить из системыперед ее поставкой пользователю. Иногда могут пригодится утверждения о свойствах программы (см.$$12.2.7).Более важной, чем набор тестов, является подход, когда структура системы такова, что есть реальныешансы убедить себя и пользователей, что ошибки можно исключить с помощью определенного наборастатических проверок, статического анализа и тестирования.
Если разработана стратегия построениясистемы, устойчивой к ошибкам (см.$$9.8), стратегия тестирования обычно разрабатывается каквспомогательная.Если вопросы тестирования полностью игнорируются на этапе проектирования, возникнут проблемы стестированием, временем поставки и сопровождением системы. Лучше всего начать работать надстратегией тестирования с интерфейсов классов и их взаимозависимостей (как предлагается в $$12.2 и$$12.4).Трудно определить необходимый объем тестирования.
Однако, очевидно, что проблему представляетнедостаток тестирования, а не его избыток. Сколько именно ресурсов в сравнении с проектированием иреализацией следует отвести для тестирования зависит от природы системы и методов ее построения.Однако, можно предложить следующее правило: отводить больше ресурсов времени и человеческихусилий на тестирование системы, чем на получения ее первой реализации.11.3.6 Сопровождение"Сопровождение программного обеспечения" - неудачный термин.
Слово "сопровождение" предлагаетневерную аналогию с аппаратурой. Программы не требуют смазки, не имеют движущихся частей,которые изнашиваются так, что требуют замены, у них нет трещин, в которые попадает вода, вызываяржавчину. Программы можно воспроизводить в точности и передавать в течении минуты на длинныерасстояния. Короче, программы это совсем не то, что аппаратура. (В оригинале: "Software is nothardware").Деятельность, которая обозначается, как сопровождение программ, на самом деле, состоит изперепроектирования и повторной реализации, а значит входит в обычный цикл развития программногообеспечения.
Если в проекте учтены вопросы расширяемости, гибкости и переносимости, то обычные298Бьерн Страуструп.Язык программирования С++задачи сопровождения решаются естественным образом.Подобно тестированию задачи сопровождения не должны решаться вне основного направленияразвития проекта и их не следует откладывать на потом.11.3.7 ЭффективностьД. Кнуту принадлежит утверждение "Непродуманная оптимизация – корень всех бед". Некоторыеслишком хорошо убедились в справедливости этого и считают вредными все заботы об оптимизации.На самом деле вопросы эффективности надо все время иметь в виду во время проектирования иреализации.
Это не означает, что разработчик должен заниматься задачами локальной оптимизации,только задача оптимизации на самом глобальном уровне должна его волновать.Лучший способ добиться эффективности - это создать ясный и простой проект. Только такой проектможет остаться относительно устойчивым на весь период развития и послужить основой для настройкисистемы с целью повышения производительности. Здесь важно избежать "гаргантюализма", которыйявляется проклятием больших проектов. Слишком часто люди добавляют определенные возможностисистемы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3), удваивая, учетверяя размер выполняемойпрограммы ради завитушек.
Еще хуже то, что такие усложненные системы трудно поддаются анализу, апо этому трудно отличить избыточные накладные расходы от необходимых и провести анализ иоптимизации на общем уровне. Оптимизация должна быть результатом анализа и оценкипроизводительности системы, а не произвольным манипулированием с программным кодом, причемэто особенно справедливо для больших систем, где интуиция разработчика или программиста не можетслужить надежным указателем в вопросах эффективности.Важно избегать по сути неэффективных конструкций, а так же таких конструкций, которые можнодовести до приемлемого уровня выполнения, только затратив массу времени и усилий.
По этой жепричине важно свести к минимуму использование непереносимых по своей сути конструкций и средств,поскольку их наличие препятствует работе системы на других машинах (менее мощных, менеедорогих).11.4 Управление проектомЕсли только это имеет какой-то смысл, большинство людей делает то, что их поощряют делать. Так, вконтексте программного проекта, если менеджер поощряет определенные способы действий инаказывает за другие, редкие программисты или разработчики рискнут своим положением, встречаясопротивления или безразличия администрации, чтобы делать так, как они полагают нужным.Организация, в которой считают своих программистов недоумками, оченьпрограммистов, которые будут рады и способны действовать только как недоумки.скорополучитОтсюда следует, что менеджер должен поощрять такие структуры, которые соответствуютсформулированным целям проекта и реализации.
Однако на практике слишком часто бывает иначе.Существенное изменение стиля программирования достижимо только при соответствующем изменениив стиле проектирования, кроме того, обычно и то и другое требует изменения в стиле управления.Мыслительная и организационная инерция слишком просто сводят все к локальным изменениям, хотятолько глобальные изменения могут принести успех. Прекрасной иллюстрацией служит переход на языкс объектно-ориентированным программированием, например на С++, когда он не влечет за собойсоответствующих изменений в методах проектирования, чтобы воспользоваться новымивозможностями языка (см.
$$12.1), и, наоборот, когда переход на "объектно-ориентированноепроектирование" не сопровождается переход на язык реализации, который поддерживает этот стиль.11.4.1 Повторное использованиеЧасто основной причиной перехода на новый язык или новый метод проектирования называют то, чтоэто облегчает повторное использование программ или проекта. Однако, во многих организацияхпоощряют сотрудника или группу, когда они предпочитают изобретать колесо. Например, еслипроизводительность программиста измеряется числом строк программы, то будет ли он писатьмаленькие программы, работающие со стандартными библиотеками, за счет своего дохода и, можетбыть, положения? А менеджер, если он оплачивается пропорционально числу людей в его группе,299Бьерн Страуструп.Язык программирования С++будет ли он использовать программы, сделанные другими коллективами, если он может просто нанятьеще пару программистов в свою группу? Компания может получить правительственный контракт, вкотором ее доход составляет фиксированный процент от расходов на проект, будет ли она сокращатьсвой доход за счет использования наиболее эффективных средств? Трудно обеспечитьвознаграждение за повторное использование, но если администрация не найдет способов поощрения ивознаграждения, то его просто не будет.Повторное использование является прежде всего социальным фактором.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
