Ларри Константин - Человеческий фактор в программировании

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

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

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

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

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

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

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

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