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

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

11.5 Свод правил

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

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

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

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

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

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

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

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

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

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

- гибкость,

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

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

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

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

Поощряйте и вознаграждайте повторное использование

- проектов,

- библиотек, и

- классов.

Сосредоточьтесь на проектировании компоненты.

- Используйте классы для представления понятий.

- Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.

- Проводите строгую типизацию интерфейсов всегда, когда это возможно.

- Используйте в интерфейсах типы из области приложения всегда, когда это возможно.

Многократно исследуйте и уточняйте как проект, так и реализацию.

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

- проекта, и

- реализации.

Экспериментируйте, анализируйте и проводите тестирование на самом раннем возможном этапе.

Стремитесь к простоте, максимальной простоте, но не сверх того.

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

Не забывайте об эффективности.

Сохраняйте уровень формализации, соответствующим размеру проекта.

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

11.6 Список литературы с комментариями

В этой главе мы только поверхностно затронули вопросы проектирования и управления программными проектами. По этой причине ниже предлагается список литературы с комментариями. Значительно более обширный список литературы с комментариями можно найти в [2].

[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for Reusable Object-Oriented Software. Proc. OOPSL

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

[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. OOPSLA87 (Addendum). Orlando, Florida. pp

1 7-34.

Исследуется, как использование наследования может повредить концепции абстрактных данных. Укажем, что в С++ есть специальные языковые средства, помогающие избежать большинство указанных проблем ($$1 2.2.5).

[8] C. N. Parkinson: Parkinsons 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).

[1 0] Alan Snyder: Encapsulation and Inheritance in Object-Oriented Programming Languages. Proc. OOPSLA86. Portland, Oregon. pp.38-45.

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

[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener: Designing Object-Oriented Software. Prentice Hall. 1 990.

Описывается антропоморфный метод проектирования основанный на специальных карточках CRC (Classes, Responsibilities, Collaboration) (т.е. Классы, Ответственность, Сотрудничество). Текст, а может быть и сам метод тяготеет к языку Smalltalk.