Бьерн Страуструп (947334), страница 66

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 66)

работе системы на других машинах (менее мощных, менее дорогих).

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

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

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

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

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

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

чтобы делать так, как они полагают нужнымЬ.

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

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

действовать только как недоумки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

этот стиль.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

что

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

и в первый раз;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11.4.2 Размер

Человек и организация склонны излишне радоваться тому, что они

"действуют по правильной методе". В институтской среде это часто

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

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

желания внести улучшения. К несчастью, если здравого смысла не хватает,

то ущерб, нанесенный неразумными действиями, может быть неограниченным.

Вернемся к этапам процесса развития, перечисленным в $$11.3, и

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

переработать эти этапы в точный метод проектирования, когда шаг точно

определен, имеет хорошо определенные входные и выходные данные и

полуформальную запись для задания входных и выходных данных. Можно

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

создать средства, предоставляющие определенные удобства для записи

и организации процесса. Далее, исследуя классификацию зависимостей,

приведенную в $$12.2, можно постановить, что определенные зависимости

являются хорошими, а другие следует считать плохими, и предоставить

средства анализа, которые обеспечат проведение таких оценок во всех

стадиях проекта. Чтобы завершить такую "стандартизацию" процесса

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

(в том числе правила на правописание и грамматику и соглашения о

формате документации), а так же стандарты на общий вид программ

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

а какие нет, перечисление допустимых библиотек и тех, которые не нужно

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

правила расположения текста программы и т.д.).

Все это может способствовать успеху проекта. По крайней мере,

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

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

над которой будут работать сотни человек, и которую будут

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

хорошо определенного и строгого плана по всем перечисленным выше

позициям.

К счастью, большинство систем не относится к этой категории.

Тем не менее, если решено, что данный метод проектирования или

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

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

применять их повсеместно. В небольших проектах это приводит к

нелепым ограничениям и большим накладным расходам. В частности,

это может привести к тому, что мерой развития и успеха становится

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

бланков. Если это случится, то в таком проекте настоящих

программистов и разработчиков вытеснят бюрократы.

Когда происходит такое нелепое злоупотребление методами

проектирования (по всей видимости совершенно разумными), то неудача

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

формализации процесса разработки программного обеспечения. Это,

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

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

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

пригодной для процесса развития конкретного проекта. Не рассчитывайте

легко найти ее решение. По сути для малого проекта каждый метод

может сработать. Еще хуже то, что похоже практически каждый метод,

даже если он плохо продуман и жесток по отношению к исполнителям,

может сработать для большого проекта, если вы готовы затратить

уйму времени и денег.

В процессе развития программного обеспечения главная задача -

сохранить целостность проекта. Трудность этой задачи зависит

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

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

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

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

что общие цели проекта легко забывает или заменяет их на более

локальные и близкие цели. Верный путь к неудаче, когда нет человека

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

Верный путь к неудаче, когда у такого человека или группы нет

средств воздействовать на проект в целом.

Отсутствие согласованных дальних целей намного более опасно

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

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

такие общие цели, постоянно держать их в уме, составить документы,

содержащие самое общее описание проекта, составить пояснения к

основным понятиям, и вообще, помогать всем остальным помнить о

назначении проекта.

11.4.3 Человеческий фактор

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

разработчиков и программистов, поэтому от их подбора зависит

успех организации.

Менеджеры часто забывают, что организация состоит из

индивидуумов. Распространено мнение, что программисты равны и

взаимозаменяемы. Это заблуждение может погубить организацию за счет

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

остальных работать над задачами значительно ниже их уровня.

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

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

необходимым для решения данной задачи. Поэтому миф о взаимозаменяемости

Характеристики

Список файлов книги