Перестройка иерархии классов

Шаги 1 и 3 требуют исследования классов и их иерархии, чтобыубедиться, что они адекватно отвечают нашим требованиям. Обычноэто не так, и приходится проводить перестройку для улучшенияструктуры, проекта или реализации. Самая типичная перестройка иерархии классов состоит в выделенииобщей части двух классов в новый класс или в разбиении класса на двановых. В обоих случаях в результате получится три класса:базовый класс и двапроизводных. Когда следует проводить такую перестройку? Каковыобщие показания, что такая перестройка будет полезной? К сожалению нет простого и универсального ответа на этивопросы. Это и не удивительно, поскольку то, что предлагается,не является мелочью при реализации, а изменяет основныепонятия системы. Важной и нетривиальной задачей является поискобщности среди классов и выделение общей части. Нет точногоопределения общности, но следует обращать внимание на общностьдля понятий системы, а не просто для удобства реализации. Указаниями,что два класса имеют нечто общее, что возможно выделить в общий базовыйкласс, служат схожие способы использования, сходство наборов операций,сходство реализаций и просто тот факт, что часто в процессе обсужденияпроекта оба класса появляются одновременно. С другойстороны, если естьнесколько наборов операций класса с различными способами использования,если эти наборы обеспечивают доступ к раздельным подмножествам объектовреализации, и, если класс возникает в процессе обсуждения несвязанныхтем, то этот класс является явным кандидатом для разбиения на части. В силу тесной связи между понятиями и классами проблемыперестройки иерархии классов высвечиваются на поверхности проблемименования классов и использования имен классов в процессе обсужденияпроекта. Если имена классов и их упорядоченность, задаваемая иерархиейклассов, кажутся неудобными при обсуждении проекта, значит, по всейвидимости, есть возможность улучшения иерархии. Заметим, чтоподразумевается, что анализ иерархии классов лучше проводить не водиночку. Если вы оказались в таком положении, когда не с кемобсудить проект, хорошим выходом будет попытаться составить учебноеописание системы, используя имена классов.

Использование моделей

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

Эксперимент и анализ

В начале честолюбивого проекта нам неизвестен лучший способ построениясистемы. Часто бывает так, что мы даже не знаем точно, что должнаделать система, поскольку конкретные факты прояснятся только в процессепостроения, тестирования и эксплуатации системы. Как задолго досоздания законченной системы получить сведения, необходимые дляпонимания того, какие решения при проектировании окажутсясущественными, и к каким последствиям они приведут? Нужно проводить эксперименты. Конечно, нужен анализ проекта и егореализации, как только появляется пища для него. Преимущественнообсуждение вертится вокруг альтернатив при проектировании иреализации. За исключением редких случаев проектирование естьсоциальная активность, которая ведет по пути презентации иобсуждений. Часто самым важным средством проектирования оказываетсяпростая грифельная доска; без нее идеи проекта, находящиеся взародыше, не могут развиться и стать общим достоянием в средеразработчиков и программистов. Похоже, что самый популярный способ проведения эксперимента сводитсяк построению прототипа, т.е. уменьшенной версии системы. Прототип необязан удовлетворять характеристикам реальных систем, обычно визобилии есть машинные ресурсы и программная поддержка, и в такихусловиях программисты и разработчики становятся непривычно опытными,хорошо образованными и активными. Появляется цель - сделатьработающий прототип как можно скорее, чтобы начать исследованиевариантов проекта и способов реализации. Такой подход, если применять его разумно, может привести куспеху. Но он также может служить оправданием неудачно сделанныхсистем. Дело в том, что уделяя особое внимание прототипу, можноприйти к смещению усилий от "исследование вариантовпроекта" к "получение как можно скорее рабочей версии системы".Тогда быстро угаснет интерес к внутренней структуре прототипа("ведь это только прототип"), а работа по проектированию будетвытесняться манипулированием с реализацией прототипа. Просчетзаключается в том, что такая реализация может легко привести к системе,которая имеет вид "почти законченной", а по сути является пожирателемресурсов и кошмаром для тех, кто ее сопровождает. В этомслучае на прототип тратятся время и энергия, которые лучше приберечьдля реальной системы. Для разработчиков и менеджеров есть искушениепеределать прототип в конечный программный продукт, а "искусствонастройки системы" отложить до выпуска следующей версии. Если идтитаким путем, то прототипы отрицают все основы проектирования. Сходная проблема возникает, если исследователи привязываютсяк тем средствам, которые они создали при построении прототипа,и забывают, что они могут оказаться непригодными длярабочей системы, и что свобода от ограничений и формальностей, ккоторой они привыкли, работая в небольшой группе, может оказатьсяневозможной в большом коллективе, бьющимся над устранением длиннойцепи препятствий. И в то же время создание прототипов может сыграть важную роль.Рассмотрим, например, проектирование пользовательского интерфейса. Дляэтой задачи внутренняя структура той части системы, которая прямо необщается с пользователем, обычно не важна, и использование прототипов -это единственный способ узнать,какова будет реакция пользователя при работе с системой.Другим примером служат прототипы, прямо предназначенные для изучениявнутренней структуры системы. Здесь уже интерфейс с пользователемможет быть примитивным, возможна работа с моделью пользователей. Использование прототипов - это способ экспериментирования.Ожидаемый результат - это более глубокое понимание целей, а несам прототип. Возможно, сущность прототипа заключается в том,что он является настолько неполным, что может служить лишь средствомдля эксперимента, и его нельзя превратить в конечный продукт безбольших затрат на перепроектирование и на другую реализацию. Оставляяпрототип "неполным", мы тем самым переключаем внимание наэксперимент и уменьшаем опасность превращения прототипа в законченныйпродукт. Это также почти избавляет от искушения взять за основупроекта системы проект прототипа, при этом забывая или игнорируя теограничения, которые внутренне присущи прототипу. После экспериментапрототип надо просто выбросить. Не следует забывать о других способах проведения эксперимента,которые могут служить во многих случаях альтернативой созданию прототипа,и там, где они применимы, их использование предпочтительнее, посколькуони обладают большей точностью и требуют меньших затратвремени разработчика и ресурсов системы. Примерами могут служитьматематические модели и различные формы моделирования. По сути,существует бесконечная возрастающая последовательность,начиная от математических моделей,ко все более и более детальным способам моделирования, затем кпрототипам, к частичным реализациям системы, вплоть до полной системы. Это подводит к идее построения системы, исходя из начальногопроекта и реализации, и двигаясь путем повторного прохожденияэтапов проектирования и реализации. Это идеальная стратегия,но она предъявляет высокие требования к средствам проектированияи реализации, и в ней содержится определенный риск того, чтопрограммный объем, реализующий решения, принятыепри начальном проектировании, в процессе развития вырастет до такойвеличины, что существенное улучшение проекта будет просто невозможно. Похоже, что по крайней мере теперь такую стратегию применяютили в проектах от малого до среднего размеров, т.е. там, гдемаловероятны переделки общего проекта, или же для перепроектированияи иной реализации после выдачи первоначальной версии системы, гдеуказанная стратегия становится неизбежной. Помимо экспериментов, предназначенных для оценки решений,принимаемых на этапе проектирования, источником получения полезнойинформации может быть анализ собственно проектирования и (или)реализации. Например, может оказаться полезным изучение различныхзависимостей между классами (см.$$ 12.2), не следует забывать и отаких традиционных вспомогательных средствах реализации, какграф вызовов функций, оценка производительности и т.п. Заметим, что спецификация (результат анализа системы) и проектмогут содержать ошибки, как и реализация, и возможно, они дажебольше подвержены ошибкам, т.к. являются менее точными, не могут бытьпроверены на практике и обычно не окружены такими развитыми средствами,как те, что служат для анализа и проверки реализации. Введениебольшей формализации в язык или запись, с помощью которой изложен проект,в какой-то степени облегчает использования этих средств дляпроектирования. Но, как сказано в $$12.1.1, это нельзя делатьза счет ухудшения языка, используемого для реализации. К томуже формальная запись может сама стать источником трудностей ипроблем. Это происходит, когда выбранная степень формализации плохоподходит для конкретных задач, когда строгость формализации превосходитматематическую основу системы и квалификацию разработчиков ипрограммистов, и когда формальное описание системы начинаетрасходиться с реальной системой, для которой оно предназначалось. Заключение о необходимости опыта и о том, что проектированиенеизбежно сопровождается ошибками и плохо поддержано программнымисредствами, служит основным доводом в пользу итеративной моделипроектирования и реализации. Альтернатива - это линейная модельпроцесса развития, начиная с анализа и кончая тестированием, ноона существенно дефектна, поскольку не допускает повторныхпроходов, исходя из опыта, полученного на различных этапах развитиясистемы.

Тестирование

Программа, которая не прошла тестирование, не работает. Идеал, чтобыпосле проектирования и (или) верификации программа заработала спервого раза, недостижим для всех, за исключением самых тривиальныхпрограмм. Следует стремиться к идеалу, но не заблуждаться, чтотестирование простое дело. "Как проводить тестирование?" - на этот вопрос нельзя ответитьв общем случае. Однако, вопрос "Когда начинать тестирование?" имееттакой ответ - на самом раннем этапе, где это возможно. Стратегиятестирования должна быть разработана как часть проекта и включенав реализацию, или, по крайней мере, разрабатываться параллельнос ними. Как только появляется работающая система, надо начинатьтестирование. Откладывание тестирования до "проведения полнойреализации" - верный способ выйти из графика или передать версиюс ошибками. Всюду, где это возможно, проектирование должно вестись так,чтобы тестировать систему было достаточно просто. В частности,имеет смысл средства тестирования прямо встраивать в систему.Иногда это не делается из-за боязни слишком объемных проверок настадии выполнения, или из-за опасений, что избыточность, необходимаядля полного тестирования, излишне усложнит структуры данных.Обычно такие опасения неоправданы, поскольку собственно программыпроверки и дополнительные конструкции, необходимые для них,можно при необходимости удалить из системы перед ее поставкойпользователю. Иногда могут пригодится утверждения о свойствахпрограммы (см. $$12.2.7). Более важной, чем набор тестов, является подход, когдаструктура системы такова, что есть реальные шансы убедить себяи пользователей, что ошибки можно исключить с помощью определенногонабора статических проверок, статического анализа и тестирования.Если разработана стратегия построения системы, устойчивой к ошибкам(см.$$9.8), стратегия тестирования обычно разрабатывается каквспомогательная. Если вопросы тестирования полностью игнорируются на этапепроектирования, возникнут проблемы с тестированием, временемпоставки и сопровождением системы. Лучше всего начать работатьнад стратегией тестирования с интерфейсов классов и ихвзаимозависимостей (как предлагается в $$12.2 и $$12.4). Трудно определить необходимый объем тестирования. Однако,очевидно, что проблему представляет недостаток тестирования,а не его избыток. Сколько именно ресурсов в сравнении с проектированиеми реализацией следует отвести для тестирования зависит отприроды системы и методов ее построения. Однако, можно предложитьследующее правило: отводить больше ресурсов времени и человеческихусилий на тестирование системы, чем на получения ее первой реализации.

Сопровождение

"Сопровождение программного обеспечения" - неудачный термин. Слово"сопровождение" предлагает неверную аналогию с аппаратурой. Программыне требуют смазки, не имеют движущихся частей, которые изнашиваютсятак, что требуют замены, у них нет трещин, в которые попадаетвода, вызывая ржавчину. Программы можно воспроизводить в точностии передавать в течении минуты на длинные расстояния. Короче,программы это совсем не то, что аппаратура. (В оригинале:"Software is not hardware"). Деятельность, которая обозначается, как сопровождение программ,на самом деле, состоит из перепроектирования и повторной реализации,а значит входит в обычный цикл развития программного обеспечения.Если в проекте учтены вопросы расширяемости, гибкости и переносимости,то обычные задачи сопровождения решаются естественным образом. Подобно тестированию задачи сопровождения не должны решатьсявне основного направления развития проекта и их не следует откладыватьна потом.

Эффективность

Д. Кнуту принадлежит утверждение "Непродуманная оптимизация - кореньвсех бед". Некоторые слишком хорошо убедились в справедливости этогои считают вредными все заботы об оптимизации. На самом деле вопросыэффективности надо все время иметь в виду во время проектирования иреализации. Это не означает, что разработчик должен заниматьсязадачами локальной оптимизации, только задача оптимизации на самомглобальном уровне должна его волновать. Лучший способ добиться эффективности - это создать ясный ипростой проект. Только такой проект может остаться относительноустойчивым на весь период развития и послужить основой длянастройки системы с целью повышения производительности. Здесьважно избежать "гаргантюализма", который является проклятиембольших проектов. Слишком часто люди добавляют определенныевозможности системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3),удваивая, учетверяя размер выполняемой программы ради завитушек.Еще хуже то, что такие усложненные системы трудно поддаютсяанализу, а по этому трудно отличить избыточные накладные расходыот необходимых и провести анализ и оптимизации на общем уровне.Оптимизация должна быть результатом анализа и оценки производительностисистемы, а не произвольным манипулированием с программным кодом,причем это особенно справедливо для больших систем, где интуицияразработчика или программиста не может служить надежным указателемв вопросах эффективности. Важно избегать по сути неэффективных конструкций, а так жетаких конструкций, которые можно довести до приемлемого уровнявыполнения, только затратив массу времени и усилий. По этой жепричине важно свести к минимуму использование непереносимых посвоей сути конструкций и средств, поскольку их наличие препятствуетработе системы на других машинах (менее мощных, менее дорогих).

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

Если только это имеет какой-то смысл, большинство людей делает то,что их поощряют делать. Так, в контексте программного проекта, еслименеджер поощряет определенные способы действий и наказывает задругие, редкие программисты или разработчики рискнут своимположением, встречая сопротивления или безразличия администрации,чтобы делать так, как они полагают нужнымЬ. Ь Организация, в которой считают своих программистов недоумками,очень скоро получит программистов, которые будут рады и способныдействовать только как недоумки. Отсюда следует, что менеджер должен поощрять такие структуры,которые соответствуют сформулированным целям проекта и реализации.Однако на практике слишком часто бывает иначе. Существенноеизменение стиля программирования достижимо только при соответствующемизменении в стиле проектирования, кроме того, обычно и то и другоетребует изменения в стиле управления. Мыслительная и организационнаяинерция слишком просто сводят все к локальным изменениям, хотятолько глобальные изменения могут принести успех. Прекраснойиллюстрацией служит переход на язык с объектно-ориентированнымпрограммированием, например на С++, когда он не влечет за собойсоответствующих изменений в методах проектирования, чтобывоспользоваться новыми возможностями языка (см. $$12.1), и, наоборот,когда переход на "объектно-ориентированное проектирование" несопровождается переход на язык реализации, который поддерживаетэтот стиль.

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

Часто основной причиной перехода на новый язык или новый методпроектирования называют то, что это облегчает повторное использованиепрограмм или проекта. Однако, во многих организациях поощряютсотрудника или группу, когда они предпочитают изобретать колесо.Например, если производительность программиста измеряется числомстрок программы, то будет ли он писать маленькие программы,работающие со стандартными библиотеками, за счет своего доходаи, может быть, положения? А менеджер, если он оплачиваетсяпропорционально числу людей в его группе, будет ли он использоватьпрограммы, сделанные другими коллективами, если он может простонанять еще пару программистов в свою группу? Компания можетполучить правительственный контракт, в котором ее доход составляетфиксированный процент от расходов на проект, будет ли онасокращать свой доход за счет использования наиболее эффективныхсредств? Трудно обеспечить вознаграждение за повторное использование,но если администрация не найдет способов поощрения и вознаграждения,то его просто не будет. Повторное использование является прежде всего социальнымфактором. Повторное использование программы возможно при условии,что [1] она работает; нельзя использовать повторно, если это невозможно и в первый раз; [2] она понятна; здесь имеет значение структура программы, наличие комментариев, документации, руководства; [3] она может работать вместе с программами, которые не создавались специально с таким условием; [4] можно рассчитывать на ее сопровождение (или придется делать это самому, что обычно не хочется); [5] это выгодно (хотя можно и разделить расходы по разработке и сопровождению с другими пользователями) и, наконец; [6] ее можно найти.К этому можно еще добавить, что компонент не является повторноиспользуемым, пока кто-то действительно не сделал это. Обычно задачаприспособления компонента к существующему окружению приводит куточнению набора операций, обобщению его поведения, и повышению егоспособности адаптации к другим программам. Пока все это не проделанохотя бы один раз, неожиданные острые углы находятся даже укомпонентов, которые тщательно проектировались и реализовывались. Личный опыт подсказывает, что условия для повторногоиспользования возникают только в том случае, когда находитсяконкретный человек, занятый этим вопросом. В маленьких группахэто обычно бывает тот, кто случайно или запланированно оказываетсяхранителем общих библиотек или документации. В больших организацияхэто бывает группа или отдел, которые получают привилегию собирать,документировать, популяризировать и сопровождать программноеобеспечение, используемое различными группами. Нельзя недооценивать такие группы "стандартных компонентов".Укажем, что в первом приближении, система отражает организацию,которая ее создала. Если в организации нет средств поощрения ивознаграждения кооперации и разделения труда, то и на практикеони будут исключением. Группа стандартных компонентов должнаактивно предлагать свои компоненты. Обычная традиционнаядокументация важна, но ее недостаточно. Помимо этого указаннаягруппа должна предоставлять руководства и другую информацию,которая позволит потенциальному пользователю отыскать компонент ипонять как он может ему помочь. Значит эта группа должна предприниматьдействия, которые обычно связываются с системой образования имаркетинга. Члены группы компонентов должны всегда, когда этовозможно, работать в тесном сотрудничестве с разработчиками изобластей приложения. Только тогда они будут в курсе запросовпользователей и сумеют почуять возможности использованиястандартного компонента в различных областях. Это являетсяаргументом за использование такой группы в роли консультанта и впользу внутренних поставок программ, чтобы информация из группыкомпонентов могла свободно распространяться. Заметим, что не все программы должны быть рассчитаны наповторное использование, иными словами, повторное использование неявляется универсальным свойством. Сказать, что некоторый компонентможет быть повторно использован, означает, что в рамках определеннойструктуры его повторное использование не потребует значительныхусилий. Но в большинстве случаев перенос в другую структуру можетпотребовать большой работы. В этом смысле повторное использованиесильно напоминает переносимость. Важно понимать, что повторноеиспользование является результатом проектирования, ставившеготакую цель, модификации компонентов на основе опыта и специальныхусилий, предпринятых для поиска среди существующих компонентовкандидатов на повторное использование. Неосознанное использованиесредств языка или приемов программирования не может чудеснымобразом гарантировать повторное использование. Такие средства языкаС++, как классы, виртуальные функции и шаблоны типа, способствуютпроектированию, облегчающему повторное использование (значит делаютего более вероятным), но сами по себе эти средства не гарантируютповторное использование.

Размер

Человек и организация склонны излишне радоваться тому, что они"действуют по правильной методе". В институтской среде это частозвучит как "развитие согласно строгим предписаниям". В обоих случаяхздравый смысл становится первой жертвой страстного и часто искреннегожелания внести улучшения. К несчастью, если здравого смысла не хватает,то ущерб, нанесенный неразумными действиями, может быть неограниченным. Вернемся к этапам процесса развития, перечисленным в $$11.3, ик шагам проектирования, указанным в $$11.3.3. Относительно простопереработать эти этапы в точный метод проектирования, когда шаг точноопределен, имеет хорошо определенные входные и выходные данные иполуформальную запись для задания входных и выходных данных. Можносоставить протокол, которому должно подчиняться проектирование,создать средства, предоставляющие определенные удобства для записии организации процесса. Далее, исследуя классификацию зависимостей,приведенную в $$12.2, можно постановить, что определенные зависимостиявляются хорошими, а другие следует считать плохими, и предоставитьсредства анализа, которые обеспечат проведение таких оценок во всехстадиях проекта. Чтобы завершить такую "стандартизацию" процессасоздания программ, можно было бы ввести стандарты на документацию(в том числе правила на правописание и грамматику и соглашения оформате документации), а так же стандарты на общий вид программ(в том числе указания какие средства языка следует использовать,а какие нет, перечисление допустимых библиотек и тех, которые не нужноиспользовать, соглашения об именовании функций, типов, переменных,правила расположения текста программы и т.д.). Все это может способствовать успеху проекта. По крайней мере,было бы явной глупостью, браться за проект системы, котораяпредположительно будет иметь порядка десяти миллионов строк текста,над которой будут работать сотни человек, и которую будутсопровождать тысячи человек в течении десятилетий, не имея достаточнохорошо определенного и строгого плана по всем перечисленным вышепозициям. К счастью, большинство систем не относится к этой категории.Тем не менее, если решено, что данный метод проектирования илиследование указанным образцам в программировании и документацииявляются "правильными", то начинает оказываться давление, чтобыприменять их повсеместно. В небольших проектах это приводит кнелепым ограничениям и большим накладным расходам. В частности,это может привести к тому, что мерой развития и успеха становитсяне продуктивная работа, а пересылка бумажек и заполнение различныхбланков. Если это случится, то в таком проекте настоящихпрограммистов и разработчиков вытеснят бюрократы. Когда происходит такое нелепое злоупотребление методамипроектирования (по всей видимости совершенно разумными), то неудачапроекта становится оправданием отказа от практически всякойформализации процесса разработки программного обеспечения. Это,в свою очередь, ведет к такой путанице и таким провалам, которыекак раз и должен был предотвратить надлежащий метод проектирования. Основная проблема состоит в определении степени формализации,пригодной для процесса развития конкретного проекта. Не рассчитывайтелегко найти ее решение. По сути для малого проекта каждый методможет сработать. Еще хуже то, что похоже практически каждый метод,даже если он плохо продуман и жесток по отношению к исполнителям,может сработать для большого проекта, если вы готовы затратитьуйму времени и денег. В процессе развития программного обеспечения главная задача -сохранить целостность проекта. Трудность этой задачи зависитнелинейно от размера проекта. Сформулировать и сохранить основныеустановки в большом проекте может только один человек или маленькаягруппа. Большинство людей тратит столько времени на решениеподзадач, технические детали, повседневную административную работу,что общие цели проекта легко забывает или заменяет их на болеелокальные и близкие цели. Верный путь к неудаче, когда нет человекаили группы с прямым заданием следить за целостностью проекта.Верный путь к неудаче, когда у такого человека или группы нетсредств воздействовать на проект в целом. Отсутствие согласованных дальних целей намного более опаснодля проекта и организации, чем отсутствие какого-либо одногоконкретного свойства. Небольшая группа людей должна сформулироватьтакие общие цели, постоянно держать их в уме, составить документы,содержащие самое общее описание проекта, составить пояснения косновным понятиям, и вообще, помогать всем остальным помнить оназначении проекта.

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

Описанный здесь метод проектирования рассчитан на искусныхразработчиков и программистов, поэтому от их подбора зависитуспех организации. Менеджеры часто забывают, что организация состоит изиндивидуумов. Распространено мнение, что программисты равны ивзаимозаменяемы. Это заблуждение может погубить организацию за счетвытеснения многих самых активных сотрудников и принужденияостальных работать над задачами значительно ниже их уровня.Индивидуумы взаимозаменяемы только, если им не дают применитьсвой талант, который поднимает их над общим минимальным уровнем,необходимым для решения данной задачи. Поэтому миф о взаимозаменяемостибесчеловечен и по сути своей расточителен. Многие системы оценок производительности программиста поощряютрасточительность и не могут учесть существенный личный вкладчеловека. Самым очевидным примером служит широко распространеннаяпрактика оценивать успех в количестве запрограммированных строк,выданных страниц документации, пропущенных тестов и т.п.Такие цифры эффектно выглядят на диаграммах, но имеют самоеотдаленное отношение к действительности. Например, еслипроизводительность измерять числом запрограммированных строк, тоудачное повторное использование ухудшит оценку труда программиста.Обычно тот же эффект будет иметь удачное применение лучших приемовв процессе перепроектирования большой части системы. Качество результата измерить значительно труднее, чем количество,и вознаграждать исполнителя или группу следует за качество их труда,а не на основе грубых количественных оценок. К сожалению, насколькоизвестно, практическая разработка способов оценки качества еще неначалась. К тому же оценки, которые неполно описывают состояниепроекта, могут исказить процесс его развития. Люди приспосабливаются,чтобы уложиться в отведенный срок и перестраивают свою работу всоответствии с оценками производительности, в результате страдаетобщая целостность системы и ее производительность. Например, еслиотведен срок для выявления определенного числа ошибок, то для того,чтобы уложиться в него, активно используют проверки на стадиивыполнения, что ухудшает производительность системы. Обратно, еслиучитываются только характеристики системы на стадии выполнения, точисло невыявленных ошибок будет расти при условии недостаткавремени у исполнителей. Отсутствие хороших и разумных оценоккачества повышает требования к технической квалификации менеджеров,иначе будет постоянная тенденция поощрять произвольную активность,а не реальный прогресс. Не надо забывать, что менеджеры тоже люди,и они должны по крайней мере настолько разбираться в новыхтехнологиях, как и те, кем они управляют. Здесь, как и в других аспектах процесса развития программногообеспечения, следует рассматривать большие временные сроки. По сутиневозможно указать производительность человека на основе егоработы за год. Однако, многие сотрудники имеют карточку своихдостижений за большой период, и она может послужить надежным указаниемдля предсказания их производительности. Если не принимать во вниманиетакие карточки, что и делается, когда сотрудников считаютвзаимозаменяемыми спицами в колесе организации, то у менеджераостаются только вводящие в заблуждения количественные оценки. Если мы рассматриваем только достаточно большие временныесроки и отказываемся от методов управления, рассчитанных на"взаимозаменяемых недоумков", то надо признать, что индивидууму(как разработчику или программисту, так и менеджеру) нужен большойсрок, чтобы дорасти до более интересной и важной работы. Такойподход не одобряет как "скакание" с места на место, так и передачуработы другому из-за карьерных соображений. Целью должен бытьнизкий оборот ключевых специалистов и ключевых менеджеров. Никакойменеджер не добьется успеха без подходящих технических знаний ивзаимопонимания с основными разработчиками и программистами.В тоже время, в конечном счете никакая группа разработчиков илипрограммистов не добьется успеха без поддержки компетентныхменеджеров и без понимания хотя бы основных нетехнических вопросов,касающихся окружения, в котором они работают. Когда требуется предложить нечто новое, на передний план выходятосновные специалисты - аналитики, разработчики, программисты. Именноони должны решить трудную и критическую задачу внедрения новойтехнологии. Это те люди, которые должны овладеть новыми методами иво многих случаях забыть старые привычки. Это не так легко. Ведьэти люди сделали большой личный вклад в создание старых методов исвою репутацию как специалиста обосновывают успехами, полученными спомощью старых методов. Так же обстоит дело и с многими менеджерами. Естественно у таких людей есть страх перед изменениями. Он можетпривести к преувеличению проблем, возникающих при изменениях, и кнежеланию признать проблемы, вызванные старыми методами. Естественно,с другой стороны люди, выступающие за изменения, могут переоцениватьвыгоды, которые принесут изменения, и недооценивать возникающиездесь проблемы. Эти две группы людей должны общаться, они должнынаучиться говорить на одном языке и должны помочь друг другуразработать подходящую схему перехода. Альтернативой будеторганизационный паралич и уход самых способных людей из обоих групп.Тем и другим следует знать, что самые удачливые из "старых ворчунов"могли быть "молодыми львами" в прошлом году, и если человеку даливозможность научиться без всяких издевательств, то он может статьсамым стойким и разумным сторонником перемен. Он будет обладатьнеоценимыми свойствами здорового скептицизма, знания пользователейи понимания организационных препятствий. Сторонники немедленных ирадикальных изменений должны осознать, что гораздо чаще нуженпереход, предполагающий постепенное внедрение новых методов.С другой стороны, те, кто не желает перемен, должны поискать длясебя такие области, где это возможно, чем вести ожесточенные,арьергардные бои в той области, где новые требования уже задалисовершенно иные условия для успешного проекта.

Свод правил