Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 28 Управление конструированием 651 Оценивайте затраты на каждое изменение Каждый раз, когда ваш заказ# чик, босс или вы сами намерены изменить систему, оценивайте время, необходи# мое на внесение изменения, включая рецензирование кода этого изменения и по# вторное тестирование всей системы. Учтите в вашей оценке расходы, касающие# ся возникновения волнового эффекта от этого изменения, распространяющего# ся по направлению от требований к проектированию, кодированию, тестирова# нию и обновлениям в пользовательской документации. Пусть все заинтересован# ные стороны знают, что ПО имеет сложнопереплетенную структуру, и что вре# менная оценка требуется, даже если изменение кажется небольшим. Независимо от того, как оптимистично вы оцениваете предложенное изменение, воздержитесь от немедленной оценки. Такие оценки обычно ошибочны в два и более раз. Относитесь с подозрением к изменениям большого объема Некоторое количество изменений неизбежно, но большой объем запросов на изменение сигнализирует о том, что требования, архитектура или высокоуровневое проек# тирование не были выполнены достаточно качественно, чтобы способствовать эффективному конструированию. Возврат к работе над требованиями или архитектурой мо# жет показаться накладным, но он гораздо дешевле, чем кон# струирование ПО более одного раза или выбрасывание кода тех функций систе# мы, которые, как выяснилось, вам не нужны. Учредите комитет контроля изменений Работа комитета контроля измене# ний состоит в отделении зерен от плевел в запросах на изменение. Любой, кто хочет предложить изменение, отправляет запрос этому комитету. Термин «запрос на изменение» относится к любому запросу, который приводит к изменению ПО: идея новой функции, изменение в существующей функциональности, «отчет об ошибке», который сигнализирует о действительной или мнимой ошибке, и т. д. Комитет периодически собирается и рассматривает предложенные изменения. Он одобряет, отвергает или откладывает каждое изменение. Комитеты контроля из# менений считаются лучшим решением для расстановки приоритетов и контроля изменений в требованиях, но они еще довольно редко встречаются в коммерче# ских структурах (Jones, 1998; Jones, 2000). Соблюдайте бюрократические процедуры, но не позволяйте страху пе' ред бюрократией препятствовать эффективному контролю изменений Нехватка дисциплинированного контроля изменений — одна из важнейших про# блем управления. Значительный процент проектов, которые считались выполнен# ными с опозданием, на самом деле могли быть сделаны в срок, если бы в них учи# тывалось влияние неотслеживаемых, но согласованных изменений. Плохой кон# троль изменений позволяет накапливаться нерегистрируемым изменениям, что подрывает возможность видеть текущее положение дел, делать долгосрочные про# гнозы, планировать выполнение работ, а также влияет на управление рисками в частности и управление проектом в целом. Контроль изменений имеет тенденцию к бюрократизации, поэтому важно искать способы по рационализации этого процесса. Если вы предпочитаете не исполь# Перекрестная ссылка Другую точку зрения на работу с изме- нениями можно найти в подраз- деле «Что делать при изменении требований во время конструи- рования программы?» раздела 3.4. Советы по безопасным из- менениям в коде см. в главе 24. 652 ЧАСТЬ VI Системные вопросы зовать традиционные запросы на изменения, заведите почтовый адрес «Change# Board» и обяжите сотрудников посылать на него запросы на изменение. Или по# просите высказывать предложения по изменениям интерактивно на заседаниях комитета контроля. Особенно действенная мера — запись запросов на измене# ния в качестве дефектов в систему отслеживания дефектов. Ревнители порядка могут классифицировать такие изменения как «дефекты требований», или их можно считать изменениями, а не дефектами. Вы можете создать официальный Комитет контроля изменений, или Группу пла# нирования продукта или Военный совет, которые будут выполнять традиционные обязанности комитета контроля изменений. Или вы можете выбрать отдельного человека в качестве Царя изменений. Но как бы вы это ни назвали, сделайте это! Время от времени я встречаю проекты, страдающие от неумелой реали# зации контроля изменений. Но в 10 раз чаще я вижу проекты, страдаю# щие от полного отсутствия вразумительного контроля изменений. Глав# ное — это сама сущность контроля изменений, поэтому не позволяйте страху перед бюрократизацией помешать реализации преимуществ этого подхода. Изменения в коде программного обеспечения Другое назначение управления конфигурацией — контроль исходного кода. Если вы изменили код и возникла новая ошибка, которая, вроде бы, никак не связана со сделанными вами правками, то при поиске ее источника, вы, возможно, захо# тите сравнить новую и старые версии кода. Если это ничем вам не поможет, вы, вероятно, захотите взглянуть на еще более старую версию. Совершить такой экс# курс в историю просто, если у вас есть инструменты управления версиями, кото# рые отслеживают многочисленные версии исходного кода. Программы управления версиями С хорошим ПО для управления версиями работать так легко, что вы едва замечаете его существование. Оно особенно полезно в групповых проектах. Один вариант управления версиями блокирует исходные файлы так, что только один человек может моди# фицировать файл в некоторый момент времени. Обычно, когда вам нужно пора# ботать с каким#то исходным кодом, вы должны снять этот файл с учета (check out) в системе управления версиями. Если кто#то уже проделал эту процедуру, вы по# лучите сообщение, что этого сделать нельзя. Когда вы извлечете этот файл, вы смо# жете с ним работать так же, как и без использования системы управления верси# ями до тех пор, пока не будете готовы снова зарегистрировать его (check in). Другой вариант управления версиями позволяет нескольким людям работать с файлами одновременно и следит за необходимостью слияния изменений во время регис# трации файлов. В обоих случаях, когда вы регистрируете файл, система спраши# вает вас, почему вы его изменили, и вы указываете причину. При таких скромных усилиях вы получаете несколько больших преимуществ: вы не наступаете никому на ноги, работая с файлом в тот момент, когда с ним работает кто#то другой (или хотя бы вы знаете об этом); вы легко можете обновить свои копии всех файлов проекта, чтобы они соот# ветствовали текущим версиям, обычно одной командой; ГЛАВА 28 Управление конструированием 653 вы можете вернуться к любой версии любого файла, когда#либо зарегистри# рованной в системе управления версиями; вы можете получить список изменений, выполненных в любой версии любо# го файла; вам не надо заботиться о персональных резервных копиях, поскольку копия в системе контроля версий служит гарантией безопасности. Контроль версий — необходимая составляющая командных проектов. Он стано# вится еще более мощным оружием при интеграции управления версиями, отсле# живания дефектов и управления изменениями. Подразделение прикладного ПО Microsoft считает собственный инструментарий управления версиями «важнейшим преимуществом» (Moore, 1992). Версии инструментария Для некоторых видов проектов может понадобиться реконструкция точной сре# ды, используемой для разработки каждой конкретной версии ПО, включая ком# пиляторы, компоновщики, библиотеки кода и т. д. В этом случае вам также следу# ет поместить эти инструменты в систему управления версиями. Конфигурации компьютеров Многие компании (включая мою) на своем опыте познали преимущества созда# ния стандартизованных машинных конфигураций. На стандартной рабочей стан# ции, содержащей необходимый инструментарий, офисные приложения и другие программы, создается образ диска. Этот образ копируется на машину каждого разработчика. Стандартная конфигурация позволяет избежать уймы проблем, свя# занных со слегка различающимися конфигурационными параметрами, версиями применяемых инструментов и т. п. Стандартизованный образ диска также силь# но упрощает подготовку новой машины по сравнению с необходимостью уста# навливать каждую программу отдельно. План резервного копирования План резервного копирования — концепция не новая. Идея в том, чтобы перио# дически делать копию вашей работы. Если вы пишете книгу, вы не оставите руко# пись на крыльце, так как ее может намочить дождь, сдуть ветер или прихватить соседская собака — почитать на сон грядущий. Вы положите свой труд в безопас# ное место. ПО менее осязаемо, поэтому гораздо проще забыть, что на вашей ма# шине есть нечто очень ценное. С компьютерными данными может произойти множество неприятностей: может повредиться жесткий диск, вы или кто#то другой можете случайно удалить самые важные файлы, рассерженный сотрудник может устроить акцию саботажа, по разным причинам (кража, наводнение, пожар) вы можете лишиться своей маши# ны. Предпринимайте шаги для защиты своей работы. Ваш план резервного копи# рования должен включать периодическое создание копий и их хранение в дру# гих помещениях. Кроме исходного кода, в нем должны присутствовать все важ# ные для вашего проекта материалы: документы, чертежи и другие записи. 654 ЧАСТЬ VI Системные вопросы Один часто забываемый аспект разработки плана резервного копирования состоит в проверке процедуры создания резервных копий. Попробуйте восстановить дан# ные на некоторый момент времени, чтобы убедиться, что резервная копия содержит необходимую информацию и восстановленная версия работоспособна. Завершив проект, создайте его архив. Сохраните в надежном месте копию всего: исходного кода, компиляторов, инструментов, требований, проекта, документа# ции — всего, что может понадобиться для полного воссоздания продукта. Контрольный список: управление конфигурацией Общие вопросы Разработан ли план управления конфигурацией так, что- бы помочь работе программистов и минимизировать накладные расходы? Лишен ли подход к SCM излишнего контроля над проектом? Группируются ли запросы на изменение либо с помощью неформальных средств (например, списка планируемых изменений), либо посредством более систематического подхода (такого, как комитет контроля изменений)? Выполняется ли систематическая оценка влияния каждого предложенного изменения на стоимость, график и качество проекта? Рассматриваете ли вы большие изменения как предупреждение о том, что разработка требований завершена не полностью? Инструментарий Используется ли ПО управления версиями для облегчения управления кон- фигурацией? Используется ли ПО управления версиями для уменьшения сложностей в координации работы команды? Резервное копирование Выполняется ли периодическое резервное копирование всех материалов про- екта? Выполняется ли периодическое перемещение резервных копий проекта в сто- ронние хранилища? Копируются ли все материалы, включая исходный код, документы, чертежи и важные записи? Протестирована ли процедура восстановления из резервной копии? Дополнительные ресурсы по управлению конфигурацией Поскольку эта книга посвящена конструированию, в данном разделе рассматривается управление изменениями с точки зрения конструирования. Но изменения затрагивают все уровни проекта, и всеобъемлющая стратегия управления изменениями должна делать то же самое. Hass, Anne Mette Jonassen. Configuration Management Principles and Practices. Boston, MA: Addison#Wesley, 2003. Эта книга дает общую картину управления конфигура# цией ПО, а также практические советы, как его внедрить в процесс разработки. Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston, MA: Addison#Wesley, 2003. Как и в http://cc2e.com/2850 http://cc2e.com/2843 ГЛАВА 28 Управление конструированием 655 предыдущей книге, здесь дается общий обзор SCM и много практической инфор# мации. Преимуществом этой книги является наличие советов, помогающих груп# пам разработчиков изолировать и координировать свою работу. SPMN. Little Book of Configuration Management. Arlington, VA: Software Program Managers Network, 1998. Эту брошюра зна# комит с процессом управления конфигурацией и опреде# ляет критически важные факторы успеха. Она находится в свободном доступе на сайте SPMN по адресу www.spmn.com/products_guidebooks.html. Bays, Michael. Software Release Methodology. Englewood Cliffs, NJ: Prentice Hall, 1999. Эта книга обсуждает управление конфигурацией ПО с акцентом на выпуске про# мышленной версии продукта. Bersoff, Edward H. and Alan M. Davis. «Impacts of Life Cycle Models on Software Con# figuration Management». Communications of the ACM 34, no. 8 (August, 1991): 104– 118. В этой статье описано, как влияют на SCM новые подходы к разработке ПО, особенно касающиеся создания прототипов. Статья в особенности актуальна для сред, использующих практику быстрой (agile) разработки приложений. 28.3. Оценка графика конструирования Управление программным проектом — одна из исключительно трудоем# ких задач XXI века, причем оценка размера проекта и усилий, требуемых для его завершения, — один из сложнейших аспектов управления про# ектом. Большой программный проект в среднем завершается на год позже заяв# ленного срока и на 100% превышает первоначальный бюджет (Standish Group, 1994; Jones, 1997; Johnson, 1999). При опросах программистов по поводу разницы между ожидаемым и реальным графиками выполнения проекта выяснилось, что разра# ботчики имеют склонность к оптимистичным оценкам в пределах 20#30% (van Genuchten, 1991). Это в той же степени связано с ошибочной оценкой размера проекта и требуемых усилий, как и с плохой разработкой. В данном разделе очерчен круг вопросов, связанных с оценкой программных проектов, а также указано, где найти более подробную информацию. Подходы к оценке Вы можете оценить размер проекта и усилия, требуемые для его завершения, одним из нескольких способов: применить оценочное ПО; использовать алгоритмический подход, такой как Cocomo II, оценочная модель Барри Бома (Boehm et al., 2000); привлечь внешних экспертов для оценки проекта; обсудить предполагаемые затраты на собрании; оценить составные части проекта, а затем сложить их вместе; предложить каждому оценить их собственные задания, а затем просуммиро# вать полученные предположения; применить опыт предыдущих проектов; сохранить предыдущие оценки и посмотреть, насколько они были аккуратны, а затем применять их для коррекции новых предположений. http://cc2e.com/2857 Дополнительные сведения По- дробнее о методиках оценки гра- фика работ см. главу 8 в «Rapid Development» (McConnell, 1996) и «Software Cost Estimation with Cocomo II» (Boehm et al., 2000). 656 ЧАСТЬ VI Системные вопросы Ссылки на подробную информацию об этих подходах даны в подразделе «Допол# нительные ресурсы, посвященные оценке ПО» в конце этого раздела. Далее опи# сан правильный подход к оценке проекта. Определите цели Зачем нужна оценка? Что вы оценива# ете? Только операции конструирования или весь процесс разработки? Только затраты на проект или на проект плюс отпуска, праздники, обучение и другие мероприятия, не относящиеся к проекту? Насколько аккуратной должна быть оценка, чтобы соответствовать вашим целям? Какую она дол# жна иметь степень достоверности? Приведут ли оптимистичная и пессимистич# ная оценки к существенно различным результатам? Выделите время для оценки Скоропалительные оценки неаккуратны. Если вы оцениваете большой проект, рассматривайте процесс оценки как минипроект и выделите время для минипланирования оценки, чтобы хорошо ее выполнить. Выясните требования к программе Точно так же, как архитектор не может сказать, сколько будет стоить «доста# точно большой» дом, так и вы не сможете надежно оценить «достаточно большой» программный проект. Бессмысленно ожидать от вас оценки объема работ, требуемых для реализации чего#то, если это «что#то» еще не опре# делено. Определите требования или запланируйте подготовительный этап для исследований, прежде чем что#то оценивать. Делайте оценки на низком уровне детализации В зависимости от обозна# ченных целей основывайте оценки на подробном изучении свойств проекта. В целом чем подробней будет ваша экспертиза, тем аккуратней будет оценка. По закону больших чисел, если на одном большом интервале существует 10%#я по# грешность, ошибка составляет 10% либо в сторону увеличения, либо в сторону уменьшения. На 50 небольших интервалах часть 10%#х погрешностей будет в сто# рону увеличения, а часть — в сторону уменьшения, и погрешности будут уравно# вешивать друг друга. Используйте несколько способов оценки и сравнивай' те полученные результаты Не все методики оценки приведут к одинаковым результатам, так что попробуйте несколько. Изучите результаты, полученные разными спо# собами. Дети быстро смекают, что, если попросить третий шарик мороженного у каждого родителя в отдельности, больше шансов услышать хотя бы одно «да», чем если спра# шивать только одного родителя. Иногда родители догады# ваются, в чем дело, и дают одинаковый ответ, а иногда — нет. Выясните, какие варианты ответов вы можете получить при использовании разных методик оценки. Ни один подход не является лучшим в любых обстоятельствах, а разница между ними может многое объяснить. Например, работая над первым изданием этой книги, я навскидку оценивал ее размер в 250–300 страниц. Когда я наконец вы# полнил углубленный расчет, предполагаемый объем оказался равен 873 страни# цам. «Этого не может быть», — подумал я. Поэтому я воспользовался абсолютно другим способом оценки. В результате второй попытки я получил 828 страниц. Дополнительные сведения Эта методика основана на рекомен- дациях, предложенных в «Soft- ware Engineering Economics» (Boehm, 1981). Перекрестная ссылка О требо- ваниях к ПО см. раздел 3.4. Перекрестная ссылка Сложно найти область разработки ПО, в которой итерация не имеет важ- ного значения. Процесс предва- рительной оценки — один из примеров, где итерация может принести пользу. Об итератив- ных методиках см. раздел 34.8. |