* законченный учебник и руководство по языку

Вид материала

Подобный материал:

1 ... 21 22 23 24 25 26 27 28 ... 34

в вопросах эффективности.

Важно избегать по сути неэффективных конструкций, а так же

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

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

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

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

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

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 Человеческий фактор

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

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

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

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

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

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

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

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

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

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

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

бесчеловечен и по сути своей расточителен.

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

расточительность и не могут учесть существенный личный вклад

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

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

выданных страниц документации, пропущенных тестов и т.п.

Такие цифры эффектно выглядят на диаграммах, но имеют самое

отдаленное отношение к действительности. Например, если

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

удачное повторное использование ухудшит оценку труда программиста.

Обычно тот же эффект будет иметь удачное применение лучших приемов

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

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

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

а не на основе грубых количественных оценок. К сожалению, насколько

известно, практическая разработка способов оценки качества еще не

началась. К тому же оценки, которые неполно описывают состояние

проекта, могут исказить процесс его развития. Люди приспосабливаются,

чтобы уложиться в отведенный срок и перестраивают свою работу в

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

общая целостность системы и ее производительность. Например, если

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

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

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

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

число невыявленных ошибок будет расти при условии недостатка

времени у исполнителей. Отсутствие хороших и разумных оценок

качества повышает требования к технической квалификации менеджеров,

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

а не реальный прогресс. Не надо забывать, что менеджеры тоже люди,

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

технологиях, как и те, кем они управляют.

Здесь, как и в других аспектах процесса развития программного

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

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

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

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

для предсказания их производительности. Если не принимать во внимание

такие карточки, что и делается, когда сотрудников считают

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

остаются только вводящие в заблуждения количественные оценки.

Если мы рассматриваем только достаточно большие временные

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

"взаимозаменяемых недоумков", то надо признать, что индивидууму

(как разработчику или программисту, так и менеджеру) нужен большой

срок, чтобы дорасти до более интересной и важной работы. Такой

подход не одобряет как "скакание" с места на место, так и передачу

работы другому из-за карьерных соображений. Целью должен быть

низкий оборот ключевых специалистов и ключевых менеджеров. Никакой

менеджер не добьется успеха без подходящих технических знаний и

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

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

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

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

касающихся окружения, в котором они работают.

Когда требуется предложить нечто новое, на передний план выходят

основные специалисты - аналитики, разработчики, программисты. Именно

они должны решить трудную и критическую задачу внедрения новой

технологии. Это те люди, которые должны овладеть новыми методами и

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

эти люди сделали большой личный вклад в создание старых методов и

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

помощью старых методов. Так же обстоит дело и с многими менеджерами.

Естественно у таких людей есть страх перед изменениями. Он может

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

нежеланию признать проблемы, вызванные старыми методами. Естественно,

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

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

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

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

разработать подходящую схему перехода. Альтернативой будет

организационный паралич и уход самых способных людей из обоих групп.

Тем и другим следует знать, что самые удачливые из "старых ворчунов"

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

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

самым стойким и разумным сторонником перемен. Он будет обладать

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

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

радикальных изменений должны осознать, что гораздо чаще нужен

переход, предполагающий постепенное внедрение новых методов.

С другой стороны, те, кто не желает перемен, должны поискать для

себя такие области, где это возможно, чем вести ожесточенные,

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

совершенно иные условия для успешного проекта.

11.5 Свод правил

В этой главе мы затронули много тем, но как правило не давали

настоятельных и конкретных рекомендаций по проектированию. Это

соответствует моему убеждению, что нет "единственно верного решения".

Принципы и приемы следует применять тем способом, который лучше

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

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

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

опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.

Эти правила можно использовать в качестве отправной точки в

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

или в качестве проверочного списка. Подчеркну еще раз, что они не

являются универсальными правилами и не могут заменить размышления.

- Узнайте, что вам предстоит создать.

- Ставьте определенные и осязаемые цели.

- Не пытайтесь с помощью технических приемов решить социальные

проблемы.

- Рассчитывайте на большой срок

- в проектировании, и

- управлении людьми.

- Используйте существующие системы в качестве моделей, источника

вдохновения и отправной точки.

- Проектируйте в расчете на изменения:

- гибкость,

- расширяемость,

- переносимость, и

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

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

Blog

* законченный учебник и руководство по языку