Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
Глава 4. Основные решения, которые приходится принимать при конструировании 2 ЧАСТЬ I Основы разработки ПО Г Л А В А 1 Добро пожаловать в мир конструирования ПО! Содержание 1.1. Что такое конструирование ПО? 1.2. Почему конструирование ПО так важно? 1.3. Как читать эту книгу Связанные темы Кому следует прочитать эту книгу? (см. предисловие) Какую выгоду можно извлечь, прочитав эту книгу? (см. предисловие) Что побудило меня написать эту книгу? (см. предисловие) Значение слова «конструирование» вне контекста разработки ПО известно всем: это то, что делают строители при сооружении жилого дома, школы или небоскреба. В детстве вы наверняка собирали разные предметы из «конструктора». Вообще под «конструированием» понимают процесс создания какого#нибудь объекта. Этот про# цесс может включать некоторые аспекты планирования, проектирования и тес# тирования, но чаще всего «конструированием» называют практическую часть создания чего#либо. 1.1. Что такое конструирование ПО? Разработка ПО — непростой процесс, который может включать множество ком# понентов. Вот какие составляющие разработки ПО определили ученые за после# дние 25 лет: определение проблемы; выработка требований; создание плана конструирования; разработка архитектуры ПО, или высокоуровневое проектирование; детальное проектирование; кодирование и отладка; http://cc2e.com/0178 ГЛАВА 1 Добро пожаловать в мир конструирования ПО! 3 блочное тестирование; интеграционное тестирование; интеграция; тестирование системы; корректирующее сопровождение. Если вы работали над неформальными проектами, то можете подумать, что этот список весьма бюрократичен. Если вы работали над слишком формальными про# ектами, вы это знаете! Достичь баланса между слишком слабым и слишком силь# ным формализмом нелегко — об этом мы еще поговорим. Если вы учились программировать самостоятельно или работали преимущественно над неформальными проектами, вы, возможно, многие действия по созданию продукта объединили в одну категорию «программирование». Если вы работаете над неформальными проектами, то скорее всего, думая о создании ПО, вы пред# ставляете себе тот процесс, который ученые называют «конструированием». Такое интуитивное представление о «конструировании» довольно верно, однако оно страдает от недостатка перспективы. Поэтому конструирование целесообразно рассматривать в контексте других процессов: это помогает сосредоточиться на задачах конструирования и уделять адекватное внимание другим важным действи# ям, к нему не относящимся. На рис. 1#1 показано место конструирования среди других процессов разработки ПО. Рис. 1'1. Процессы конструирования изображены внутри серого эллипса. Главными компонентами конструирования являются кодирование и отладка, однако оно включает и детальное проектирование, блочное тестирование, интеграционное тестирование и другие процессы Как видите, конструирование состоит преимущественно из кодирования и отладки, однако включает и детальное проектирование, создание пла# на конструирования, блочное тестирование, интеграцию, интеграцион# 4 ЧАСТЬ I Основы разработки ПО ное тестирование и другие процессы. Если бы эта книга была посвящена всем ас# пектам разработки ПО, в ней было бы приведено сбалансированное обсуждение всех процессов. Однако это руководство по методам конструирования, так что остальных тем я почти не касаюсь. Если бы эта книга была собакой, она тщатель# но принюхивалась бы к конструированию, виляла хвостом перед проектирова# нием и тестированием и лаяла на прочие процессы. Иногда конструирование называют «кодированием» или «программированием». «Кодирование» кажется мне в данном случае не лучшим термином, так как он подразумевает механическую трансляцию разработанного плана в команды язы# ка программирования, тогда как конструирование вовсе не механический про# цесс и часто связано с творчеством и анализом. Смысл слов «программирование» и «конструирование» кажется мне похожим, и я буду использовать их как равно# правные. На рис. 1#1 разработка ПО была изображена в «плоском» виде; более точным от# ражением содержания этой книги является рис. 1#2. Рис. 1'2. Кодирование и отладка, детальное проектирование, создание плана конструирования, блочное тестирование, интеграция, интеграционное тестирова% ние и другие процессы обсуждаются в данной книге примерно в такой пропорции На рис. 1#1 и 1#2 процессы конструирования представлены с общей точки зре# ния. Но что можно сказать об их деталях? Вот некоторые конкретные задачи, свя# занные с конструированием: проверка выполнения условий, необходимых для успешного конструирования; определение способов последующего тестирования кода; проектирование и написание классов и методов; создание и присвоение имен переменным и именованным константам; выбор управляющих структур и организация блоков команд; ГЛАВА 1 Добро пожаловать в мир конструирования ПО! 5 блочное тестирование, интеграционное тестирование и отладка собственно# го кода; взаимный обзор кода и низкоуровневых программных структур членами группы; «шлифовка» кода путем его тщательного форматирования и комментирования; интеграция программных компонентов, созданных по отдельности; оптимизация кода, направленная на повышение его быстродействия, и снижение степени использования ресурсов. Еще более полное представление о процессах и задачах конструирования вы получите, просмотрев содержание книги. Конструирование включает так много задач, что вы можете спросить: «Ладно, а что не является частью конструирования?» Хороший вопрос. В конструирование не входят такие важные процессы, как управление, выработка требований, разра# ботка архитектуры приложения, проектирование пользовательского интерфейса, тестирование системы и ее сопровождение. Все они не меньше, чем конструиро# вание, влияют на конечный успех проекта — по крайней мере любого проекта, который требует усилий более одного#двух человек и длится больше нескольких недель. Все эти процессы стали предметом хороших книг, многие из которых я указал в разделах «Дополнительные ресурсы» и в главе 35. 1.2. Почему конструирование ПО так важно? Раз уж вы читаете эту книгу, вы наверняка понимаете важность улучшения каче# ства ПО и повышения производительности труда разработчиков. Многие из са# мых удивительных современных проектов основаны на применении ПО: Интер# нет и спецэффекты в кинематографе, медицинские системы жизнеобеспечения и космические программы, высокопроизводительный анализ финансовых данных и научные исследования. Эти, а также более традиционные проекты имеют мно# го общего, поэтому применение улучшенных методов программирования окупится во всех случаях. Признавая важность улучшения разработки ПО в целом, вы можете спросить: «Почему именно конструированию в этой книге уделяется такое внимание?» Ответы на этот вопрос приведены ниже. Конструирование — крупная часть процесса разра' ботки ПО В зависимости от размера проекта на конст# руирование обычно уходит 30–80 % общего времени работы. Все, что занимает так много времени работы над проектом, неизбежно влияет на его успешность. Конструирование занимает центральное место в про' цессе разработки ПО Требования к приложению и его архитектура разрабатываются до этапа конструирования, чтобы гарантировать его эффективность. Тестирование системы (в строгом смысле независимого тестиро# вания) выполняется после конструирования и служит для проверки его правиль# ности. Конструирование — центр процесса разработки ПО. Перекрестная ссылка О связи между размером проекта и до- лей времени, уходящего на кон- струирование, см. подраздел «Соотношение между выполня- емыми операциями и размер» раздела 27.5. 6 ЧАСТЬ I Основы разработки ПО Повышенное внимание к конструированию может намного повысить производительность труда от' дельных программистов В своем классическом иссле# довании Сэкман, Эриксон и Грант показали, что произво# дительность труда отдельных программистов во время кон# струирования изменяется в 10–20 раз (Sackman, Erikson, and Grant, 1968). С тех пор эти данные были подтверждены другими исследованиями (Curtis, 1981; Mills, 1983; Curtis et al., 1986; Card, 1987; Valett and McGarry, 1989; DeMarco and Lister, 1999№; Boehm et al., 2000). Эта книга поможет всем программистам изучить ме# тоды, которые уже используются лучшими разработчиками. Результат конструирования — исходный код — часто является единствен' ным верным описанием программы Зачастую единственным видом доступ# ной программистам документации является сам исходный код. Спецификации тре# бований и проектная документация могут устареть, но исходный код актуален всегда, поэтому он должен быть максимально качественным. Последовательное при# менение методов улучшения исходного кода — вот что отличает детальные, кор# ректные и поэтому информативные программы от устройств Руба Голдберга 1 . Эф# фективнее всего применять эти методы на этапе конструирования. Конструирование — единственный процесс, который выполняется во всех случаях Идеальный программный проект до начала конструи# рования проходит стадии тщательной выработки требований и проекти# рования архитектуры. После конструирования в идеале должно быть выполнено ис# черпывающее, статистически контролируемое тестирование системы. Однако в ре# альных проектах нашего несовершенного мира разработчики часто пропускают этапы выработки требований и проектирования, начиная прямо с конструирова# ния программы. Тестирование также часто выпадает из расписания из#за огромно# го числа ошибок и недостатка времени. Но каким бы срочным или плохо сплани# рованным ни был проект, куда без конструирования деться? Так что повышение эф# фективности конструирования ПО позволяет оптимизировать любой проект, ка# ким бы несовершенным он ни был. 1.3. Как читать эту книгу Вы можете читать эту книгу от корки до корки или по отдельным темам. Если вы предпочитаете первый вариант, переходите к главе 2. Если второй — можете на# чать с главы 6 и переходить по перекрестным ссылкам к другим темам, которые вас заинтересуют. Если вы не уверены, какой из этих вариантов вам подходит, начните с раздела 3.2. 1 Голдберг, Рубен Лушес («Руб») [Goldberg, «Rube» (Reuben Lucius)] (1883–1970) — карика# турист, скульптор. Известен своими карикатурами, в которых выдуманное им сложное обору# дование («inventions») выполняет примитивные и никому не нужные операции. Лауреат Пулит# церовской премии 1948 г. за политические карикатуры. — Прим. перев. Перекрестная ссылка О произ- водительности труда программи- стов см. подраздел «Индивиду- альные различия» раздела 28.5. ГЛАВА 1 Добро пожаловать в мир конструирования ПО! 7 Ключевые моменты Конструирование — главный этап разработки ПО, без которого не обходится ни один проект. Основные этапы конструирования: детальное проектирование, кодирование, отладка, интеграция и тестирование приложения разработчиками (блочное тестирование и интеграционное тестирование). Конструирование часто называют «кодированием» и «программированием». От качества конструирования во многом зависит качество ПО. В конечном счете ваша компетентность в конструировании ПО определяет то, насколько хороший вы программист. Совершенствованию ваших навыков и посвящена оставшаяся часть этой книги. 8 ЧАСТЬ I Основы разработки ПО Г Л А В А 2 Метафоры, позволяющие лучше понять разработку ПО Содержание 2.1. Важность метафор 2.2. Как использовать метафоры? 2.3. Популярные метафоры, характеризующие разработку ПО Связанная тема Эвристика при проектировании: подраздел «Проектирование — эвристический процесс» в разделе 5.1 Терминология компьютерных наук — одна из самых красочных. Действительно, в какой еще области существуют стерильные комнаты с тщательно контролируе# мой температурой, заполненные вирусами, троянскими конями, червями, жучка# ми и прочей живностью и нечистью? Все эти яркие метафоры описывают специфические аспекты мира программиро# вания. Более общие явления характеризуются столь же красочными метафорами, позволяющих лучше понять процесс разработки ПО. Остальная часть книги не зависит от обсуждения метафор в этой главе. Можете пропустить ее, если хотите быстрее добраться до практических советов. Если хотите яснее представлять разработку ПО, читайте дальше. 2.1. Важность метафор Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем понятное явление с чем#то похожим, но более понятным, вы можете догадаться, как справиться с проблемой. Такое использование метафор называется «модели# рованием». История науки полна открытий, сделанных благодаря метафорам. Так, химик Ке# куле однажды во сне увидел змею, схватившую себя за хвост. Проснувшись, он понял, что свойства бензола объяснила бы молекулярная структура, имеющая похожую кольцевую форму. Дальнейшие эксперименты подтвердили его гипоте# зу (Barbour, 1966). http://cc2e.com/0278 ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО 9 Кинетическая теория газов была создана на основе модели «бильярдных шаров», согласно которой молекулы газа, подобно бильярдным шарам, имеют массу и совершают упругие соударения. Волновая теория света была разработана преимущественно путем исследования сходств между светом и звуком. И свет, и звук имеют амплитуду (яркость — гром# кость), частоту (цвет — высота) и другие общие свойства. Сравнение волновых теорий звука и света оказалось столь продуктивным, что ученые потратили мно# го сил, пытаясь обнаружить среду, которая распространяла бы свет, как воздух распространяет звук. Они даже дали этой среде название — «эфир», но так и не смогли ее обнаружить. В данном случае аналогия была такой убедительной, что ввела ученых в заблуждение. В целом эффективность моделей объясняется их яркостью и концептуальной целостностью. Модели подсказывают ученым свойства, отношения и перспективные области исследований. Иногда модели вводят в заблуждение; как правило, к это# му приводит чрезмерное обобщение метафоры. Поиск эфира — наглядный при# мер чрезмерного обобщения модели. Разумеется, некоторые метафоры лучше других. Хорошими метафорами можно считать те, что отличаются простотой, согласуются с другими релевантными мета# форами и объясняют многие экспериментальные данные и наблюдаемые явления. Рассмотрим, к примеру, колебания камня, подвешенного на веревке. До Галилея сторонники Аристотеля считали, что тяжелый объект перемещается из верхней точки в нижнюю, переходя в состояние покоя. В данном случае они подумали бы, что камень падает, но с осложнениями. Когда Галилей смотрел на раскачивающийся камень, он видел маятник, поскольку камень снова и снова повторял одно и то же движение. Указанные модели фокусируют внимание на совершенно разных факторах. Пос# ледователи Аристотеля, рассматривавшие раскачивающийся камень как падающий объект, принимали в расчет вес камня, высоту, на которую он был поднят, и время, проходящее до достижения камнем состояния покоя. В модели Галилея важными были другие факторы. Он обращал внимание на вес камня, угловое смещение, ра# диус и период колебаний маятника. Благодаря этому Галилей открыл законы, кото# рые последователи Аристотеля открыть не смогли, так как их модель заставила их наблюдать за другими явлениями и задавать другие вопросы. Аналогичным образом метафоры способствуют и лучшему пониманию вопросов разработки ПО. Во время лекции по случаю получения премии Тьюринга в 1973 г., Чарльз Бахман (Charles Bachman) упомянул переход от доминировавшего геоцен# трического представления о Вселенной к гелиоцентрическому. Геоцентрическая модель Птолемея не вызывала почти никаких сомнений целых 1400 лет. Затем, в 1543 г., Коперник выдвинул гелиоцентрическую теорию, предположив, что цент# ром Вселенной на самом деле является Солнце, а не Земля. В конечном итоге та# кое изменение умозрительных моделей привело к открытию новых планет, ис# ключению Луны из категории планет и переосмыслению места человечества во Вселенной. 10 ЧАСТЬ I Основы разработки ПО Переход от геоцентрического представления к гелиоцент# рическому в астрономии Бахман сравнил с изменением, происходившим в программировании в начале 1970#х. В это время центральное место в моделях обработки данных стали отводить не компьютерам, а базам данных. Бахман указал, что создатели ранних моделей стремились рассматривать все данные как последовательный поток карт, «протекаю# щий» через компьютер (компьютеро#ориентированный подход). Суть изменения заключалась в отведении централь# ного места пулу данных, над которыми компьютер выпол# няет некоторые действия (подход, ориентированный на БД). Сегодня почти невозможно найти человека, считающего, что Солнце вращается вокруг Земли. Столь же трудно предста# вить программиста, который бы думал, что все данные мож# но рассматривать как последовательный поток карт. После опровержения старых теорий трудно понять, как кто#то когда#то мог в них верить. Еще удивительнее то, что приверженцам этих старых теорий новые теории казались такими же нелепыми, как нам старые. Геоцентрическое представление о Вселенной мешало астрономам, которые сохра# нили верность этой теории после появления лучшей. Аналогично компьютеро# ориентированное представление о компьютерной вселенной тянуло назад ком# пьютерных ученых, которые продолжили придерживаться его после появления теории, ориентированной на БД. Иногда люди упрощают суть метафор. На каждый из описанных примеров так и тянет ответить: «Разумеется, правильная метафора более полезна. Другая метафора была неверной!» Так#то оно так, но это слишком упрощенное представление. Ис# тория науки — не серия переходов от «неверных» метафор к «верным». Это серия переходов от «менее хороших» метафор к «лучшим», от менее полных теорий к более полным, от адекватного описания одной области к адекватному описанию другой. В действительности многие модели, на смену которым приходят лучшие модели, сохраняют свою полезность. Так, инженеры до сих пор решают большинство своих задач, опираясь на ньютонову динамику, хотя в теоретической физике ее вытес# нила теория Эйнштейна. Разработка ПО — относительно молодая область науки. Она еще недостаточно зрелая, чтобы иметь набор стандартных метафор. Поэтому она включает массу второстепенных и противоречивых метафор. Одни из них лучше другие — хуже. Оттого, насколько хорошо вы понимаете метафоры, зависит и ваше понимание разработки ПО. 2.2. Как использовать метафоры? Метафора, характеризующая разработку ПО, больше похожа на про# жектор, чем на дорожную карту. Она не говорит, где найти ответ — она говорит, как его искать. Метафора — это скорее эвристический подход, а не алгоритм. Не стоит недооценивать важ- ность метафор. Метафоры име- ют одно неоспоримое достоин- ство: описываемое ими поведе- ние предсказуемо и понятно всем людям. Это сокращает объем ненужной коммуникации, способствует достижению вза- имопонимания и ускоряет обу- чение. По сути метафора — это способ осмысления и абстраги- рования концепций, позволяю- щий думать в более высокой плоскости и избегать низкоуров- невых ошибок. Фернандо Дж. Корбати (Fernando J. Corbatу) |