Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик Страница 40

Рисковать реальными начальными деньгами ради предполагаемых, но неопределенных прибылей в будущем — это то, чем инвесторы занимаются изо дня в день. Однако во многих программирующих организациях менеджерам требуется для этого смелость — качество более редкое, чем компетенция в технических вопросах или административное мастерство. Я полагаю, что крайняя степень авансироания расходов и откладывания прибыли является самым существенным фактором, замедляющим принятие О-О технологий. Но даже в таких условиях C++, похоже, уверенно вытесняет C во многих организациях.

Что с повторным использованием?

Лучший способ справиться с разработкой части программной системы, относящейся к ее сущности — это вообще ее не разрабатывать. Пакеты программ — один из способов сделать это. Другой способ — повторное использование. Действительно, одной из наиболее привлекательных черт объектно-ориентированного программирования является обещание простоты повторного использования классов в сочетании с легкостью настройки благодаря наследованию.

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

Конечно, программисты всегда повторно использовали собственные разработки. Джонс пишет:

У наиболее опытных программистов есть свои личные библиотеки, позволяющие им при разработке новых программ повторно использовать до 30% кода по объему. На корпоративном уровне повторное использование приближается к 75% по объему и требует специальных библиотек и администрирования. Повторное использование кода в корпоративных масштабах требует изменений в бухгалтерии проекта и методах измерения работы. [23]

У. Хуан (W. Huang) предложил организацию программного производства с матричной структурой управления функциональными специалистами, чтобы держать под контролем их естественную склонность к повторному использованию собственного кода. [24]

Ван Шнайдер (Van Snyder) из JPL напоминает мне, что в кругах разработчиков математического программного обеспечения существует давняя традиция повторного использования программ:

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

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

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

**Как сегодня обстоят дела с повторным использованием на корпоративном уровне? Проведено множество исследований, а вот практикуется в США относительно мало. Что же касается повторного использования за рубежом, то тут имеют место неправдоподобные отчеты. [25]

Джонс сообщает, что все клиенты его фирмы, у которых более 5000 программистов, проводят формальные исследования повторной используемости, в то время как из числа клиентов с 500 и менее программстами это делает менее 10 процентов. [26] По его сообщению, в отраслях с высоким потенциалом повторного использования исследования (не реализация) «ведутся активно и энергично, даже если не вполне успешно». Эд Йордон сообщает о программной фирме в Маниле, в которой 50 программистов из общего числа 200 заняты только разработкой повторно используемых модулей для использования всеми остальными, и что в тех случаях, которые он видел, принятие этой технологии было вызвано организационными, а не техническими факторами — например, системой поощрений.

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

Парнас пишет следующее:

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

Кен Брукс сообщает, что трудно рассчитать, какая степень обобщенности окажется необходимой: «Мне приходится менять вещи, даже в пятый раз используя собственную библиотеку пользовательских интерфейсов.»

Реально повторное использование только начинается. Джонс сообщает, что на открытом рынке есть несколько модулей с повторно используемым кодом по цене от 1 до 20 процентов от обычной стоимости разработки. [27] Демарко говорит:

Меня все более обескураживает вся эта история с повторным использованием. Практически отсутствует теорема существования для повторного использования. Время подтвердило, что сделать вещи повторно используемыми стоит дорого.

Йордон дает оценку того, сколько это стоит: «Хорошее эмпирическое правило говорит, что повторно используемые компоненты потребуют вдвое больших затрат, чем «одноразовые» компоненты.» [28] Я рассматриваю эту цену как величину затрат на запуск компонентов в производство, обсуждавшуюся в главе 1, поэтому я оцениваю рост затрат как троекратный.

Конечно, мы видим различные формы и варианты повторного использования, но оно далеко не так широко применяется, как мы предполагали. Предстоит еще многое понять.

Понимание больших словарей: неожиданная проблема повторного использования, которую можно было предвидеть

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

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

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