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

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

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

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

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

Разумеется, это не так, и вопросы эффективности нельзя упускать из виду в процессе проектирования и реализации. Но проектировщик не должен рассматривать приемы достижения микроэффективности, а должен сосредотачивать свое внимание на высокоуровневых аспектах эффективной работы системы. Глава 23. Общий взгляд на разработку программ. Проектирование 838 Наилучшая стратегия достижения эффективности — это создание ясного и не переусложненного проекта. Только такие проекты остаются стабильными на протяжении жизни системы и служат базой для повышения ее быстродействия. Не нужно добавлять в проект все новые возможности «просто на всякий случай» (З23.4.3.2, З23.5.3) — это заканчивается удвоением или утроением первоначального размера и сопоставимым снижением быстродействия.

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

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

Серьезного изменения в программировании можно добиться лишь в связи с серьезным изменением стиля проектирования, а все это достигается серьезными изменениями в стиле управления проектом. Интеллектуальная и организационная инерция способствуют осуществлению сугубо локальных изменений, в то время как для серьезного успеха обычно нужны глобальные изменения. Типичным примером является ситуация, когда осуществляется переход на язык объектно-ориентированного программирования, такой как С+-ь, но при этом по-прежнему используются старые проектные стратегии, не способствующие эффективному использованию новых средств языка (В24.2). Другой пример — переход на объектно-ориентнрованное проектирование при сохранении старого (не объектно-ориентированного) языка программирования.

23.5.1. Повторное использование кода Увеличение степени повторного использования готовых проектов и программного кода часто называют в качестве ~лавной причины перехода на новый язык программирования нлн новую стратегию проектирования. Но на практике часто бывает наоборот — организации скорее поощряют программистов «изобретать велосипед». Например, производительность программиста замеряют по числу строк кода; будет он после этого стремиться к фрагментам малого размера, активно ис- 23.5.

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

Повторное использование предыдущих разработок — это социальная проблема. Воспользоваться готовыми программными проектами можно лишь тогда, когда: 1. Они работают: чтобы годиться к повторному использованию, они должны на самом деле использоваться. 2.

Они понятны: важны программная структура, комментарии, документация и руководство. 3. Они могут сосуществовать с иными программами, специально не предназначенными для совместной работы с ними. 4. Они имеют поддержку. 5. Они экономичны (затраты на их разработку и сопровождение равномерно распределены между многими пользователями). 6. Они доступны. Можно утверждать, что нельзя твердо считать программный компонент готовым для повторного использования до того момента, как кто-либо реально воспользуется им с этой целью. Задача подгонки компонента к новой среде работы требует, как правило, определенной корректировки его операций, универсализации поведения и улучшения способности сосуществовать с другими программами.

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

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

Кроме того, эта группа должна составлять руководства, нз которых потенциальные пользователи могут узнать, где найти компонент и какую пользу он может принести. То есть характер работы такой группы близок характеру работы групп маркетинга и повышения квалификации персонала. Глава 23. Общий взгляд на разработку программ. Проектирование 840 По мере возможности члены группы «по стандартным компонентам» должны работать как можно ближе к разработчикам, ибо только в этом случае они смогут понять нужды своих пользователей и осознать возможности совместной работы разных приложений со стандартными компонентами. Успех группы «по стандартным компонентам» должен измеряться успехом их клиентов.

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

В то же время, переход к другой среде разработки может потребовать значительных усилий, так что способность к повторному использованию напоминает свойство переносимости. Важно осознать, что повторное использование — это результат проектирования, направленного на достижение этого свойства, результат усовершенствования компонент на основе опыта их применения и результат сознательных усилий по поиску компонентов, пригодных для повторного использования. Повторное использование ие возникает волшебным образом из бездумного применения отдельных языковых черт или технологий кодирования. Такие средства языка С++, как классы, виртуальные функции и шаблоны помогают спроектировать систему так, что ее повторное использование становится более легким (и более вероятным), но сами по себе эти средства ничего не гарантируют. 23.5.2.

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

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