Бьерн Страуструп. Язык программирования С++ Второе дополненное издание



Pdf көрінісі
бет216/256
Дата11.07.2022
өлшемі2,87 Mb.
#37591
1   ...   212   213   214   215   216   217   218   219   ...   256
Байланысты:
Бьерн Страуструп. Язык программирования С . М Бином, 2011

11.3.6 Сопровождение 
"Сопровождение программного обеспечения" - неудачный термин. Слово "сопровождение" предлагает 
неверную аналогию с аппаратурой. Программы не требуют смазки, не имеют движущихся частей, 
которые изнашиваются так, что требуют замены, у них нет трещин, в которые попадает вода, вызывая 
ржавчину. Программы можно воспроизводить в точности и передавать в течении минуты на длинные 
расстояния. Короче, программы это совсем не то, что аппаратура. (В оригинале: "Software is not 
hardware"). 
Деятельность, которая обозначается, как сопровождение программ, на самом деле, состоит из 
перепроектирования и повторной реализации, а значит входит в обычный цикл развития программного 
обеспечения. Если в проекте учтены вопросы расширяемости, гибкости и переносимости, то обычные 


Бьерн Страуструп.
Язык программирования С++ 
 
299 
задачи сопровождения решаются естественным образом. 
Подобно тестированию задачи сопровождения не должны решаться вне основного направления 
развития проекта и их не следует откладывать на потом. 
11.3.7 Эффективность 
Д. Кнуту принадлежит утверждение "Непродуманная оптимизация – корень всех бед". Некоторые 
слишком хорошо убедились в справедливости этого и считают вредными все заботы об оптимизации. 
На самом деле вопросы эффективности надо все время иметь в виду во время проектирования и 
реализации. Это не означает, что разработчик должен заниматься задачами локальной оптимизации, 
только задача оптимизации на самом глобальном уровне должна его волновать. 
Лучший способ добиться эффективности - это создать ясный и простой проект. Только такой проект 
может остаться относительно устойчивым на весь период развития и послужить основой для настройки 
системы с целью повышения производительности. Здесь важно избежать "гаргантюализма", который 
является проклятием больших проектов. Слишком часто люди добавляют определенные возможности 
системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3), удваивая, учетверяя размер выполняемой 
программы ради завитушек. Еще хуже то, что такие усложненные системы трудно поддаются анализу, а 
по этому трудно отличить избыточные накладные расходы от необходимых и провести анализ и 
оптимизации на общем уровне. Оптимизация должна быть результатом анализа и оценки 
производительности системы, а не произвольным манипулированием с программным кодом, причем 
это особенно справедливо для больших систем, где интуиция разработчика или программиста не может 
служить надежным указателем в вопросах эффективности. 
Важно избегать по сути неэффективных конструкций, а так же таких конструкций, которые можно 
довести до приемлемого уровня выполнения, только затратив массу времени и усилий. По этой же 
причине важно свести к минимуму использование непереносимых по своей сути конструкций и средств, 
поскольку их наличие препятствует работе системы на других машинах (менее мощных, менее 
дорогих). 


Достарыңызбен бөлісу:
1   ...   212   213   214   215   216   217   218   219   ...   256




©emirsaba.org 2024
әкімшілігінің қараңыз

    Басты бет