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

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

Тогда в чем же проблема? К сожалению, большинство программистов любят программировать. Некоторые из них могут даже не есть и не мыться, а только заниматься программированием. Большинство из них предпочитают писать код, а не рыться в документации, или искать в каталогах, или разбираться в идиотской работе какого-то тупого программиста. Разработчики программного обеспечения создают продукты, а пользователи их применяют. При прочих равных условиях программисты будут разрабатывать и строить с нуля, а не использовать что-либо повторно. Каждый из них убежден, что сможет написать более короткую и более элегантную программу, чем код его предшественника. В силу своего характера программисты имеют предубеждение против повторного использования, даже если оно может повысить их продуктивность. Как побудить их изменить свои привычки? Внезапно с балкона раздается контрапунктное пение хора: «Премии. Рыночные меры. Поощрительные схемы. Гонорары. Графики поощрений. Изменение культуры». Какая приятная какофония!

На самом деле не так уж и трудно понять всю выгоду. Применение повторного использования в больших масштабах начинается с библиотек повторно используемых компонентов. Существуют только две основные проблемы, связанные с такими библиотеками: помещение компонентов туда и извлечение оттуда! Для того чтобы программисты могли повторно пользоваться компонентами из библиотеки, эти компоненты должны там находиться. Откуда они там возьмутся?

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

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

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

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

Меилир Пейдж-Джонс (Meilir Page-Jones) рассказывает об одном клиенте, у которого библиотека «подержанных» компонентов стала чересчур громоздкой. Руководство решило назначить библиотекаря, чьей обязанностью было извлечение компонентов из библиотеки и контроль за тем, чтобы в хранилище включались только самые лучшие подпрограммы. Легенда сообщает, что этого человека стали называть Конан-Библиотекарем (Conan the Librarian). Тем не менее для эффективности такого подхода должны быть серьезные силы, которые побуждали бы разработчиков вносить свои пожертвования в библиотеку.

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

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

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

Авторские гонорары за повторное использование ставят другие проблемы. Например, отдача от компонентов, за которые выплачены гонорары (в виде наличных денег или кредита), обычно слишком запаздывает. Деньги уже потрачены — не только на те компоненты, которые часто используются повторно, но и на те, которые оказались бесполезными. Для эффективности процесса отбора необходим большой набор компонентов, соответствующий разнообразным требованиям рынка или среды. Это означает, что средние библиотеки будут достаточно большими. В них будет много посредственных или плохих компонентов, из которых можно отобрать лишь небольшое количество «хороших». Трудно даже понять, как проводить такой процесс отбора. Всегда ли часто используемый компонент является подходящим? Может быть, его часто применяют потому, что другого в библиотеке нет? А может быть, частота обращения к нему отражает его позицию в индексе и броузере? А может, его просто лучше разрекламировали, хотя существует меньший по размеру и более мощный вариант?

И что считать «использованием»? Каждый вызов или конкретизацию? Каждый случай наследования или ссылки? Одна программа может 130 раз обратиться к компоненту, который ни разу не применялся ни в одном продукте, а другой компонент может однократно применяться в каждой из 27 систем, разработанных в течение года. Какой компонент является более полезным? Какой продукт заслуживает большего гонорара: простой, понятный и часто используемый компонент или искусный и оригинальный класс, который помог сэкономить несколько дней работы в одном проекте?

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

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

Простое коллекционирование разумных компонентов не создаст библиотеку компонентов повторного использования. Нужно еще убедить разработчиков применять эти компоненты, а не изобретать их заново. Во многих компаниях для этого разработаны системы надбавок и премий, однако я не уверен в том, что они необходимы для продуктивного повторного использования компонентов. Более того, в конечном итоге такие схемы даже могут оказаться непродуктивными. Иногда бывает достаточно просто предоставить информацию о производительности. В одной организации понадобилось лишь изменить способ информирования группы о степени продуктивности. Инвестировав средства в развитие библиотеки компонентов, они были разочарованы из-за ее ограниченного использования. Они ежемесячно вывешивали лист с диаграммами, которые отражали продуктивность программистов, измеренную в строках написанного и сданного кода. Вместо этого их убедили сообщать об общем количестве строк, взятых из библиотеки компонентов и включенных в сданный код. Уровень повторного использования резко возрос. Однако является ли ко-личество-строк-библиотечного-кода правильной меркой повторного использования? Возможно, корректное, разумное и уместное повторное использование — это намного более тонкий показатель, который сложно описать и измерить.

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

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

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

Из журнала Computer Language Magazine, том 9, № 7,1992 г.