straustrup2 (852740), страница 79
Текст из файла (страница 79)
Обычно такие опасения неоправданы, поскольку собственно программы проверки идополнительные конструкции, необходимые для них, можно при необходимости удалить из системыперед ее поставкой пользователю. Иногда могут пригодится утверждения о свойствах программы (см.$$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Бьерн Страуструп.Язык программирования С++будет ли он использовать программы, сделанные другими коллективами, если он может просто нанятьеще пару программистов в свою группу? Компания может получить правительственный контракт, вкотором ее доход составляет фиксированный процент от расходов на проект, будет ли она сокращатьсвой доход за счет использования наиболее эффективных средств? Трудно обеспечитьвознаграждение за повторное использование, но если администрация не найдет способов поощрения ивознаграждения, то его просто не будет.Повторное использование является прежде всего социальным фактором.
Повторное использованиепрограммы возможно при условии, что[1]она работает; нельзя использовать повторно, если это невозможно и в первый раз;[2]она понятна; здесь имеетдокументации, руководства;[3]она может работать вместе с программами, которые не создавались специально с такимусловием;[4]можно рассчитывать на ее сопровождение (или придется делать это самому, что обычно нехочется);[5]это выгодно (хотя можно и разделить расходы по разработке и сопровождению с другимипользователями) и, наконец;[6]ее можно найти.значениеструктурапрограммы,наличиекомментариев,К этому можно еще добавить, что компонент не является повторно используемым, пока кто-тодействительно не сделал это.
Обычно задача приспособления компонента к существующемуокружению приводит к уточнению набора операций, обобщению его поведения, и повышению егоспособности адаптации к другим программам. Пока все это не проделано хотя бы один раз,неожиданные острые углы находятся даже у компонентов, которые тщательно проектировались иреализовывались.Личный опыт подсказывает, что условия для повторного использования возникают только в том случае,когда находится конкретный человек, занятый этим вопросом. В маленьких группах это обычно бываеттот, кто случайно или запланированно оказывается хранителем общих библиотек или документации.
Вбольших организациях это бывает группа или отдел, которые получают привилегию собирать,документировать, популяризировать и сопровождать программное обеспечение, используемоеразличными группами.Нельзя недооценивать такие группы "стандартных компонентов". Укажем, что в первом приближении,система отражает организацию, которая ее создала. Если в организации нет средств поощрения ивознаграждения кооперации и разделения труда, то и на практике они будут исключением. Группастандартных компонентов должна активно предлагать свои компоненты.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
