Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 26 Методики оптимизации кода 631 Shirazi, Jack. Java Performance Tuning. Sebastopol, CA: O’Reilly & Associates, 2000. Wilson, Steve and Jeff Kesselman. Java Platform Performance: Strategies and Tactics. Boston, MA: Addison-Wesley, 2000. Ключевые моменты 쐽 Результаты конкретных видов оптимизации во многом зависят от языка, ком- пилятора и среды. Не оценив результатов оптимизации, вы не сможете сказать, помогает она программе или вредит. 쐽 Первый вид оптимизации часто далеко не самый лучший. Обнаружив эффек- тивный вид оптимизации, продолжайте пробовать и, возможно, найдете еще более эффективный. 쐽 Оптимизация кода похожа на ядерную энергию — это противоречивая и эмо- циональная тема. Кто-то считает, что оптимизация настолько ухудшает надеж- ность и удобство сопровождения программы, что ее вообще выполнять не следует. Другие думают, что при соблюдении должной предосторожности она приносит пользу. Если вы решите использовать методики, описанные в этой главе, будьте внимательны и осторожны. ГЛАВА 25 Стратегии оптимизации кода 633 Часть VI СИСТЕМНЫЕ ВОПРОСЫ 쐽 Глава 27. Как размер программы влияет на конструирование 쐽 Глава 28. Управление конструированием 쐽 Глава 29. Интеграция 쐽 Глава 30. Инструменты программирования 634 ЧАСТЬ VI Системные вопросы Г Л А В А 2 7 Как размер программы влияет на конструирование Содержание 쐽 27.1. Взаимодействие и размер 쐽 27.2. Диапазон размеров проектов 쐽 27.3. Влияние размера проекта на возникновение ошибок 쐽 27.4. Влияние размера проекта на производительность 쐽 27.5. Влияние размера проекта на процесс разработки Связанные темы 쐽 Предварительные требования к конструированию: глава 3 쐽 Определение вида ПО, над которым вы работаете: раздел 3.2 쐽 Управление конструированием: глава 28 Масштабирование в области разработки ПО — это не просто вопрос увеличения составных частей небольшого проекта. Допустим, вы разработали программный комплекс Gigatron, содержащий 25 000 строк кода, за 20 человеко-месяцев и на- шли 500 ошибок во время производственного тестирования. Допустим, Gigatron 1.0 имел успех, так же, как и Gigatron 2.0, и вы начали работу над Gigatron Deluxe — значительно улучшенной версией программы, которая предположительно бу- дет состоять из 250 000 строк кода. Хотя ее размер в 10 раз превышает размер начальной версии, Gigatron Deluxe по- требует не 10-кратных усилий при разработке, а 30-кратных. Более того, 30-крат- ные общие затраты не означают 30-кратных затрат только на конструирование. Возможно, потребуется потратить в 25 раз больше усилий на конструирование, и в 40 — на архитектуру и системное тестирование. Точно так же вы не получите 10-кратный прирост ошибок — он может быть 15-кратным и даже больше. Если вы привыкли работать над маленькими проектами, то ваш первый проект среднего или большого размера может вырваться из-под контроля, превратившись в необузданного зверя, вместо благоприятного исхода, который вы себе представ- ляли. Эта глава рассказывает, какие виды хищников можно встретить и где найти хлыст и кольцо для их укрощения. С другой стороны, если вы привыкли работать http://cc2e.com/2761 ГЛАВА 27 Как размер программы влияет на конструирование 635 с большими проектами, то используемые вами подходы могут оказаться слишком формализованными применительно к малым задачам. Эта глава описывает, как сэ- кономить, чтобы предохранить небольшие проекты от обрушения под грузом накладных расходов. 27.1. Взаимодействие и размер Если вы единственный человек, работающий над проектом, то единственное на- правление взаимодействия проходит между вами и заказчиком, если не считать путь между левым и правым полушариями вашего мозга. С ростом числа участни- ков проекта, увеличивается и число вариантов взаимодействия. Причем это чис- ло растет не аддитивно в соответствии с количеством людей, а мультипликатив- но — пропорционально квадрату числа участников (рис. 27-1). Рис. 27-1. Количество вариантов взаимодействия растет пропорционально квадрату числа участников команды Как видите, в проекте с двумя участниками только одно направление вза- имодействия. Проект с пятью участниками содержит 10 возможных ва- риантов. В проекте с 10 участниками может быть 45 направлений, при условии, что каждый человек может контактировать с любым другим. 10% проек- тов, в которых занято 50 или более программистов, содержат минимум 1200 по- тенциальных вариантов. Чем больше путей взаимодействия, тем больше времени вы тратите на общение и тем больше вероятность появления ошибок в процессе взаимодействия. Проекты большего размера требуют принятия организационных мер, которые упорядочивают взаимодействие или существенно его ограничивают. Типичный подход к упорядочению взаимодействия состоит в его формализации с помощью документов. Вместо непосредственного общения 50 человек друг с другом в любом возможном сочетании эти 50 человек пишут и читают докумен- ты. Некоторые документы — текстовые, некоторые — графические. Некоторые на- печатаны на бумаге, а некоторые — хранятся в электронной форме. 636 ЧАСТЬ VI Системные вопросы 27.2. Диапазон размеров проектов Является ли размер проекта, над которым вы работаете, типичным? Широкий диапазон размеров проектов означает, что вы не можете считать типичным ни- какой из возможных размеров. Одним из способов оценить размер проекта слу- жит оценка численности команды разработчиков, работавших над этим проек- том. Вот как примерно выглядит процентное соотношение всех проектов, выпол- ненных командами разных размеров: Размер команды разработчиков Примерная доля проектов (в %) 13 25% 410 30% 1125 20% 2650 15% 50+ 10% Источники: Получено на основе данных из «A Survey of Software Engineering Practice: Tools, Methods, and Results» (Beck and Perkins, 1983), «Agile Software Development Eco- systems» (Highsmith, 2002) и «Balancing Agility and Discipline»(Boehm and Turner, 2003). Один из неочевидных аспектов информации о размерах проектов заключается в различии между процентным соотношением проектов разной величины и чис- лом программистов, работающих над проектами каждого размера. Поскольку над большими проектами работает больше программистов, чем над маленькими, то в них занят больший процент всех программистов. Приведем приблизительную оценку процентного соотношения количества программистов, работающих над проектами разного размера: Размер команды разработчиков Примерная доля программистов (в %) 13 5% 410 10% 1125 15% 2650 20% 50+ 50% Источники: Получено на основе данных из «A Survey of Software Engineering Practice: Tools, Methods, and Results» (Beck and Perkins, 1983), «Agile Software Development Ecosys- tems» (Highsmith, 2002) и «Balancing Agility and Discipline»(Boehm and Turner, 2003). 27.3. Влияние размера проекта на возникновение ошибок Размер проекта влияет как на количество, так и на тип воз- никающих ошибок. Вы могли и не предполагать, что тип ошибок также подвержен влиянию, но с ростом размера проекта обычно все больший процент ошибок можно отнести к просчетам в тех- нических требованиях и проектировании (рис. 27-2). Перекрестная ссылка Подроб- нее об ошибках см. раздел 22.4. ГЛАВА 27 Как размер программы влияет на конструирование 637 Рис. 27-2. При увеличении размера проекта обычно возрастает количество ошибок, возникающих из-за просчетов в технических требованиях и проектировании. И все же иногда ошибки в основном возникают при конструировании (Boehm, 1981, Grady, 1987, Jones, 1998) В маленьких проектах ошибки конструирования составляют до 75% най- денных ошибок. Методология меньше влияет на качество кода, а наиболь- шее влияние на систему часто оказывает мастерство индивидуума, раз- рабатывающего эту программу (Jones, 1998). В больших проектах ошибки конструирования могут сократиться примерно до 50%; все остальные можно отнести к ошибкам в требованиях и архитектуре. По- видимому, это связано с тем, что в больших проектах разработке требований и архитектурному проектировании нужно уделять больше времени, поэтому при выполнении этих операций пропорционально возрастает и вероятность возник- новения ошибок. Однако в некоторых очень больших проектах доля ошибок кон- струирования остается высокой — иногда даже в системах с 500 000 строк кода, 75% ошибок можно отнести к области конструирования (Grady 1987). Аналогично изменению типа при увеличении размера проекта меняет- ся и количество ошибок. Вы могли ожидать, что проект, превышающий другой вдвое, закономерно содержит вдвое больше ошибок. Но на самом деле плотность дефектов — число ошибок на 1000 строк кода — возрастает. Вдвое больший продукт содержит более чем в два раза больше ошибок. Табл. 27-1 пока- зывает диапазоны плотностей дефектов, появление которых вы можете ожидать в проектах разных размеров. Табл. 27-1. Размер проекта и типичная плотность ошибок Размер проекта (число строк кода) Типичная плотность ошибок Менее 2K 0–25 ошибок на 1000 строк кода (thousand lines of code, KLOC) 2K–16K 0–40 ошибок на KLOC 16K–64K 0,5–50 ошибок на KLOC 64K–512K 2–70 ошибок на KLOC 512K или больше 4–100 ошибок на KLOC Источники: «Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Soft- ware Costs» (Jones, 1998). 638 ЧАСТЬ VI Системные вопросы Данные для этой таблицы получены на основе специализи- рованных проектов, и эти числа могут иметь мало общего с данными проектов, над которыми вы работаете. Однако в ка- честве моментального снимка для отрасли они весьма пока- зательны: число ошибок значительно возрастает при увели- чении размера проекта, и очень большие проекты имеют до четырех раз больше ошибок на 1000 строк кода, чем малень- кие. Для достижения одинакового соотношения ошибок в больших проектах придется приложить больше усилий. 27.4. Влияние размера проекта на производительность Когда речь заходит о размере проекта, производительность имеет много общего с качеством ПО. При небольших размерах (2000 строк кода и менее) наибольшее влияние на производительность оказывает мастерство отдельного программиста (Jones, 1998). С увеличением размера проекта все больше на производительность начинают влиять численность команды и организация. Насколько большим должен быть проект, чтобы численность команды раз- работчиков стала влиять на производительность? В «Prototyping Versus Specifying: a Multiproject Experiment» Бом, Грей и Сиволдт (Boehm, Gray and Seewaldt) сообщали, что команды меньших размеров выполняли проекты с производительностью на 39% выше, чем более многочисленные команды. Размер команд? Два человека для маленьких проектов и три — для больших (1984). Табл. 27-2 позволяет получить представление о взаимосвязи между размером проекта и производительностью. Табл. 27-2. Размер проекта и производительность Число строк кода на человека в год (в скобках указано номинальное Размер проекта (число строк кода) значение Cocomo II* ) 1K 2500–25 000 (4000) 10K 2000–25 000 (3200) 100K 1000–20 000 (2600) 1 000K 700–10 000 (2000) 10 000K 300–5000 (1600) Источники: Составлено на основе данных из «Measures for Excellence» (Putnam and Meyers, 1992), «Industrial Strength Software» (Putnam and Meyers, 1997), «Software Cost Esti- mation with Cocomo II» (Boehm et al., 2000), и «Software Development Worldwide: The Sta- te of the Practice» (Cusumano et al., 2003). Перекрестная ссылка Данные представляют собой среднее значение. Горстка организаций сообщает о лучшем соотноше- нии ошибок, чем приведенные здесь минимальные величины. Примеры см. в подразделе «Сколько ошибок вы можете найти?» раздела 22.4. * Constructive Cost Model (конструктивная стоимостная модель) — метод оценки затрат на раз- работку ПО. — Прим. перев. ГЛАВА 27 Как размер программы влияет на конструирование 639 Производительность в значительной степени определяется видом ПО, над кото- рым вы работаете, квалификацией персонала, языком программирования, мето- дологией, сложностью продукта, программной средой, инструментарием, спосо- бом подсчета «строк кода», тем, как усилия по поддержке, не относящиеся напря- мую к программированию, переводятся в «количество строк кода на человека в год», и другими факторами. Поэтому конкретные цифры в табл. 27-2 очень силь- но отличаются. Однако тенденция, представленная этими числами, очень показательна. Произ- водительность в малых проектах может быть в 2–3 раза выше, чем в больших, а разница в производительности между самыми маленькими и самыми большими проектами может достигать 5–10 раз. 27.5. Влияние размера проекта на процесс разработки Если вы работаете над проектом в одиночку, то наибольшее влияние на его успех или провал оказываете вы сами. Если вы работаете над проектом, в котором за- няты 25 человек, то потенциально все еще можете оказывать наибольшее влия- ние, но скорее всего отдельный человек не может присвоить себе такое достиже- ние — на успех или провал сильнее будет влиять организация. Соотношение между выполняемыми операциями и размер По мере того как растет размер проекта и увеличивается необходимость формаль- ных взаимодействий, меняются и виды операций, выполняемых в проекте. Соот- ношение операций в процессе разработки для проектов различных размеров можно представить так (рис. 27-3): Рис. 27-3. Конструирование преобладает в маленьких проектах. Проекты большего размера требуют больших затрат на архитектуру, интеграцию и системное тестирование. Работа по составлению технических требований на этой диаграмме не показана, потому что в отличие от других операций эти усилия не зависят от размера программы напрямую. (Albrecht, 1979; Glass, 1982; Boehm, Gray and Seewaldt, 1984; Boddie, 1987; Card, 1987; McGarry, Waligora and McDermott, 1989; Brooks, 1995; Jones, 1998; Jones, 2000; Boehm et al., 2000) 640 ЧАСТЬ VI Системные вопросы В малых проектах конструирование является наиболее заметной частью проекта: на него приходится до 65% всего времени разработки. В сред- них по величине проектах конструирование все еще доминирует, но его доля снижается до 50% от всех трудозатрат. В очень больших проектах архитек- тура, интеграция и системное тестирование занимают все больше времени, и доля конструирования становится все менее заметной. Короче, при возрастании раз- мера проекта доля конструирования в общих затратах уменьшается. Этот график выглядит так, будто при его продолжении вправо конструирование исчезнет со- всем. Поэтому, чтобы не остаться без работы, я ограничился размером в 512K. Доля конструирования снижается, потому что с ростом размера проекта все со- ставляющие конструирования: проектирование, кодирование, отладка и модуль- ное тестирование — пропорционально масштабируются, однако затраты на дру- гие виды деятельности растут гораздо быстрее (рис. 27-4). Рис. 27-4. Объем работ по конструированию ПО — практически линейная функция от размера проекта. Трудозатраты на другие виды работ при увеличении проекта растут нелинейно В близких по размеру проектах будут выполняться примерно одинаковые опера- ции, однако при расхождении в размерах виды выполняемых действий тоже начнут различаться. Как сказано во вступлении к этой главе, если Gigatron Deluxe в 10 раз больше начального Gigatron, он потребует в 25 раз больше затрат на конст- руирование, в 25–50 — на планирование, в 30 — на интеграцию и в 40 — на ар- хитектуру и системное тестирование. Соотношение между видами деятельности изменяется, потому что при разных размерах проекта разные виды деятельности становятся крити- ческими. Барри Бом и Ричард Тернер (Barry Boehm and Richard Turner) выяснили, что расходы на проработку архитектуры в пределах 5% от общей сто- имости проекта позволяют минимизировать затраты для проектов, содержащих примерно 10 000 строк кода. Но наилучшие результаты можно получить, если в проектах размером в 100 000 строк кода израсходовать на архитектуру 15–20% средств (Boehm and Turner, 2004). Далее приведены виды деятельности, затраты на которые с ростом размера про- екта увеличиваются нелинейно: 쐽 взаимодействие; 쐽 планирование; 쐽 управление; 쐽 разработка требований; 쐽 функциональное проектирование системы; ГЛАВА 27 Как размер программы влияет на конструирование 641 쐽 проектирование и спецификация интерфейса; 쐽 архитектура; 쐽 интеграция; 쐽 удаление дефектов; 쐽 системное тестирование; 쐽 документирование. Независимо от размера проекта некоторые технологии всегда имеют большое значение: дисциплинированная практика кодирования, проверка проекта и кода другими разработчиками, хороший инструментарий и использование высокоуров- невых языков. Эти приемы представляют ценность в маленьких проектах и бес- ценны в больших. Программы, продукты, системы и системные продукты Не только количество строк кода и размер команды влия- ют на размер проекта. Более тонкое воздействие оказыва- ют качество и сложность окончательной версии программ- ного продукта. Для создания и отладки первой версии Giga- tron мог потребоваться всего месяц. Это была отдельная программа, написанная, протестированная и задокументированная одним чело- веком. Если Gigatron длиной 2500 строк занял один месяц, то почему окончательный вариант Gigatron, длиной 25 000 строк потребовал 20 месяцев? Простейший вид ПО — это отдельная «программа», используемая человеком, ее написавшим, или несколькими другими. Более сложный вид программы — это программный «продукт», предназначенный для использования другими людьми, а не самим разработчиком. Программный про- дукт используется в средах, отличающихся о той, в которой этот продукт был создан. Он тщательно протестирован перед сдачей в эксплуатацию, задокументирован, и другие люди могут осуществлять его сопровождение. Разработка программного продукта стоит примерно втрое дороже разработки программы. Другой уровень сложности требуется и для разработки пакета программ, работаю- щих вместе. Такой пакет называется программной «системой». Разработать систе- му гораздо сложнее, чем простую программу из-за сложности разработки интер- фейсов между отдельными частями и необходимости интеграции этих частей. В целом система также примерно втрое дороже, чем простая программа. Создание «системного продукта» предполагает наведение глянца, прису- щего продукту, и наличие нескольких частей системы. Системный про- дукт примерно в девять раз дороже простой программы (Brooks, 1995, Shull et al., 2002). Неучитываемые различия в сложности и глянце между программами, продукта- ми, системами и системными продуктами и являются частой причиной ошибок в оценках. Программисты, использующие свой опыт в написании программ для составления плана создания программного продукта, могут ошибиться в меньшую сторону примерно в 10 раз. Рассматривая следующий пример, обратитесь к гра- фику на рис. 27-3. Если вы воспользуетесь своим опытом в написании 2K строк Дополнительные сведения Другое объяснение этой точки зрения см. в главе 1 книги «The Mythical Man- Month» (Brooks, 1995). 642 ЧАСТЬ VI Системные вопросы кода, чтобы оценить, сколько времени займет разработка программы длиной в 2K строк, ваши расчеты будут учитывать только 65% времени, необходимого для выполнения всех операций по созданию программы. Написание 2K строк кода не занимает столько же времени, сколько создание целой программы, состоящей из 2K строк. Если вы не учитываете время, затрачиваемое не на конструирование, разработка займет на 50% больше времени, чем вы рассчитывали. При увеличении проекта конструирование требует все меньшей доли общих за- трат. Если вы основываете свои расчеты только на опыте конструирования, оце- ночная ошибка растет. Если вы использовали свой опыт написания 2K строк для оценки времени, необходимого для разработки программы длиной 32K, ваша оценка будет включать только 50% от необходимого времени; весь процесс раз- работки может занять на 100% больше времени, чем вы предполагали. Ошибку в оценке можно полностью приписать вашему непониманию влияния размера на разработку больших программ. Кроме того, если вы не учли дополни- тельных усилий по наведению лоска, в отличие от простой программы оценоч- ная ошибка может легко увеличиться в три или более раз. Методология и размер Методология используется в проектах любых размеров. В маленьких проектах методология скорее случайна и инстинктивна — в больших она скрупулезна и тщательно спланирована. Порой методология бывает столь неопределенной, что программисты даже не по- дозревают, что ее используют. Некоторые программисты доказывают, что методо- логия лишена гибкости, поэтому они не будут ее использовать. Хотя они могут не использовать методологию сознательно, любой подход к программированию со- стоит из методологии независимо от простоты этого подхода. Обычный утренний подъем и поездка на работу являются рудиментарной методологией, хотя и не слиш- ком вдохновляющей. Программисты, отказывающиеся использовать методологию, на самом деле просто не используют ее явно — куда от нее денешься! Формальный подход не всегда доставляет удовольствие, а если он применяется неправильно, накладные расходы могут поглотить получаемые от него преиму- щества. Однако возрастающая сложность больших проектов требует более осоз- нанного отношения к методологии. Строить небоскреб и собачью будку нужно по-разному. То же относится и к программным проектам разных размеров. В боль- ших проектах случайный выбор методологии не соответствует задаче. Успешные проектировщики выбирают стратегии для больших проектов осознанно. В светском обществе чем формальней событие, тем более неудобную одежду нужно надевать (высокие каблуки, галстуки и т. д.). В разработке ПО чем формальней проект, тем больше бумажных документов необхо- димо создать, чтобы убедиться, что вы выполнили ваше домашнее задание. Кей- перс Джонс указывает, что в проекте длиной в 1000 строк примерно 7% затрат приходится на бумажную работу, тогда как в проекте в 100 000 строк затраты на бумажную работу увеличиваются в среднем до 26% (Jones, 1998). Эта работа проводится не из чистой любви к писанине. Она является прямым ре- зультатом интересного феномена: чем больше человек вам приходится коорди- нировать, тем больше требуется документов (рис. 27-1). |