Страница:
стадиях проекта. Чтобы завершить такую "стандартизацию" процесса
создания программ, можно было бы ввести стандарты на документацию
(в том числе правила на правописание и грамматику и соглашения о
формате документации), а так же стандарты на общий вид программ
(в том числе указания какие средства языка следует использовать,
а какие нет, перечисление допустимых библиотек и тех, которые не нужно
использовать, соглашения об именовании функций, типов, переменных,
правила расположения текста программы и т.д.).
Все это может способствовать успеху проекта. По крайней мере,
было бы явной глупостью, браться за проект системы, которая
предположительно будет иметь порядка десяти миллионов строк текста,
над которой будут работать сотни человек, и которую будут
сопровождать тысячи человек в течении десятилетий, не имея достаточно
хорошо определенного и строгого плана по всем перечисленным выше
позициям.
К счастью, большинство систем не относится к этой категории.
Тем не менее, если решено, что данный метод проектирования или
следование указанным образцам в программировании и документации
являются "правильными", то начинает оказываться давление, чтобы
применять их повсеместно. В небольших проектах это приводит к
нелепым ограничениям и большим накладным расходам. В частности,
это может привести к тому, что мерой развития и успеха становится
не продуктивная работа, а пересылка бумажек и заполнение различных
бланков. Если это случится, то в таком проекте настоящих
программистов и разработчиков вытеснят бюрократы.
Когда происходит такое нелепое злоупотребление методами
проектирования (по всей видимости совершенно разумными), то неудача
проекта становится оправданием отказа от практически всякой
формализации процесса разработки программного обеспечения. Это,
в свою очередь, ведет к такой путанице и таким провалам, которые
как раз и должен был предотвратить надлежащий метод проектирования.
Основная проблема состоит в определении степени формализации,
пригодной для процесса развития конкретного проекта. Не рассчитывайте
легко найти ее решение. По сути для малого проекта каждый метод
может сработать. Еще хуже то, что похоже практически каждый метод,
даже если он плохо продуман и жесток по отношению к исполнителям,
может сработать для большого проекта, если вы готовы затратить
уйму времени и денег.
В процессе развития программного обеспечения главная задача -
сохранить целостность проекта. Трудность этой задачи зависит
нелинейно от размера проекта. Сформулировать и сохранить основные
установки в большом проекте может только один человек или маленькая
группа. Большинство людей тратит столько времени на решение
подзадач, технические детали, повседневную административную работу,
что общие цели проекта легко забывает или заменяет их на более
локальные и близкие цели. Верный путь к неудаче, когда нет человека
или группы с прямым заданием следить за целостностью проекта.
Верный путь к неудаче, когда у такого человека или группы нет
средств воздействовать на проект в целом.
Отсутствие согласованных дальних целей намного более опасно
для проекта и организации, чем отсутствие какого-либо одного
конкретного свойства. Небольшая группа людей должна сформулировать
такие общие цели, постоянно держать их в уме, составить документы,
содержащие самое общее описание проекта, составить пояснения к
основным понятиям, и вообще, помогать всем остальным помнить о
назначении проекта.
Описанный здесь метод проектирования рассчитан на искусных
разработчиков и программистов, поэтому от их подбора зависит
успех организации.
Менеджеры часто забывают, что организация состоит из
индивидуумов. Распространено мнение, что программисты равны и
взаимозаменяемы. Это заблуждение может погубить организацию за счет
вытеснения многих самых активных сотрудников и принуждения
остальных работать над задачами значительно ниже их уровня.
Индивидуумы взаимозаменяемы только, если им не дают применить
свой талант, который поднимает их над общим минимальным уровнем,
необходимым для решения данной задачи. Поэтому миф о взаимозаменяемости
бесчеловечен и по сути своей расточителен.
Многие системы оценок производительности программиста поощряют
расточительность и не могут учесть существенный личный вклад
человека. Самым очевидным примером служит широко распространенная
практика оценивать успех в количестве запрограммированных строк,
выданных страниц документации, пропущенных тестов и т.п.
Такие цифры эффектно выглядят на диаграммах, но имеют самое
отдаленное отношение к действительности. Например, если
производительность измерять числом запрограммированных строк, то
удачное повторное использование ухудшит оценку труда программиста.
Обычно тот же эффект будет иметь удачное применение лучших приемов
в процессе перепроектирования большой части системы.
Качество результата измерить значительно труднее, чем количество,
и вознаграждать исполнителя или группу следует за качество их труда,
а не на основе грубых количественных оценок. К сожалению, насколько
известно, практическая разработка способов оценки качества еще не
началась. К тому же оценки, которые неполно описывают состояние
проекта, могут исказить процесс его развития. Люди приспосабливаются,
чтобы уложиться в отведенный срок и перестраивают свою работу в
соответствии с оценками производительности, в результате страдает
общая целостность системы и ее производительность. Например, если
отведен срок для выявления определенного числа ошибок, то для того,
чтобы уложиться в него, активно используют проверки на стадии
выполнения, что ухудшает производительность системы. Обратно, если
учитываются только характеристики системы на стадии выполнения, то
число невыявленных ошибок будет расти при условии недостатка
времени у исполнителей. Отсутствие хороших и разумных оценок
качества повышает требования к технической квалификации менеджеров,
иначе будет постоянная тенденция поощрять произвольную активность,
а не реальный прогресс. Не надо забывать, что менеджеры тоже люди,
и они должны по крайней мере настолько разбираться в новых
технологиях, как и те, кем они управляют.
Здесь, как и в других аспектах процесса развития программного
обеспечения, следует рассматривать большие временные сроки. По сути
невозможно указать производительность человека на основе его
работы за год. Однако, многие сотрудники имеют карточку своих
достижений за большой период, и она может послужить надежным указанием
для предсказания их производительности. Если не принимать во внимание
такие карточки, что и делается, когда сотрудников считают
взаимозаменяемыми спицами в колесе организации, то у менеджера
остаются только вводящие в заблуждения количественные оценки.
Если мы рассматриваем только достаточно большие временные
сроки и отказываемся от методов управления, рассчитанных на
"взаимозаменяемых недоумков", то надо признать, что индивидууму
(как разработчику или программисту, так и менеджеру) нужен большой
срок, чтобы дорасти до более интересной и важной работы. Такой
подход не одобряет как "скакание" с места на место, так и передачу
работы другому из-за карьерных соображений. Целью должен быть
низкий оборот ключевых специалистов и ключевых менеджеров. Никакой
менеджер не добьется успеха без подходящих технических знаний и
взаимопонимания с основными разработчиками и программистами.
В тоже время, в конечном счете никакая группа разработчиков или
программистов не добьется успеха без поддержки компетентных
менеджеров и без понимания хотя бы основных нетехнических вопросов,
касающихся окружения, в котором они работают.
Когда требуется предложить нечто новое, на передний план выходят
основные специалисты - аналитики, разработчики, программисты. Именно
они должны решить трудную и критическую задачу внедрения новой
технологии. Это те люди, которые должны овладеть новыми методами и
во многих случаях забыть старые привычки. Это не так легко. Ведь
эти люди сделали большой личный вклад в создание старых методов и
свою репутацию как специалиста обосновывают успехами, полученными с
помощью старых методов. Так же обстоит дело и с многими менеджерами.
Естественно у таких людей есть страх перед изменениями. Он может
привести к преувеличению проблем, возникающих при изменениях, и к
нежеланию признать проблемы, вызванные старыми методами. Естественно,
с другой стороны люди, выступающие за изменения, могут переоценивать
выгоды, которые принесут изменения, и недооценивать возникающие
здесь проблемы. Эти две группы людей должны общаться, они должны
научиться говорить на одном языке и должны помочь друг другу
разработать подходящую схему перехода. Альтернативой будет
организационный паралич и уход самых способных людей из обоих групп.
Тем и другим следует знать, что самые удачливые из "старых ворчунов"
могли быть "молодыми львами" в прошлом году, и если человеку дали
возможность научиться без всяких издевательств, то он может стать
самым стойким и разумным сторонником перемен. Он будет обладать
неоценимыми свойствами здорового скептицизма, знания пользователей
и понимания организационных препятствий. Сторонники немедленных и
радикальных изменений должны осознать, что гораздо чаще нужен
переход, предполагающий постепенное внедрение новых методов.
С другой стороны, те, кто не желает перемен, должны поискать для
себя такие области, где это возможно, чем вести ожесточенные,
арьергардные бои в той области, где новые требования уже задали
совершенно иные условия для успешного проекта.
В этой главе мы затронули много тем, но как правило не давали
настоятельных и конкретных рекомендаций по проектированию. Это
соответствует моему убеждению, что нет "единственно верного решения".
Принципы и приемы следует применять тем способом, который лучше
подходит для конкретных задач. Для этого нужен вкус, опыт и разум.
Все-таки можно указать некоторый свод правил, который разработчик
может использовать в качестве ориентиров, пока не наберется достаточно
опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.
Эти правила можно использовать в качестве отправной точки в
процессе выработки основных направлений для проекта или организации
или в качестве проверочного списка. Подчеркну еще раз, что они не
являются универсальными правилами и не могут заменить размышления.
- Узнайте, что вам предстоит создать.
- Ставьте определенные и осязаемые цели.
- Не пытайтесь с помощью технических приемов решить социальные
проблемы.
- Рассчитывайте на большой срок
- в проектировании, и
- управлении людьми.
- Используйте существующие системы в качестве моделей, источника
вдохновения и отправной точки.
- Проектируйте в расчете на изменения:
- гибкость,
- расширяемость,
- переносимость, и
- повторное использование.
- Документируйте, предлагайте и поддерживайте повторно используемые
компоненты.
- Поощряйте и вознаграждайте повторное использование
- проектов,
- библиотек, и
- классов.
- Сосредоточьтесь на проектировании компоненты.
- Используйте классы для представления понятий.
- Определяйте интерфейсы так, чтобы сделать открытым минимальный
объем информации, требуемой для интерфейса.
- Проводите строгую типизацию интерфейсов всегда, когда это
возможно.
- Используйте в интерфейсах типы из области приложения всегда,
когда это возможно.
- Многократно исследуйте и уточняйте как проект, так и реализацию.
- Используйте лучшие доступные средства для проверки и анализа
- проекта, и
- реализации.
- Экспериментируйте, анализируйте и проводите тестирование на
самом раннем возможном этапе.
- Стремитесь к простоте, максимальной простоте, но не сверх того.
- Не разрастайтесь, не добавляйте возможности "на всякий случай".
- Не забывайте об эффективности.
- Сохраняйте уровень формализации, соответствующим размеру проекта.
- Не забывайте, что разработчики, программисты и даже менеджеры
остаются людьми.
Еще некоторые правила можно найти в $$12.5
В этой главе мы только поверхностно затронули вопросы проектирования
и управления программными проектами. По этой причине ниже предлагается
список литературы с комментариями. Значительно более обширный список
литературы с комментариями можно найти в [2].
[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for
Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa,
Canada. pp. 12-27.
Описание модели итеративного проектирования и повторного
проектирования с некоторыми примерами и обсуждением результатов.
[2] Grady Booch: Object Oriented Design. Benjamin Cummings. 1991.
В этой книге есть детальное описание проектирования, определенный
метод проектирования с графической формой записи и несколько
больших примеров проекта, записанных на различных языках. Это
превосходная книга, которая во многом повлияла на эту главу. В ней
более глубоко рассматриваются многие из затронутых здесь вопросов.
[3] Fred Brooks: The Mythical Man Month. Addison Wesley. 1982.
Каждый должен перечитывать эту книгу раз в пару лет.
Предостережение от высокомерия. Она несколько устарела в
технических вопросах, но совершенно не устарела во всем, что
касается отдельного работника, организации и вопросов размера.
[4] Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4.
April 1987.
Сводка различных подходов к процессу развития больших программных
систем с очень полезным предостережением от веры в магические
рецепты ("золотая пуля").
[5] De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987.
Одна из немногих книг, посвященных роли человеческого фактора
в производстве программного обеспечения. Необходима для каждого
менеджера. Достаточно успокаивающая для чтения перед сном.
Лекарство от многих глупостей.
[6] Ron Kerr: A Materialistic View of the Software "Engineering"
Analogy. in SIGPLAN Notices, March 1987. pp 123-125.
Использование аналогии в этой и следующей главах во многом
обязано наблюдениям из указанной статьи, а так же беседам с
Р. Керром, которые этому предшествовали.
[7] Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87
(Addendum). Orlando, Florida. pp 17-34.
Исследуется как использование наследования может повредить
концепции абстрактных данных. Укажем, что в С++ есть специальные
языковые средства, помогающие избежать большинство указанных
проблем ($$12.2.5).
[8] C. N. Parkinson: Parkinson's Law and other Studies in
Administration. Houghton-Mifflin. Boston. 1957.
Одно из забавных и самых язвительных описаний бед, к которым
приводит процесс администрирования.
[9] Bertrand Meyer: Object Oriented Software Construction.
Prentice Hall. 1988.
Страницы 1-64 и 323-334 содержат хорошее описание одного взгляда
на объектно-ориентированное программирование и проектирование,
а также много здравых, практических советов. В остальной части
книги описывается язык Эйффель (Eiffel).
[10] Alan Snyder: Encapsulation and Inheritance in Object-Oriented
Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45.
Возможно первое хорошее описание взаимодействия оболочки и
наследования. В статье так же на хорошем уровне рассматриваются
некоторые понятия, связанные с множественным наследованием.
[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener:
Designing Object-Oriented Software. Prentice Hall. 1990.
Описывается антропоморфный метод проектирования основанный на
специальных карточках CRC (Classes, Responsibilities,
Collaboration) (т.е. Классы, Ответственность, Сотрудничество).
Текст, а может быть и сам метод тяготеет к языку Smalltalk.
Стремись к простоте, максимальной простоте, но не сверх того.
- А. Эйнштейн
Эта глава посвящена связи между проектированием и языком
программирования С++. В ней исследуется применение классов при
проектировании и указываются определенные виды зависимостей, которые
следует выделять как внутри класса, так и между классами. Изучается
роль статического контроля типов. Исследуется применение наследования
и связь наследования и принадлежности. Обсуждается понятие компонента
и даются некоторые образцы для интерфейсов.
Если бы мне надо было построить мост, то я серьезно подумал бы, из
какого материала его строить, и проект моста сильно зависел бы от
выбранного материала, а, следовательно, разумные проекты каменного
моста отличаются от разумных проектов металлического моста или
от разумных проектов деревянного моста и т.д. Не стоит
рассчитывать на выбор подходящего для моста материала без определенных
знаний о материалах и их использовании. Конечно, вам не надо быть
специалистом плотником для проектирования деревянного моста, но вы
должны знать основы конструирования из дерева, чтобы предпочесть его
металлу в качестве материала для моста. Более того, хотя для
проектирования деревянного моста вы и не должны быть специалистом
плотником, вам необходимо достаточно детально знать свойства
дерева и еще больше знать о плотниках.
Аналогично, при выборе языка программирования для
определенного программного обеспечения надо знать несколько языков,
а для успешного проектирования программы надо достаточно детально
знать выбранный язык реализации, даже если вам лично не предстоит
написать ни одной строчки программы. Хороший проектировщик моста
ценит свойства используемых им материалов и применяет их для улучшения
проекта. Аналогично, хороший разработчик программ использует сильные
стороны языка реализации и, насколько возможно, стремится избежать такого
его использования, которое вызовет трудности на стадии реализации.
Можно подумать, что так получается естественным образом, если
в проектировании участвует только один разработчик или программист, однако
даже в этом случае программист в силу недостатка опыта или из-за
неоправданной приверженности к стилю программирования, рассчитанному на
совершенно другие языки, может сбиться на неверное использование языка.
Если разработчик существенно отличается от программиста, особенно
если у них разная программистская культура, возможность появления
в окончательной версии системы ошибок, неэффективных и неэлегантных решений
почти наверняка превратится в неизбежность.
Итак, чем может помочь разработчику язык программирования? Он
может предоставить такие языковые средства, которые позволят
выразить прямо на языке программирования основные понятия проекта.
Тогда облегчается реализация, проще поддерживать ее соответствие
проекту, проще организовать общение между
разработчиками и программистами, и появляется возможность создать
более совершенные средства как для разработчиков, так и для
программистов.
Например, многие методы проектирования уделяют значительное внимание
зависимостям между различными частями программы (обычно с целью
их уменьшения и гарантии того, что эти части будут понятны и хорошо
определены). Язык, допускающий явное задание интерфейсов между
частями программы, может помочь в этом вопросе
разработчикам. Он может гарантировать, что действительно будут
существовать только предполагаемые зависимости. Поскольку
большинство зависимостей явно выражено в программе на таком языке,
можно разработать средства, читающие программу и выдающие графы
зависимостей. В этом случае разработчику и другим исполнителям легче
уяснить структуру программы. Такие языки программирования как С++
помогают сократить разрыв между проектом и программой, а значит
уменьшают возможность путаницы и недопониманий.
Базовое понятие С++ - это класс. Класс имеет определенный
тип. Кроме того, класс является первичным средством упрятывания
информации. Можно описывать программы в терминах пользовательских
типов и иерархий этих типов. Как встроенные, так и пользовательские
типы подчиняются правилам статического контроля типов. Виртуальные
функции предоставляют, не нарушая правил статических типов,
механизм связывания на этапе выполнения. Шаблоны типа позволяют
создавать параметризованные типы. Особые ситуации позволяют сделать
регулярной реакцию на ошибки. Все эти средства С++ можно
использовать без дополнительных накладных
расходов в сравнении с программой на С. Таковы главнейшие
средства С++, которые должен представлять и учитывать разработчик.
Кроме того, существенно повлиять на принятие решений на стадии
проектирования может наличие доступных больших библиотек
следующего назначения: для работы с матрицами, для связи с
базами данных, для поддержки параллельного
программирования, графические библиотеки и т.д.
Страх перед новизной, непригодный здесь опыт работы на других
языках, в других системах или областях приложения, бедные средства
проектирования - все это приводит к неоптимальному использованию С++.
Следует отметить три момента, когда разработчику не удается
извлечь выгоду из возможностей С++ и учесть ограничения языка:
[1] Игнорирование классов и составление проекта таким образом, что
программистам приходится ограничиваться только С.
[2] Игнорирование производных классов и виртуальных функций,
использование только подмножества абстрактных данных.
[3] Игнорирование статического контроля типов и составление проекта
таким образом, что программисты вынуждены применять динамические
проверки типов.
Обычно указанные моменты возникают у разработчиков, связанных с:
[1] C, или традиционной системой CASE или методами структурного
проектирования;
[2] Адой или методами проектирования с помощью абстракции данных;
[3] языками, близкими Smalltalk или Lisp.
В каждом случае следует решить: неправильно выбран язык
реализации (считая, что метод проектирования выбран верно), или
разработчику не удалось приспособиться и оценить язык (считая, что
язык реализации выбран верно).
Следует сказать, что нет ничего необычного или позорного в
таком расхождении. Просто это расхождение, которое приведет к
неоптимальному проекту, возложит дополнительную работу на
программистов, а в случае, когда структура понятий проекта
значительно беднее структуры языка С++, то и на самих разработчиков.
Отметим, что необязательно все программы должны
структурироваться опираясь на понятия классов и (или) иерархий классов,
и необязательно всякая программа должна использовать все средства,
предоставляемые С++. Как раз наоборот, для успеха проекта необходимо,
чтобы людям не навязывали использование языковых средств, с которыми
они только познакомились. Цель последующего изложения не в том,
чтобы навязать догматичное использование классов, иерархий и
строго типизированных интерфейсов, а в том, чтобы показать
возможности их использования всюду, где позволяет область
приложения, ограничения С++ и опыт исполнителей. В $$12.1.4 будут
рассмотрены подходы к различному использованию С++ в проекте
под заголовком "Проект-гибрид".
Рассмотрим первый из указанных моментов - игнорирование классов.
В таком случае получившаяся программа на С++ будет приблизительно
эквивалентна С-программе, разработанной по тому же проекту, и,
можно сказать, что они будут приблизительно эквивалентны программам
на Аде или Коболе, разработанным по нему же.
По сути проект составлен как независящий от языка реализации, что
принуждает программиста ограничиваться общим подмножеством языков
С, Ада или Кобол. Здесь есть свои преимущества. Например, получившееся
в результате строгое разделение данных и программного кода позволяет
легко использовать традиционные базы данных, которые разработаны
для таких программ. Поскольку используется ограниченный язык
программирования, от программистов требуется меньше опытности
(или, по крайней мере другой ее уровень). Для многих приложений,
например, для традиционных баз данных, работающих с
файлом последовательно, такой подход вполне разумен, а традиционные
приемы, отработанные за десятилетия, вполне адекватны задаче.
Однако там, где область приложения существенно отличается от
традиционной последовательной обработки записей (или символов),
или сложность задачи выше, как, например, в диалоговой системе
CASE, недостаток языковой поддержки абстрактных данных
из-за отказа от классов (если их не учитывать) повредит
проекту. Сложность задачи не уменьшится, но, поскольку система
реализована на обедненном языке, структура программы плохо будет
отвечать проекту. У нее слишком большой объем, не хватает проверки типов,
и, вообще, она плохо приспособлена для использования различных
вспомогательных средств. Это путь, приводящий к кошмарам при ее
сопровождении.
Обычно для преодоления указанных трудностей создают специальные
средства, поддерживающие понятия, используемые в проекте. Благодаря
им создаются конструкции более высокого
уровня и организуются проверки с целью компенсировать дефекты
(или сознательное обеднение) языка реализации. Так метод
проектирования становится самоцелью, и для него создается специальный
язык программирования. Такие языки программирования в большинстве
случаев являются плохой заменой широко распространенных языков
программирования общего назначения, которые сопровождаются
подходящими средствами проектирования. Использовать С++ с таким
ограничением, которое должно компенсироваться при проектировании
специальными средствами, бессмысленно. Хотя несоответствие между
языком программирования и средствами проектирования может быть просто
стадией процесса перехода, а значит временным явлением.
Самой типичной причиной игнорирования классов при проектировании
является простая инерция. Традиционные языки программирования не
предоставляют понятия класса, и в традиционных методах проектирования
создания программ, можно было бы ввести стандарты на документацию
(в том числе правила на правописание и грамматику и соглашения о
формате документации), а так же стандарты на общий вид программ
(в том числе указания какие средства языка следует использовать,
а какие нет, перечисление допустимых библиотек и тех, которые не нужно
использовать, соглашения об именовании функций, типов, переменных,
правила расположения текста программы и т.д.).
Все это может способствовать успеху проекта. По крайней мере,
было бы явной глупостью, браться за проект системы, которая
предположительно будет иметь порядка десяти миллионов строк текста,
над которой будут работать сотни человек, и которую будут
сопровождать тысячи человек в течении десятилетий, не имея достаточно
хорошо определенного и строгого плана по всем перечисленным выше
позициям.
К счастью, большинство систем не относится к этой категории.
Тем не менее, если решено, что данный метод проектирования или
следование указанным образцам в программировании и документации
являются "правильными", то начинает оказываться давление, чтобы
применять их повсеместно. В небольших проектах это приводит к
нелепым ограничениям и большим накладным расходам. В частности,
это может привести к тому, что мерой развития и успеха становится
не продуктивная работа, а пересылка бумажек и заполнение различных
бланков. Если это случится, то в таком проекте настоящих
программистов и разработчиков вытеснят бюрократы.
Когда происходит такое нелепое злоупотребление методами
проектирования (по всей видимости совершенно разумными), то неудача
проекта становится оправданием отказа от практически всякой
формализации процесса разработки программного обеспечения. Это,
в свою очередь, ведет к такой путанице и таким провалам, которые
как раз и должен был предотвратить надлежащий метод проектирования.
Основная проблема состоит в определении степени формализации,
пригодной для процесса развития конкретного проекта. Не рассчитывайте
легко найти ее решение. По сути для малого проекта каждый метод
может сработать. Еще хуже то, что похоже практически каждый метод,
даже если он плохо продуман и жесток по отношению к исполнителям,
может сработать для большого проекта, если вы готовы затратить
уйму времени и денег.
В процессе развития программного обеспечения главная задача -
сохранить целостность проекта. Трудность этой задачи зависит
нелинейно от размера проекта. Сформулировать и сохранить основные
установки в большом проекте может только один человек или маленькая
группа. Большинство людей тратит столько времени на решение
подзадач, технические детали, повседневную административную работу,
что общие цели проекта легко забывает или заменяет их на более
локальные и близкие цели. Верный путь к неудаче, когда нет человека
или группы с прямым заданием следить за целостностью проекта.
Верный путь к неудаче, когда у такого человека или группы нет
средств воздействовать на проект в целом.
Отсутствие согласованных дальних целей намного более опасно
для проекта и организации, чем отсутствие какого-либо одного
конкретного свойства. Небольшая группа людей должна сформулировать
такие общие цели, постоянно держать их в уме, составить документы,
содержащие самое общее описание проекта, составить пояснения к
основным понятиям, и вообще, помогать всем остальным помнить о
назначении проекта.
Описанный здесь метод проектирования рассчитан на искусных
разработчиков и программистов, поэтому от их подбора зависит
успех организации.
Менеджеры часто забывают, что организация состоит из
индивидуумов. Распространено мнение, что программисты равны и
взаимозаменяемы. Это заблуждение может погубить организацию за счет
вытеснения многих самых активных сотрудников и принуждения
остальных работать над задачами значительно ниже их уровня.
Индивидуумы взаимозаменяемы только, если им не дают применить
свой талант, который поднимает их над общим минимальным уровнем,
необходимым для решения данной задачи. Поэтому миф о взаимозаменяемости
бесчеловечен и по сути своей расточителен.
Многие системы оценок производительности программиста поощряют
расточительность и не могут учесть существенный личный вклад
человека. Самым очевидным примером служит широко распространенная
практика оценивать успех в количестве запрограммированных строк,
выданных страниц документации, пропущенных тестов и т.п.
Такие цифры эффектно выглядят на диаграммах, но имеют самое
отдаленное отношение к действительности. Например, если
производительность измерять числом запрограммированных строк, то
удачное повторное использование ухудшит оценку труда программиста.
Обычно тот же эффект будет иметь удачное применение лучших приемов
в процессе перепроектирования большой части системы.
Качество результата измерить значительно труднее, чем количество,
и вознаграждать исполнителя или группу следует за качество их труда,
а не на основе грубых количественных оценок. К сожалению, насколько
известно, практическая разработка способов оценки качества еще не
началась. К тому же оценки, которые неполно описывают состояние
проекта, могут исказить процесс его развития. Люди приспосабливаются,
чтобы уложиться в отведенный срок и перестраивают свою работу в
соответствии с оценками производительности, в результате страдает
общая целостность системы и ее производительность. Например, если
отведен срок для выявления определенного числа ошибок, то для того,
чтобы уложиться в него, активно используют проверки на стадии
выполнения, что ухудшает производительность системы. Обратно, если
учитываются только характеристики системы на стадии выполнения, то
число невыявленных ошибок будет расти при условии недостатка
времени у исполнителей. Отсутствие хороших и разумных оценок
качества повышает требования к технической квалификации менеджеров,
иначе будет постоянная тенденция поощрять произвольную активность,
а не реальный прогресс. Не надо забывать, что менеджеры тоже люди,
и они должны по крайней мере настолько разбираться в новых
технологиях, как и те, кем они управляют.
Здесь, как и в других аспектах процесса развития программного
обеспечения, следует рассматривать большие временные сроки. По сути
невозможно указать производительность человека на основе его
работы за год. Однако, многие сотрудники имеют карточку своих
достижений за большой период, и она может послужить надежным указанием
для предсказания их производительности. Если не принимать во внимание
такие карточки, что и делается, когда сотрудников считают
взаимозаменяемыми спицами в колесе организации, то у менеджера
остаются только вводящие в заблуждения количественные оценки.
Если мы рассматриваем только достаточно большие временные
сроки и отказываемся от методов управления, рассчитанных на
"взаимозаменяемых недоумков", то надо признать, что индивидууму
(как разработчику или программисту, так и менеджеру) нужен большой
срок, чтобы дорасти до более интересной и важной работы. Такой
подход не одобряет как "скакание" с места на место, так и передачу
работы другому из-за карьерных соображений. Целью должен быть
низкий оборот ключевых специалистов и ключевых менеджеров. Никакой
менеджер не добьется успеха без подходящих технических знаний и
взаимопонимания с основными разработчиками и программистами.
В тоже время, в конечном счете никакая группа разработчиков или
программистов не добьется успеха без поддержки компетентных
менеджеров и без понимания хотя бы основных нетехнических вопросов,
касающихся окружения, в котором они работают.
Когда требуется предложить нечто новое, на передний план выходят
основные специалисты - аналитики, разработчики, программисты. Именно
они должны решить трудную и критическую задачу внедрения новой
технологии. Это те люди, которые должны овладеть новыми методами и
во многих случаях забыть старые привычки. Это не так легко. Ведь
эти люди сделали большой личный вклад в создание старых методов и
свою репутацию как специалиста обосновывают успехами, полученными с
помощью старых методов. Так же обстоит дело и с многими менеджерами.
Естественно у таких людей есть страх перед изменениями. Он может
привести к преувеличению проблем, возникающих при изменениях, и к
нежеланию признать проблемы, вызванные старыми методами. Естественно,
с другой стороны люди, выступающие за изменения, могут переоценивать
выгоды, которые принесут изменения, и недооценивать возникающие
здесь проблемы. Эти две группы людей должны общаться, они должны
научиться говорить на одном языке и должны помочь друг другу
разработать подходящую схему перехода. Альтернативой будет
организационный паралич и уход самых способных людей из обоих групп.
Тем и другим следует знать, что самые удачливые из "старых ворчунов"
могли быть "молодыми львами" в прошлом году, и если человеку дали
возможность научиться без всяких издевательств, то он может стать
самым стойким и разумным сторонником перемен. Он будет обладать
неоценимыми свойствами здорового скептицизма, знания пользователей
и понимания организационных препятствий. Сторонники немедленных и
радикальных изменений должны осознать, что гораздо чаще нужен
переход, предполагающий постепенное внедрение новых методов.
С другой стороны, те, кто не желает перемен, должны поискать для
себя такие области, где это возможно, чем вести ожесточенные,
арьергардные бои в той области, где новые требования уже задали
совершенно иные условия для успешного проекта.
В этой главе мы затронули много тем, но как правило не давали
настоятельных и конкретных рекомендаций по проектированию. Это
соответствует моему убеждению, что нет "единственно верного решения".
Принципы и приемы следует применять тем способом, который лучше
подходит для конкретных задач. Для этого нужен вкус, опыт и разум.
Все-таки можно указать некоторый свод правил, который разработчик
может использовать в качестве ориентиров, пока не наберется достаточно
опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.
Эти правила можно использовать в качестве отправной точки в
процессе выработки основных направлений для проекта или организации
или в качестве проверочного списка. Подчеркну еще раз, что они не
являются универсальными правилами и не могут заменить размышления.
- Узнайте, что вам предстоит создать.
- Ставьте определенные и осязаемые цели.
- Не пытайтесь с помощью технических приемов решить социальные
проблемы.
- Рассчитывайте на большой срок
- в проектировании, и
- управлении людьми.
- Используйте существующие системы в качестве моделей, источника
вдохновения и отправной точки.
- Проектируйте в расчете на изменения:
- гибкость,
- расширяемость,
- переносимость, и
- повторное использование.
- Документируйте, предлагайте и поддерживайте повторно используемые
компоненты.
- Поощряйте и вознаграждайте повторное использование
- проектов,
- библиотек, и
- классов.
- Сосредоточьтесь на проектировании компоненты.
- Используйте классы для представления понятий.
- Определяйте интерфейсы так, чтобы сделать открытым минимальный
объем информации, требуемой для интерфейса.
- Проводите строгую типизацию интерфейсов всегда, когда это
возможно.
- Используйте в интерфейсах типы из области приложения всегда,
когда это возможно.
- Многократно исследуйте и уточняйте как проект, так и реализацию.
- Используйте лучшие доступные средства для проверки и анализа
- проекта, и
- реализации.
- Экспериментируйте, анализируйте и проводите тестирование на
самом раннем возможном этапе.
- Стремитесь к простоте, максимальной простоте, но не сверх того.
- Не разрастайтесь, не добавляйте возможности "на всякий случай".
- Не забывайте об эффективности.
- Сохраняйте уровень формализации, соответствующим размеру проекта.
- Не забывайте, что разработчики, программисты и даже менеджеры
остаются людьми.
Еще некоторые правила можно найти в $$12.5
В этой главе мы только поверхностно затронули вопросы проектирования
и управления программными проектами. По этой причине ниже предлагается
список литературы с комментариями. Значительно более обширный список
литературы с комментариями можно найти в [2].
[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for
Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa,
Canada. pp. 12-27.
Описание модели итеративного проектирования и повторного
проектирования с некоторыми примерами и обсуждением результатов.
[2] Grady Booch: Object Oriented Design. Benjamin Cummings. 1991.
В этой книге есть детальное описание проектирования, определенный
метод проектирования с графической формой записи и несколько
больших примеров проекта, записанных на различных языках. Это
превосходная книга, которая во многом повлияла на эту главу. В ней
более глубоко рассматриваются многие из затронутых здесь вопросов.
[3] Fred Brooks: The Mythical Man Month. Addison Wesley. 1982.
Каждый должен перечитывать эту книгу раз в пару лет.
Предостережение от высокомерия. Она несколько устарела в
технических вопросах, но совершенно не устарела во всем, что
касается отдельного работника, организации и вопросов размера.
[4] Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4.
April 1987.
Сводка различных подходов к процессу развития больших программных
систем с очень полезным предостережением от веры в магические
рецепты ("золотая пуля").
[5] De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987.
Одна из немногих книг, посвященных роли человеческого фактора
в производстве программного обеспечения. Необходима для каждого
менеджера. Достаточно успокаивающая для чтения перед сном.
Лекарство от многих глупостей.
[6] Ron Kerr: A Materialistic View of the Software "Engineering"
Analogy. in SIGPLAN Notices, March 1987. pp 123-125.
Использование аналогии в этой и следующей главах во многом
обязано наблюдениям из указанной статьи, а так же беседам с
Р. Керром, которые этому предшествовали.
[7] Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87
(Addendum). Orlando, Florida. pp 17-34.
Исследуется как использование наследования может повредить
концепции абстрактных данных. Укажем, что в С++ есть специальные
языковые средства, помогающие избежать большинство указанных
проблем ($$12.2.5).
[8] C. N. Parkinson: Parkinson's Law and other Studies in
Administration. Houghton-Mifflin. Boston. 1957.
Одно из забавных и самых язвительных описаний бед, к которым
приводит процесс администрирования.
[9] Bertrand Meyer: Object Oriented Software Construction.
Prentice Hall. 1988.
Страницы 1-64 и 323-334 содержат хорошее описание одного взгляда
на объектно-ориентированное программирование и проектирование,
а также много здравых, практических советов. В остальной части
книги описывается язык Эйффель (Eiffel).
[10] Alan Snyder: Encapsulation and Inheritance in Object-Oriented
Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45.
Возможно первое хорошее описание взаимодействия оболочки и
наследования. В статье так же на хорошем уровне рассматриваются
некоторые понятия, связанные с множественным наследованием.
[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener:
Designing Object-Oriented Software. Prentice Hall. 1990.
Описывается антропоморфный метод проектирования основанный на
специальных карточках CRC (Classes, Responsibilities,
Collaboration) (т.е. Классы, Ответственность, Сотрудничество).
Текст, а может быть и сам метод тяготеет к языку Smalltalk.
Стремись к простоте, максимальной простоте, но не сверх того.
- А. Эйнштейн
Эта глава посвящена связи между проектированием и языком
программирования С++. В ней исследуется применение классов при
проектировании и указываются определенные виды зависимостей, которые
следует выделять как внутри класса, так и между классами. Изучается
роль статического контроля типов. Исследуется применение наследования
и связь наследования и принадлежности. Обсуждается понятие компонента
и даются некоторые образцы для интерфейсов.
Если бы мне надо было построить мост, то я серьезно подумал бы, из
какого материала его строить, и проект моста сильно зависел бы от
выбранного материала, а, следовательно, разумные проекты каменного
моста отличаются от разумных проектов металлического моста или
от разумных проектов деревянного моста и т.д. Не стоит
рассчитывать на выбор подходящего для моста материала без определенных
знаний о материалах и их использовании. Конечно, вам не надо быть
специалистом плотником для проектирования деревянного моста, но вы
должны знать основы конструирования из дерева, чтобы предпочесть его
металлу в качестве материала для моста. Более того, хотя для
проектирования деревянного моста вы и не должны быть специалистом
плотником, вам необходимо достаточно детально знать свойства
дерева и еще больше знать о плотниках.
Аналогично, при выборе языка программирования для
определенного программного обеспечения надо знать несколько языков,
а для успешного проектирования программы надо достаточно детально
знать выбранный язык реализации, даже если вам лично не предстоит
написать ни одной строчки программы. Хороший проектировщик моста
ценит свойства используемых им материалов и применяет их для улучшения
проекта. Аналогично, хороший разработчик программ использует сильные
стороны языка реализации и, насколько возможно, стремится избежать такого
его использования, которое вызовет трудности на стадии реализации.
Можно подумать, что так получается естественным образом, если
в проектировании участвует только один разработчик или программист, однако
даже в этом случае программист в силу недостатка опыта или из-за
неоправданной приверженности к стилю программирования, рассчитанному на
совершенно другие языки, может сбиться на неверное использование языка.
Если разработчик существенно отличается от программиста, особенно
если у них разная программистская культура, возможность появления
в окончательной версии системы ошибок, неэффективных и неэлегантных решений
почти наверняка превратится в неизбежность.
Итак, чем может помочь разработчику язык программирования? Он
может предоставить такие языковые средства, которые позволят
выразить прямо на языке программирования основные понятия проекта.
Тогда облегчается реализация, проще поддерживать ее соответствие
проекту, проще организовать общение между
разработчиками и программистами, и появляется возможность создать
более совершенные средства как для разработчиков, так и для
программистов.
Например, многие методы проектирования уделяют значительное внимание
зависимостям между различными частями программы (обычно с целью
их уменьшения и гарантии того, что эти части будут понятны и хорошо
определены). Язык, допускающий явное задание интерфейсов между
частями программы, может помочь в этом вопросе
разработчикам. Он может гарантировать, что действительно будут
существовать только предполагаемые зависимости. Поскольку
большинство зависимостей явно выражено в программе на таком языке,
можно разработать средства, читающие программу и выдающие графы
зависимостей. В этом случае разработчику и другим исполнителям легче
уяснить структуру программы. Такие языки программирования как С++
помогают сократить разрыв между проектом и программой, а значит
уменьшают возможность путаницы и недопониманий.
Базовое понятие С++ - это класс. Класс имеет определенный
тип. Кроме того, класс является первичным средством упрятывания
информации. Можно описывать программы в терминах пользовательских
типов и иерархий этих типов. Как встроенные, так и пользовательские
типы подчиняются правилам статического контроля типов. Виртуальные
функции предоставляют, не нарушая правил статических типов,
механизм связывания на этапе выполнения. Шаблоны типа позволяют
создавать параметризованные типы. Особые ситуации позволяют сделать
регулярной реакцию на ошибки. Все эти средства С++ можно
использовать без дополнительных накладных
расходов в сравнении с программой на С. Таковы главнейшие
средства С++, которые должен представлять и учитывать разработчик.
Кроме того, существенно повлиять на принятие решений на стадии
проектирования может наличие доступных больших библиотек
следующего назначения: для работы с матрицами, для связи с
базами данных, для поддержки параллельного
программирования, графические библиотеки и т.д.
Страх перед новизной, непригодный здесь опыт работы на других
языках, в других системах или областях приложения, бедные средства
проектирования - все это приводит к неоптимальному использованию С++.
Следует отметить три момента, когда разработчику не удается
извлечь выгоду из возможностей С++ и учесть ограничения языка:
[1] Игнорирование классов и составление проекта таким образом, что
программистам приходится ограничиваться только С.
[2] Игнорирование производных классов и виртуальных функций,
использование только подмножества абстрактных данных.
[3] Игнорирование статического контроля типов и составление проекта
таким образом, что программисты вынуждены применять динамические
проверки типов.
Обычно указанные моменты возникают у разработчиков, связанных с:
[1] C, или традиционной системой CASE или методами структурного
проектирования;
[2] Адой или методами проектирования с помощью абстракции данных;
[3] языками, близкими Smalltalk или Lisp.
В каждом случае следует решить: неправильно выбран язык
реализации (считая, что метод проектирования выбран верно), или
разработчику не удалось приспособиться и оценить язык (считая, что
язык реализации выбран верно).
Следует сказать, что нет ничего необычного или позорного в
таком расхождении. Просто это расхождение, которое приведет к
неоптимальному проекту, возложит дополнительную работу на
программистов, а в случае, когда структура понятий проекта
значительно беднее структуры языка С++, то и на самих разработчиков.
Отметим, что необязательно все программы должны
структурироваться опираясь на понятия классов и (или) иерархий классов,
и необязательно всякая программа должна использовать все средства,
предоставляемые С++. Как раз наоборот, для успеха проекта необходимо,
чтобы людям не навязывали использование языковых средств, с которыми
они только познакомились. Цель последующего изложения не в том,
чтобы навязать догматичное использование классов, иерархий и
строго типизированных интерфейсов, а в том, чтобы показать
возможности их использования всюду, где позволяет область
приложения, ограничения С++ и опыт исполнителей. В $$12.1.4 будут
рассмотрены подходы к различному использованию С++ в проекте
под заголовком "Проект-гибрид".
Рассмотрим первый из указанных моментов - игнорирование классов.
В таком случае получившаяся программа на С++ будет приблизительно
эквивалентна С-программе, разработанной по тому же проекту, и,
можно сказать, что они будут приблизительно эквивалентны программам
на Аде или Коболе, разработанным по нему же.
По сути проект составлен как независящий от языка реализации, что
принуждает программиста ограничиваться общим подмножеством языков
С, Ада или Кобол. Здесь есть свои преимущества. Например, получившееся
в результате строгое разделение данных и программного кода позволяет
легко использовать традиционные базы данных, которые разработаны
для таких программ. Поскольку используется ограниченный язык
программирования, от программистов требуется меньше опытности
(или, по крайней мере другой ее уровень). Для многих приложений,
например, для традиционных баз данных, работающих с
файлом последовательно, такой подход вполне разумен, а традиционные
приемы, отработанные за десятилетия, вполне адекватны задаче.
Однако там, где область приложения существенно отличается от
традиционной последовательной обработки записей (или символов),
или сложность задачи выше, как, например, в диалоговой системе
CASE, недостаток языковой поддержки абстрактных данных
из-за отказа от классов (если их не учитывать) повредит
проекту. Сложность задачи не уменьшится, но, поскольку система
реализована на обедненном языке, структура программы плохо будет
отвечать проекту. У нее слишком большой объем, не хватает проверки типов,
и, вообще, она плохо приспособлена для использования различных
вспомогательных средств. Это путь, приводящий к кошмарам при ее
сопровождении.
Обычно для преодоления указанных трудностей создают специальные
средства, поддерживающие понятия, используемые в проекте. Благодаря
им создаются конструкции более высокого
уровня и организуются проверки с целью компенсировать дефекты
(или сознательное обеднение) языка реализации. Так метод
проектирования становится самоцелью, и для него создается специальный
язык программирования. Такие языки программирования в большинстве
случаев являются плохой заменой широко распространенных языков
программирования общего назначения, которые сопровождаются
подходящими средствами проектирования. Использовать С++ с таким
ограничением, которое должно компенсироваться при проектировании
специальными средствами, бессмысленно. Хотя несоответствие между
языком программирования и средствами проектирования может быть просто
стадией процесса перехода, а значит временным явлением.
Самой типичной причиной игнорирования классов при проектировании
является простая инерция. Традиционные языки программирования не
предоставляют понятия класса, и в традиционных методах проектирования