Б. Страуструп - Язык программирования С++ (1119446), страница 84
Текст из файла (страница 84)
Отсутствие хороших и разумных оценок качества повышает требования к техническойквалификации менеджеров, иначе будет постоянная тенденция поощрять произвольную активность, ане реальный прогресс. Не надо забывать, что менеджеры тоже люди, и они должны по крайней меренастолько разбираться в новых технологиях, как и те, кем они управляют.Здесь, как и в других аспектах процесса развития программного обеспечения, следует рассматриватьбольшие временные сроки.
По сути невозможно указать производительность человека на основе егоработы за год. Однако, многие сотрудники имеют карточку своих достижений за большой период, и онаможет послужить надежным указанием для предсказания их производительности. Если не принимать вовнимание такие карточки, что и делается, когда сотрудников считают взаимозаменяемыми спицами вколесе организации, то у менеджера остаются только вводящие в заблуждения количественные оценки.Если мы рассматриваем только достаточно большие временные сроки и отказываемся от методовуправления, рассчитанных на "взаимозаменяемых недоумков", то надо признать, что индивидууму (какразработчику или программисту, так и менеджеру) нужен большой срок, чтобы дорасти до болееинтересной и важной работы.
Такой подход не одобряет как "скакание" с места на место, так и передачуработы другому из-за карьерных соображений. Целью должен быть низкий оборот ключевыхспециалистов и ключевых менеджеров. Никакой менеджер не добьется успеха без подходящихтехнических знаний и взаимопонимания с основными разработчиками и программистами.
В тоже время,в конечном счете никакая группа разработчиков или программистов не добьется успеха без поддержкикомпетентных менеджеров и без понимания хотя бы основных нетехнических вопросов, касающихсяокружения, в котором они работают.302Бьерн Страуструп.Язык программирования С++Когда требуется предложить нечто новое, на передний план выходят основные специалисты аналитики, разработчики, программисты.
Именно они должны решить трудную и критическую задачувнедрения новой технологии. Это те люди, которые должны овладеть новыми методами и во многихслучаях забыть старые привычки. Это не так легко. Ведь эти люди сделали большой личный вклад всоздание старых методов и свою репутацию как специалиста обосновывают успехами, полученными спомощью старых методов. Так же обстоит дело и с многими менеджерами.Естественно у таких людей есть страх перед изменениями. Он может привести к преувеличениюпроблем, возникающих при изменениях, и к нежеланию признать проблемы, вызванные старымиметодами. Естественно, с другой стороны люди, выступающие за изменения, могут переоцениватьвыгоды, которые принесут изменения, и недооценивать возникающие здесь проблемы.
Эти две группылюдей должны общаться, они должны научиться говорить на одном языке и должны помочь друг другуразработать подходящую схему перехода. Альтернативой будет организационный паралич и уходсамых способных людей из обоих групп. Тем и другим следует знать, что самые удачливые из "старыхворчунов" могли быть "молодыми львами" в прошлом году, и если человеку дали возможностьнаучиться без всяких издевательств, то он может стать самым стойким и разумным сторонникомперемен. Он будет обладать неоценимыми свойствами здорового скептицизма, знания пользователей ипонимания организационных препятствий. Сторонники немедленных и радикальных изменений должныосознать, что гораздо чаще нужен переход, предполагающий постепенное внедрение новых методов. Сдругой стороны, те, кто не желает перемен, должны поискать для себя такие области, где это возможно,чем вести ожесточенные, арьергардные бои в той области, где новые требования уже задалисовершенно иные условия для успешного проекта.11.5 Свод правилВ этой главе мы затронули много тем, но как правило не давали настоятельных и конкретныхрекомендаций по проектированию.
Это соответствует моему убеждению, что нет "единственно верногорешения". Принципы и приемы следует применять тем способом, который лучше подходит дляконкретных задач. Для этого нужен вкус, опыт и разум. Все-таки можно указать некоторый свод правил,который разработчик может использовать в качестве ориентиров, пока не наберется достаточно опыта,чтобы выработать лучшие.
Ниже приведен свод таких правил.Эти правила можно использовать в качестве отправной точки в процессе выработки основныхнаправлений для проекта или организации или в качестве проверочного списка. Подчеркну еще раз, чтоони не являются универсальными правилами и не могут заменить размышления.•Узнайте, что вам предстоит создать.•Ставьте определенные и осязаемые цели.•Не пытайтесь с помощью технических приемов решить социальные проблемы.•Рассчитывайте на большой срок-в проектировании, и-управлении людьми.•Используйте существующие системы в качестве моделей, источника вдохновения и отправнойточки.•Проектируйте в расчете на изменения:-гибкость,-расширяемость,-переносимость, и-повторное использование.•Документируйте, предлагайте и поддерживайте повторно используемые компоненты.•Поощряйте и вознаграждайте повторное использование303Бьерн Страуструп.•Язык программирования С++-проектов,-библиотек, и-классов.Сосредоточьтесь на проектировании компоненты.-Используйте классы для представления понятий.-Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации,требуемой для интерфейса.-Проводите строгую типизацию интерфейсов всегда, когда это возможно.-Используйте в интерфейсах типы из области приложения всегда, когда это возможно.•Многократно исследуйте и уточняйте как проект, так и реализацию.•Используйте лучшие доступные средства для проверки и анализа-проекта, и-реализации.• Экспериментируйте, анализируйте и проводите тестирование на самом раннем возможном этапе.• Стремитесь к простоте, максимальной простоте, но не сверх того.• Не разрастайтесь, не добавляйте возможности "на всякий случай".• Не забывайте об эффективности.• Сохраняйте уровень формализации, соответствующим размеру проекта.• Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.Еще некоторые правила можно найти в $$12.511.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.304Бьерн Страуструп.Язык программирования С++Одна из немногих книг, посвященных роли человеческого фактора в производствепрограммного обеспечения. Необходима для каждого менеджера. Достаточно успокаивающаядля чтения перед сном. Лекарство от многих глупостей.[6]Ron Kerr: A Materialistic View of the Software "Engineering" Analogy. in SIGPLAN Notices, March1987. pp 123-125.Использование аналогии в этой и следующей главах во многом обязано наблюдениям изуказанной статьи, а так же беседам с Р. Керром, которые этому предшествовали.[7]Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87 (Addendum). Orlando, Florida.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
