Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 27 Как размер программы влияет на конструирование 643 Вы не создаете эти документы ради самого факта их существования. Смысл напи# сания плана управления конфигурацией, например, не в том, чтобы потренировать пальцы рук, но в том, чтобы заставить вас тщательно продумать управление кон# фигурацией и объяснить ваш план любому желающему. Документация — это ося# заемый побочный эффект проделанной вами реальной работе по планированию и конструированию системы. Если вам кажется, что вы делаете это ради профор# мы и пишете обобщенные документы, значит, что#то не в порядке. «Больше» не значит лучше, во всяком случае в том, что касается методо# логии. В своем сравнении быстрых и четко спланированных вариантов методологии Барри Бом и Ричард Тернер предупреждают, что обычно лучше сначала создать небольшие методы, а затем промасштабировать их для большого проекта, чем начать с создания универсального метода, а затем урезать его для маленького проекта (Boehm and Turner, 2004). Некоторые ученые мужи в области ПО говорят о «легковесной» и «тяжеловесной» методологии, но на прак# тике главное — это учесть конкретный размер и тип вашего проекта, а затем найти «правильновесную» методологию. Дополнительные ресурсы Для дальнейшего изучения темы данной главы ознакомьтесь со следующими источниками. Boehm, Barry и Richard Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison#Wesley, 2004. Бом и Тернер рассказы# вают, как размер проекта влияет на применение быстрых и четко спланированных методов, а также рассматривают другие вопросы, касающиеся быстроты и четкого планирования. Cockburn, Alistair. Agile Software Development. Boston, MA: Addison#Wesley, 2002. В гла# ве 4 обсуждаются вопросы выбора подходящей методологии проекта, в том чис# ле учитываются размеры проекта. Глава 6 представляет Кристаллическую методо# логию Кокберна (Cockburn’s Crystal Methodologies), в которой определены подходы к разработке проектов различной величины и степени критичности. Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981. Бом всестороннее рассматривает такие зависящие от размера проекта величины, как стоимость, производительность и качество, а также другие переменные, участву# ющие в процессе разработки ПО. Книга включает обсуждение влияния размера на конструирование и другие операции. Глава 11 содержит отличное объяснение от# рицательных последствий масштабирования ПО. Другая информация о размере проекта распределена по всей книге. Выпущенная в 2000 г. книга Бома Software Cost Estimation with Cocomo II содержит больше современной информации относитель# но оценочной модели Бома Cocomo, но более ранняя книга включает более глубо# кое обсуждение вопроса, все еще представляющее интерес. Jones, Capers. Estimating Software Costs. New York, NY: McGraw#Hill, 1998. Эта книга заполнена таблицами и графиками, анализирующими источники производитель# ности разработки ПО. Что касается конкретного вопроса влияния размера про# екта, то раздел «The Impact of Program Size» главы 3 изданной в 1986 г. книги Джонса Programming Productivity содержит отличное обсуждение. http://cc2e.com/2768 644 ЧАСТЬ VI Системные вопросы Brooks, Frederick P., Jr. The Mythical Man%Month: Essays on Software Engineering, An% niversary Edition (2d ed.). Reading, MA: Addison#Wesley, 1995. Брукс работал в IBM менеджером разработки OS/360 — гигантского проекта, занявшего 5000 челове# ко#лет. В своем очаровательном эссе он обсуждает вопросы управления, свойствен# ные маленьким и большим командам, и высказывает исключительно яркое мне# ние о командах главных программистов. DeGrace, Peter, и Leslie Stahl. Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms. Englewood Cliffs, NJ: Yourdon Press, 1990. Как следу# ет из названия, книга классифицирует подходы к разработке ПО. Как упомина# лось на протяжении всей этой главы, подход должен изменяться при изменении размера проекта, и Дегрейс и Стал делают эту точку зрения очевидной. В разделе «Attenuating and Truncating» главы 5 обсуждается настройка процессов разработ# ки ПО в соответствии с размером проекта и другими формальностями. Книга содержит описания моделей из НАСА и Минобороны, а также большое количе# ство поучительных иллюстраций. Jones, T. Capers. «Program Quality and Programmer Productivity». IBM Technical Report TR 02.764 (January 1977): 42–78. Статья также доступна в книге Джонса Tutorial: Programming Productivity: Issues for the Eighties, 2d ed. Los Angeles, CA: IEEE Computer Society Press, 1986. Эта статья содержит первый глубокий анализ причин, по ко# торым распределение расходов в больших проектах отлично от маленьких. Это исчерпывающее обсуждение различий между большими и маленькими проекта# ми, включающее требования и меры по обеспечению качества. Статья старая, но все еще интересная. Ключевые моменты С ростом размера проекта появляется необходимость поддерживать взаимо# действие. Смысл большинства подходов к методологии состоит в уменьшении проблем взаимодействия, поэтому методология должна жить или умереть в зависимости от ее вклада в облегчение взаимодействия. При прочих равных, производительность в больших проектах будет ниже, чем в маленьких. При прочих равных большие проекты будут содержать больше ошибок на 1000 строк кода, чем маленькие. Деятельность, которая в малых проектах сама собой разумеется, в больших проектах должна быть тщательно спланирована. С ростом размера проекта конструирование занимает все меньшую ее часть. Увеличение масштаба легковесной методологии обычно работает лучше, чем уменьшение масштаба тяжеловесной. Наиболее эффективный подход состоит в использовании «правильновесной» методологии. ГЛАВА 28 Управление конструированием 645 Г Л А В А 2 8 Управление конструированием Содержание 28.1. Поощрение хорошего кодирования 28.2. Управление конфигурацией 28.3. Оценка графика конструирования 28.4. Измерения 28.5. Гуманное обращение с программистами 28.6. Управление менеджером Связанные темы Предварительные требования к конструированию: глава 3 Определение вида ПО, над которым вы работаете: раздел 3.2 Размер программы: глава 27 Качество ПО: глава 20 На протяжении нескольких последних десятилетий управление разработкой ПО является задачей повышенной сложности. Обсуждение общих вопросов управле# ния программными проектами выходит за рамки данной книги, но в этой главе рассматриваются некоторые специальные темы управления, напрямую связанные с конструированием (рис. 28#1). Если вы разработчик, эта глава поможет вам по# нять те вопросы, которые менеджеры должны принимать во внимание; если же менеджер — понять, как менеджеры рассматривают разработчиков, а также как эффективно управлять конструированием. Поскольку глава охватывает широкий спектр вопросов, то в некоторых разделах также приведены источники дополни# тельной информации. http://cc2e.com/2836 646 ЧАСТЬ VI Системные вопросы Рис. 28'1. Эта глава охватывает вопросы управления ПО, относящиеся к конструированию Если вы интересуетесь управлением разработкой ПО, прочитайте раздел 3.2, что# бы понять различие между традиционными последовательными подходами к раз# работке и современными итеративными подходами. Не забудьте также прочесть главы 20 и 27, поскольку и требования к качеству, и размеры проекта влияют на то, как должно осуществляться управление данным конкретным проектом. 28.1. Поощрение хорошего кодирования Поскольку код — это основной результат конструирования, то ключевой вопрос в управлении конструированием звучит так: «Как содействовать выработке хоро# шей практики кодирования?» Вообще внедрение строгого набора технических стандартов с позиций менеджера — не очень хорошая идея. Программисты склонны рассматривать менеджеров как низшую ступень технической эволюции, где#то между одноклеточными организмами и мамонтами, вымершими в ледниковый период. Поэтому, если внедрение программных стандартов необходимо, програм# мисты должны в этом участвовать. Если какой#то участник проекта собирается определять стандарты, это должен быть скорее архитектор, пользующийся уважением, а не менеджер. Программные про# екты опираются в такой же степени на «профессиональную иерархию», как и на «должностную». Если этот архитектор считается идейным лидером проекта, команда в большинстве случаев будет придерживаться стандартов, установленных им. Если вы выбрали этот подход, убедитесь, что архитектора действительно уважа# ют. Иногда архитектор проекта — это просто старший по возрасту человек, ко# торый работает достаточно давно и не имеет представления о проблемах промыш# ленного кодирования. Программисты будут протестовать против стандартов, на# вязанных таким «архитектором», поскольку они не имеют ничего общего с их работой. Вопросы внедрения стандартов В одних организациях стандарты полезны, в других — не очень. Некоторые раз# работчики приветствуют стандартизацию, потому что она снижает вероятность возникновения случайных разногласий. Если ваша группа сопротивляется приме# нению строгих стандартов, рассмотрите несколько альтернатив: гибкие правила, предложения вместо правил или набор примеров, иллюстрирующих наилучшую практику. ГЛАВА 28 Управление конструированием 647 Технологии поощрения хорошего кодирования Ниже описаны способы достижения хорошего качества кодирования, не столь тяжеловесные, как утверждение жестких стандартов: Назначьте двух человек на каждую часть проекта Если над каждой строкой кода приходится работать двоим, то у вас есть гарантия, что хотя бы два человека думают, что код работает и его можно читать. Механизм работы команды из двух человек может варьироваться от парного программирования до пары «наставник — стажер» или рецензирования кода методом близнецов. Рецензируйте каждую строку кода В рецензировании кода обычно участвует программист и минимум два рецен# зента. Это значит, что каждую строку кода читают не менее трех человек. Другое название парного рецензирования — «парное давление» (peer pressure). Кроме предоставления страховки на тот слу# чай, если первоначальный программист покинет проект, рецензирование кода улучшает его качество, так как программист знает, что его код будут читать дру# гие. Даже если у вас нет явных стандартов кодирования, рецензирование позво# ляет незаметно продвигаться к созданию группового стандарта — в процессе ре# цензирования группа принимает решения, которые со временем могут стать ее стандартами. Введите процедуру подписания кода В других отраслях технические черте# жи утверждаются и подписываются управляющим инженером. Подпись означает, что в соответствии с уровнем квалификации инженера, этот чертеж технически компетентен и не содержит ошибок. Некоторые компании обращаются с кодом так же: только код, подписанный старшим техническим персоналом, считается за# вершенным. Распространяйте для ознакомления хорошие примеры кода Важной со# ставляющей хорошего управления является способность ясно донести свои тре# бования. Для этих целей вы можете распространять хороший код между програм# мистами или выставлять его на всеобщее обозрение. Так вы предоставляете яс# ный пример того качества, которого вы добиваетесь. Точно так же кодовые стан# дарты могут состоять главным образом из «листингов отличного кода». Присвое# ние определенному листингу «знака качества» — пример для подражания. Подоб# ные руководства легче обновлять, чем писаные (словами) стандарты. Кроме того, так легко показать тонкости стиля кодирования, которые тяжело по пунктам опи# сать словами. Подчеркивайте, что код — это общее имущество Иногда программисты считают, что код, который они на# писали, — «их» личная собственность. Хотя это результат их работы, но он является частью всего проекта и должен быть доступен любому участнику проекта. Он должен просмат# риваться другими хотя бы во время рецензирования и со# провождения. Перекрестная ссылка О парном программировании см. раздел 21.2. Перекрестная ссылка О рецен- зировании см. разделы 21.3 и 21.4. Перекрестная ссылка Большая часть программирования состо- ит в сообщении результатов ва- шей работы другим людям (см. разделы 33.5 и 34.3). 648 ЧАСТЬ VI Системные вопросы Один из самых успешных проектов, о котором когда#либо сообщалось, был реализован за 11 лет и состоял из 83 000 строк кода. За первые 13 месяцев эксплуатации была выявлена только одна ошибка, приведшая к системному сбою. Это достижение еще больше ошеломляет, если учитывать, что проект был завершен в конце 1960#х, без использования онлайн#компиляции и интерактивной отладки. Производительность проекта —7500 строк кода в год в конце 60#х — и по сегодняшним стандартам достаточно впечатляет. Главный про# граммист проекта сообщил, что одним из залогов успеха было признание всех машинных прогонов (ошибочных и нет) общим, а не частным достоянием (Baker and Mills, 1973). Эта идея нашла свое воплощение и в современной ситуации, на# пример, в ПО с открытым исходными кодом (Open Source Software) (Raymond, 2000), экстремальном программировании с его понятием о коллективном владе# нии (Beck, 2000) и во многих других случаях. Награждайте за хороший код Используйте систему поощрений для закреп# ления практики хорошего кодирования. При разработке таких поощрений при# нимайте во внимание следующие соображения. Награда должна представлять интерес для программиста. (Многим из них по# ощрения типа «Какой молодец!» неприятны, особенно когда исходят от нетех# нических менеджеров.) Код, поощряемый таким образом, должен быть исключительно хорошим. На# граждая программиста, которого все остальные считают плохим работником, вы уподобляетесь Гомеру Симпсону, пытающемуся запустить ядерный реактор. Не имеет значения, что этот программист всегда демонстрирует готовность к сотрудничеству или никогда не опаздывает на работу. Вы потеряете кредит доверия, если ваша награда не будет соответствовать технической стороне вопроса. Если вы недостаточно технически подкованы, чтобы судить о каче# стве кода, — не делайте этого. Лучше совсем не вручать награду или позволить команде выбрать достойного. Один простой стандарт Если вы управляете программным проектом и в про# шлом сами были программистом, то простым и эффективным способом добить# ся хорошего результата будет фраза: «Я должен быть в состоянии прочесть и по# нять любой код, написанный в проекте». То, что менеджер — не самый техничес# ки продвинутый специалист, может быть преимуществом, так как препятствует созданию заумного или хитрого кода. Роль этой книги Большая часть книги содержит обсуждение хорошей практики программирова# ния. Она не предназначена для оправдания жестких стандартов — используйте ее как повод для дискуссии, источник сведений о хорошей программной практике, а также для поиска таких методик, которые могут дать преимущества в вашей среде программирования. ГЛАВА 28 Управление конструированием 649 28.2. Управление конфигурацией Программный проект динамичен. Меняется код, меняется проект, меняются и требования. Более того, изменения в требованиях влекут еще большие изменения в проекте, а изменения в проекте приводят к еще более значительным изменени# ям в коде и тестовых примерах. Что такое управление конфигурацией? Управление конфигурацией — это практика определения элементов проекта и систематическая обработка изменений таким образом, чтобы система могла под# держивать свою целостность длительное время. Другое название этого процесса — «контроль изменений». Он включает в себя методики определения предпола# гаемых изменений, отслеживание изменений и хранение копий системы в том виде, в каком она существовала в разные моменты. Если вы не контролируете изменения в технических требованиях, это может за# кончиться написанием кода для тех частей системы, которые в какой#то момент были отменены. Вы можете создать код, несовместимый с новыми элементами системы. Эти несовместимости можно не обнаружить до момента интеграции, который также станет началом поиска виноватых, потому что на самом деле никто не будет знать, что происходит. Если не контролируются изменения в коде, вы можете изменить содержимое ме# тода, который в то же время меняет кто#то другой, причем успешно объединить ваши и чужие изменения будет проблематично. При неконтролируемых измене# ниях код может выглядеть протестированным лучше, чем на самом деле. Версия, прошедшая тестирование, возможно, была старой, еще не измененной. Без хоро# шего контроля изменений вы можете внести в метод несколько исправлений, найти новые ошибки, но при этом не будете иметь возможности восстановления пре# дыдущей рабочей версии метода. Если изменения не обрабатываются систематически, то вы блуждаете в тумане, вместо того чтобы двигаться прямиком к ясной цели. Без хорошего контроля изменений вместо разработки кода вы впустую тратите время. Управление кон# фигурацией позволяет использовать время эффективно. Несмотря на очевидную необходимость управления конфигурацией, многие программисты избегают его десятилетиями. Опрос, проведенный более 20 лет назад, выяснил, что около трети программистов даже не были знакомы с этой идеей (Beck and Perkins, 1983), и нет никаких признаков, что это положение изменилось. Более свежее исследование Института Разработки ПО по# казало, что среди организаций, использующих неформальные методики разработ# ки ПО менее 20% применяют адекватное управление конфигурацией (SEI, 2003). Управление конфигурацией изобрели не программисты, но поскольку программ# ные проекты чрезвычайно изменчивы, то для них оно особенно полезно. Приме# нительно к программным проектам управление конфигурацией обычно называ# ется «управление конфигурацией ПО» (software configuration management, SCM). SCM сосредотачивается на программных требованиях, исходном коде, докумен# тации и тестах. 650 ЧАСТЬ VI Системные вопросы Систематическая ошибка SCM заключается в избыточном контроле. Абсолютно надежный способ прекратить автомобильные аварии — это запретить всем водить машину, а абсолютно надежный способ предотвратить проблемы с разработкой ПО — прекратить всю разработку. Хотя это и один из вариантов контроля изме# нений, это неудачный способ разрабатывать ПО. Необходимо тщательно плани# ровать SCM, чтобы оно давало преимущества, а не было камнем на шее. В маленьком проекте, разрабатываемом в одиночку, вы, вполне возможно, обойдетесь без всякого SCM, исключая планирование периодического нерегулярного создания ре# зервных копий. И все же управление конфигурацией еще способно принести пользу (на самом деле я пользовался такой системой при со# здании этой рукописи). В больших проектах, выполняемых 50 участниками, вам, вероятно, потребуется полнофункциональная схема SCM, включающая довольно формальные процедуры резервного копирования, контроль изменений требова# ний и проекта, а также контроль над документами, исходным кодом, содержани# ем, тестовыми вариантами и другими элементами проекта. Если ваш проект не слишком велик и не слишком мал, вы должны установить уровень формальности, находящийся между двумя экстремумами. Следующие подразделы описывают не# которые варианты реализации SCM. Изменения в требованиях и проекте Во время разработки вас переполняют идеи о том, как улуч# шить систему. Если вы будете реализовывать каждое изме# нение, вы скоро почувствуете, что бежите на месте: хотя система будет постоянно меняться, она не будет приближать# ся к завершению. Вот некоторые советы по контролю из# менений в проекте. Следуйте систематической процедуре контроля изменений Систематичес# кая процедура контроля изменений — это настоящая находка в случае, когда у вас большое количество запросов на изменение (см. раздел 3.4). Установив система# тическую процедуру, вы даете понять, что изменения будут рассмотрены в кон# тексте наибольшей пользы для проекта в целом. Обрабатывайте запросы на изменения группами Реализация простых из# менений по мере возникновения идей выглядит заманчиво. Проблема такого под# хода в том, что хорошие изменения могут затеряться. Если вы задумали простое изменение при 25%#й готовности проекта и сроки это позволяют, вы внесете это изменение. Если вы придумали еще одно простое изменение, когда готово 50% проекта, но вы уже опаздываете, вы не будете его вносить. Когда сроки начинают поджимать в конце проекта, уже не имеет значения, что второе изменение в 10 раз лучше, чем первое: вы не в том положении, чтобы делать несущественные исправления. Часть самых лучших изменений может уйти сквозь пальцы просто потому, что подумали о них слишком поздно. Решение этой проблемы состоит в записи всех идей и предложений (независимо от легкости их реализации) и сохранения их до тех пор, пока не появится воз# можность ими заняться. Тогда, рассматривая их целой группой, выберите из них наиболее полезные. Перекрестная ссылка О влиянии размера проекта на конструиро- вание см. главу 27. Перекрестная ссылка Одни под- ходы к разработке лучше под- держивают изменения, другие — хуже (см. раздел 3.2). |