Бьерн Страуструп. Язык программирования С++

11.4 Управление проектом

Если только это имеет какой-то смысл, большинство людей делает то,

что их поощряют делать. Так, в контексте программного проекта, если

менеджер поощряет определенные способы действий и наказывает за

другие, редкие программисты или разработчики рискнут своим

положением, встречая сопротивления или безразличия администрации,

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

очень скоро получит программистов, которые будут рады и способны

действовать только как недоумки.
Отсюда следует, что менеджер должен поощрять такие структуры,

которые соответствуют сформулированным целям проекта и реализации.

Однако на практике слишком часто бывает иначе. Существенное

изменение стиля программирования достижимо только при соответствующем

изменении в стиле проектирования, кроме того, обычно и то и другое

требует изменения в стиле управления. Мыслительная и организационная

инерция слишком просто сводят все к локальным изменениям, хотя

только глобальные изменения могут принести успех. Прекрасной

иллюстрацией служит переход на язык с объектно-ориентированным

программированием, например на С++, когда он не влечет за собой

соответствующих изменений в методах проектирования, чтобы

воспользоваться новыми возможностями языка (см. $$12.1), и, наоборот,

когда переход на "объектно-ориентированное проектирование" не

сопровождается переход на язык реализации, который поддерживает

этот стиль.

11.4.1 Повторное использование

Часто основной причиной перехода на новый язык или новый метод

проектирования называют то, что это облегчает повторное использование

программ или проекта. Однако, во многих организациях поощряют

сотрудника или группу, когда они предпочитают изобретать колесо.

Например, если производительность программиста измеряется числом

строк программы, то будет ли он писать маленькие программы,

работающие со стандартными библиотеками, за счет своего дохода

и, может быть, положения? А менеджер, если он оплачивается

пропорционально числу людей в его группе, будет ли он использовать

программы, сделанные другими коллективами, если он может просто

нанять еще пару программистов в свою группу? Компания может

получить правительственный контракт, в котором ее доход составляет

фиксированный процент от расходов на проект, будет ли она

сокращать свой доход за счет использования наиболее эффективных

средств? Трудно обеспечить вознаграждение за повторное использование,

но если администрация не найдет способов поощрения и вознаграждения,

то его просто не будет.

Повторное использование является прежде всего социальным

фактором. Повторное использование программы возможно при условии,

что

[1] она работает; нельзя использовать повторно, если это невозможно

[2] она понятна; здесь имеет значение структура программы, наличие

комментариев, документации, руководства;

[3] она может работать вместе с программами, которые не создавались

специально с таким условием;

[4] можно рассчитывать на ее сопровождение (или придется делать

это самому, что обычно не хочется);

[5] это выгодно (хотя можно и разделить расходы по разработке

и сопровождению с другими пользователями) и, наконец;

[6] ее можно найти.

К этому можно еще добавить, что компонент не является повторно

используемым, пока кто-то действительно не сделал это. Обычно задача

приспособления компонента к существующему окружению приводит к

уточнению набора операций, обобщению его поведения, и повышению его

способности адаптации к другим программам. Пока все это не проделано

хотя бы один раз, неожиданные острые углы находятся даже у

компонентов, которые тщательно проектировались и реализовывались.

Личный опыт подсказывает, что условия для повторного

использования возникают только в том случае, когда находится

конкретный человек, занятый этим вопросом. В маленьких группах

это обычно бывает тот, кто случайно или запланированно оказывается

хранителем общих библиотек или документации. В больших организациях

это бывает группа или отдел, которые получают привилегию собирать,

документировать, популяризировать и сопровождать программное

обеспечение, используемое различными группами.

Нельзя недооценивать такие группы "стандартных компонентов".

Укажем, что в первом приближении, система отражает организацию,

которая ее создала. Если в организации нет средств поощрения и

вознаграждения кооперации и разделения труда, то и на практике

они будут исключением. Группа стандартных компонентов должна

активно предлагать свои компоненты. Обычная традиционная

документация важна, но ее недостаточно. Помимо этого указанная

группа должна предоставлять руководства и другую информацию,

которая позволит потенциальному пользователю отыскать компонент и

понять как он может ему помочь. Значит эта группа должна предпринимать

действия, которые обычно связываются с системой образования и

маркетинга. Члены группы компонентов должны всегда, когда это

возможно, работать в тесном сотрудничестве с разработчиками из

областей приложения. Только тогда они будут в курсе запросов

пользователей и сумеют почуять возможности использования

стандартного компонента в различных областях. Это является

аргументом за использование такой группы в роли консультанта и в

пользу внутренних поставок программ, чтобы информация из группы

компонентов могла свободно распространяться.

Заметим, что не все программы должны быть рассчитаны на

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

является универсальным свойством. Сказать, что некоторый компонент

может быть повторно использован, означает, что в рамках определенной

структуры его повторное использование не потребует значительных

усилий. Но в большинстве случаев перенос в другую структуру может

потребовать большой работы. В этом смысле повторное использование

сильно напоминает переносимость. Важно понимать, что повторное

использование является результатом проектирования, ставившего

такую цель, модификации компонентов на основе опыта и специальных

усилий, предпринятых для поиска среди существующих компонентов

кандидатов на повторное использование. Неосознанное использование

средств языка или приемов программирования не может чудесным

образом гарантировать повторное использование. Такие средства языка

С++, как классы, виртуальные функции и шаблоны типа, способствуют

проектированию, облегчающему повторное использование (значит делают

его более вероятным), но сами по себе эти средства не гарантируют

повторное использование.