Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 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 г., Коперник выдвинул гелиоцентрическую теорию, предположив, что цент- ром Вселенной на самом деле является Солнце, а не Земля. В конечном итоге та- кое изменение умозрительных моделей привело к открытию новых планет, ис- ключению Луны из категории планет и переосмыслению места человечества во Вселенной. 1 0 ЧАСТЬ I Основы разработки ПО Переход от геоцентрического представления к гелиоцент- рическому в астрономии Бахман сравнил с изменением, происходившим в программировании в начале 1970-х. В это время центральное место в моделях обработки данных стали отводить не компьютерам, а базам данных. Бахман указал, что создатели ранних моделей стремились рассматривать все данные как последовательный поток карт, «протекаю- щий» через компьютер (компьютеро-ориентированный подход). Суть изменения заключалась в отведении централь- ного места пулу данных, над которыми компьютер выпол- няет некоторые действия (подход, ориентированный на БД). Сегодня почти невозможно найти человека, считающего, что Солнце вращается вокруг Земли. Столь же трудно предста- вить программиста, который бы думал, что все данные мож- но рассматривать как последовательный поток карт. После опровержения старых теорий трудно понять, как кто-то когда-то мог в них верить. Еще удивительнее то, что приверженцам этих старых теорий новые теории казались такими же нелепыми, как нам старые. Геоцентрическое представление о Вселенной мешало астрономам, которые сохра- нили верность этой теории после появления лучшей. Аналогично компьютеро- ориентированное представление о компьютерной вселенной тянуло назад ком- пьютерных ученых, которые продолжили придерживаться его после появления теории, ориентированной на БД. Иногда люди упрощают суть метафор. На каждый из описанных примеров так и тянет ответить: «Разумеется, правильная метафора более полезна. Другая метафора была неверной!» Так-то оно так, но это слишком упрощенное представление. Ис- тория науки — не серия переходов от «неверных» метафор к «верным». Это серия переходов от «менее хороших» метафор к «лучшим», от менее полных теорий к более полным, от адекватного описания одной области к адекватному описанию другой. В действительности многие модели, на смену которым приходят лучшие модели, сохраняют свою полезность. Так, инженеры до сих пор решают большинство своих задач, опираясь на ньютонову динамику, хотя в теоретической физике ее вытес- нила теория Эйнштейна. Разработка ПО — относительно молодая область науки. Она еще недостаточно зрелая, чтобы иметь набор стандартных метафор. Поэтому она включает массу второстепенных и противоречивых метафор. Одни из них лучше другие — хуже. Оттого, насколько хорошо вы понимаете метафоры, зависит и ваше понимание разработки ПО. 2.2. Как использовать метафоры? Метафора, характеризующая разработку ПО, больше похожа на про- жектор, чем на дорожную карту. Она не говорит, где найти ответ — она говорит, как его искать. Метафора — это скорее эвристический подход, а не алгоритм. Не стоит недооценивать важ- ность метафор. Метафоры име- ют одно неоспоримое достоин- ство: описываемое ими поведе- ние предсказуемо и понятно всем людям. Это сокращает объем ненужной коммуникации, способствует достижению вза- имопонимания и ускоряет обу- чение. По сути метафора — это способ осмысления и абстраги- рования концепций, позволяю- щий думать в более высокой плоскости и избегать низкоуров- невых ошибок. Фернандо Дж. Корбати (Fernando J. Corbatу) |