Читаем Человеческий фактор в программировании полностью

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

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

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

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

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

Приобретенный вкус

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

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

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT