Главная Совершенный код. Мастер-класс

Совершенный код. Мастер-класс

0 / 0
Насколько вам понравилась эта книга?
Какого качества скаченный файл?
Скачайте книгу, чтобы оценить ее качество
Какого качества скаченные файлы?
Более 10 лет первое издание этой книги считалось одним из лучших практических руководств по программированию. Сейчас эта книга полностью обновлена с учетом современных тенденций и технологий и дополнена сотнями новых примеров, иллюстрирующих искусство и науку программирования. Опираясь на академические исследования, с одной стороны, и практический опыт коммерческих разработок ПО с другой, автор синтезировал из самых эффективных методик и наиболее эффективных принципов ясное прагматичное руководство. Каков бы ни был ваш профессиональный уровень, с какими бы средствами разработками вы ни работали, какова бы ни была сложность вашего проекта, в этой книге вы найдете нужную информацию, она заставит вас размышлять и поможет создать совершенный код.

Книга состоит из 35 глав, предметного указателя и библиографии.
Категории:
Год:
2010
Издание:
2
Издательство:
Издательство «Русская редакция»
Язык:
russian
Страницы:
896
ISBN 13:
9785750200641
Файл:
PDF, 6,13 MB
Скачать (pdf, 6,13 MB)

Возможно Вас заинтересует Powered by Rec2Me

 

Ключевые слова

 
0 comments
 

Чтобы оставить отзыв, пожалуйста, войдите или зарегистрируйтесь
Вы можете оставить отзыв о книге и поделиться своим опытом. Другим читателям будет интересно узнать ваше мнение о прочитанных книгах. Независимо от того, пришлась ли вам книга по душе или нет, если вы честно и подробно расскажете об этом, люди смогут найти для себя новые книги, которые их заинтересуют.
«Великолепное руководство по стилю программирования и конструированию ПО».
Мартин Фаулер, автор книги «Refactoring»
«Книга Стива Макконнелла… это быстрый путь к мудрому программированию… Его книги
увлекательны, и вы никогда не забудете то, что он рассказывает, опираясь на свой с тру#
дом полученный опыт».
Джон Бентли, автор книги «Programming Pearls, 2d ed»
«Это просто самая лучшая книга по конструированию ПО из всех, что когда#либо попада#
лись мне в руки. Каждый разработчик должен иметь ее и перечитывать от корки до корки
каждый год. Я ежегодно перечитываю ее на протяжении вот уже девяти лет и все еще уз#
наю много нового!»
Джон Роббинс, автор книги «Debugging Applications
for Microsoft .NET and Microsoft Windows»
«Современное ПО должно быть надежным и гибким, а создание защищенного кода начи#
нается с дисциплинированного конструирования программы. За десять лет так и не по#
явилось лучшего руководства по этой теме, чем эта книга.
Майкл Ховард, специалист по защите ПО, корпорация Microsoft;
один из авторов книги «Writing Secure Code»
«Это исчерпывающее исследование тактических аспектов создания хорошо спроектиро#
ванных программ. Книга Макконнелла охватывает такие разные темы, как архитектура,
стандарты кодирования, тестирование, интеграция и суть разработки ПО».
Гради Буч, автор книги «Object Solutions»
«Авторитетная энциклопедия для разработчиков ПО — вот что такое „Совершенный код“.
Подзаголовок „Практическое руководство по конструированию ПО“ характеризует эту 850#
страничную книгу абсолютно точно. Как утверждает автор, она призвана сократить раз#
рыв между знаниями „гуру и лучших специалистов отрасли“ (например, Йордона и Прес#
смана) и общепринятыми методиками разработки коммерческого ПО, а также „помочь
создавать более качественные программы за меньшее время с меньшей головной болью“…
Эту книгу следует иметь каждому разработчику. Ее стиль и содержание в высшей степени
практичны».
Крис Лузли, автор книги «High%Performance Client/Server»
«Полная плодотворных идей книга Макконнелла „Совершенный код“ ; — это одна из са#
мых понятных работ, посвященных подробному обсуждению методик разработки ПО…»
Эрик Бетке, автор книги «Game Development and Production»
«Кладезь полезной информации и рекомендаций по общим вопросам проектирования и
разработки хорошего ПО».
Джон Демпстер, автор книги «The Laboratory Computer:
A Practical Guide for Physiologists and Neuroscientists»
«Если вы действительно хотите улучшить навыки программирования, обязательно прочтите
книгу „Совершенный код“ Стива Макконнелла».
Джин Дж. Лаброссе, автор книги «Embedded Systems Building Blocks:
Complete and Ready%To%Use Modules in C»
«Стив Макконнелл написал одну из лучших книг по разработке ПО, не привязанных к
конкретной среде…»
Кеннет Розен, один из авторов книги «Unix: The Complete Reference»

«Пару раз в поколение или около того появляются книги, обобщающие накопленный опыт
и избавляющие вас от многих лет мучений… Не могу найти слов, чтобы адекватно опи#
сать все великолепие этой книги. „Совершенный код“ — довольно жалкое название для
такой превосходной работы».
Джефф Дантеманн, журнал «PC Techniques»
«Издательство Microsoft Press опубликовало то, что я считаю самой лучшей книгой по конст#
руированию ПО. Эта книга должна занять место на книжной полке каждого программиста».
Уоррен Кеуффель, журнал «Software Development»
«Эту выдающуюся книгу следует прочесть каждому программисту».
Т. Л. (Фрэнк) Паппас, журнал «Computer»
«Если вы собираетесь стать профессиональным программистом, покупка этой книги, по#
жалуй, станет самым мудрым вложением средств. Можете не читать этот обзор дальше —
просто идите в магазин и купите ее. Как пишет сам Макконнелл, его целью было сокра#
щение разрыва между знаниями гуру и общепринятыми методиками разработки коммер#
ческого ПО… Удивительно, но ему это удалось».
Ричард Матеосян, журнал «IEEE Micro»
«„Совершенный код“ — обязательное чтение для всех… кто имеет отношение к разработ#
ке ПО».
Томми Ашер, журнал «C Users Journal»
«Я вынужден сделать чуть более категоричное заявление, чем обычно, и рекомендовать
книгу Стива Макконнелла „Совершенный код“ всем разработчикам без всяких оговорок…
Если раньше во время работы я держал ближе всего к клавиатуре руководства по API, то
теперь их место заняла книга Макконнелла».
Джим Кайл, журнал «Windows Tech Journal»
«Это лучшая книга по разработке ПО из всех, что я читал».
Эдвард Кенворт, журнал «.EXE»
«Эта книга заслуживает статуса классической, и ее в обязательном порядке должны про#
честь все разработчики и те, кто ими управляет».
Питер Райт, «Program Now»

Посвящаю эту книгу своей жене Эшли, которая не имеет особого отношения
к программированию, но настолько обогащает всю мою остальную жизнь,
что я не могу выразить это в словах.

Steve McConnell

CODE

COMPLETE

Second Edition

Стив Макконнелл

Совершенный

КОД

МАСТЕР-КЛАСС

2010

УДК 004.45
ББК 32.973.26–018.2
М15
Макконнелл С.
М15

Совершенный код. Мастер#класс / Пер. с англ. — М. : Издательство «Русская
редакция», 2010. — 896 стр. : ил.
ISBN 978-5750200641
Более 10 лет первое издание этой книги считалось одним из лучших практических
руководств по программированию. Сейчас эта книга полностью обновлена с учетом
современных тенденций и технологий и дополнена сотнями новых примеров, иллюстрирующих искусство и науку программирования. Опираясь на академические
исследования, с одной стороны, и практический опыт коммерческих разработок ПО —
с другой, автор синтезировал из самых эффективных методик и наиболее эффективных принципов ясное прагматичное руководство. Каков бы ни был ваш профессиональный уровень, с какими бы средствами разработками вы ни работали, какова бы
ни была сложность вашего проекта, в этой книге вы найдете нужную информацию,
она заставит вас размышлять и поможет создать совершенный код.
Книга состоит из 35 глав, предметного указателя и библиографии.

УДК 004.45
ББК 32.973.26–018.2
© 2005-2012, Translation Russian Edition Publishers.
Authorized Russian translation of the English edition of Code Complete, Second Edition, ISBN 9780735619678
© Steven C. McConnell.
This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish
and sell the same.
© 2005-2012, перевод ООО «Издательство «Русская редакция».
Авторизованный перевод с английского на русский язык произведения Code Complete, Second Edition,
ISBN 9780735619678 © Steven C. McConnell.
Этот перевод оригинального издания публикуется и продается с разрешения O’Reilly Media, Inc., которая владеет
или распоряжается всеми правами на его публикацию и продажу.
© 2005-2012, оформление и подготовка к изданию, ООО «Издательство «Русская редакция».
Microsoft, а также товарные знаки, перечисленные в списке, расположенном по адресу:
http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx
являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других
странах. Все другие товарные знаки являются собственностью соответствующих фирм.
Все названия компаний, организаций и продуктов, а также имена лиц, используемые в примерах, вымышлены
и не имеют никакого отношения к реальным компаниям, организациям, продуктам и лицам.

Содержание

VII

Содержание
Предисловие .................................................................................................................... XIII
Благодарности ................................................................................................................ XIX
Контрольные списки ...................................................................................................... XXI

Часть I

Основы разработки ПО

1 Добро пожаловать в мир конструирования ПО! .................................................... 2
1.1. Что такое конструирование ПО? ................................................................................................. 2
1.2. Почему конструирование ПО так важно? ........................................................................... 5
1.3. Как читать эту книгу ................................................................................................................................ 6
2 Метафоры, позволяющие лучше понять разработку ПО .................................... 8
2.1. Важность метафор ...................................................................................................................................... 8
2.2. Как использовать метафоры? ...................................................................................................... 10
2.3. Популярные метафоры, характеризующие разработку ПО ........................ 12
3 Семь раз отмерь, один раз отрежь: предварительные условия ...................... 21
3.1. Важность выполнения предварительных условий ............................................... 22
3.2. Определите тип ПО, над которым вы работаете ..................................................... 28
3.3. Предварительные условия, связанные
с определением проблемы ...................................................................................................................... 34
3.4. Предварительные условия, связанные с выработкой требований ....... 36
3.5. Предварительные условия, связанные
с разработкой архитектуры .................................................................................................................... 41
3.6. Сколько времени следует посвятить выполнению
предварительных условий? ..................................................................................................................... 52
4 Основные решения, которые приходится принимать
при конструировании ................................................................................................ 58
4.1. Выбор языка программирования ........................................................................................... 59
4.2. Конвенции программирования ............................................................................................... 63
4.3. Волны развития технологий ........................................................................................................ 64
4.4. Выбор основных методик конструирования ............................................................. 66

Часть II

Высококачественный код

5 Проектирование при конструировании ................................................................. 70
5.1. Проблемы, связанные с проектированием ПО ......................................................... 71
5.2. Основные концепции проектирования ........................................................................... 74
5.3. Компоненты проектирования: эвристические принципы ........................... 84
5.4. Методики проектирования ........................................................................................................ 107
5.5. Комментарии по поводу популярных методологий ........................................ 115
6 Классы ........................................................................................................................ 121
6.1. Основы классов: абстрактные типы данных ............................................................ 122
6.2. Качественные интерфейсы классов .................................................................................. 129
6.3. Вопросы проектирования и реализации ..................................................................... 139

VIII

Содержание

6.4. Разумные причины создания классов ............................................................................. 148
6.5. Аспекты, специфические для языков ................................................................................ 152
6.6. Следующий уровень: пакеты классов ............................................................................... 153
7 Высококачественные методы ............................................................................... 157
7.1. Разумные причины создания методов ............................................................................ 160
7.2. Проектирование на уровне методов ................................................................................ 163
7.3. Удачные имена методов ................................................................................................................. 167
7.4. Насколько объемным может быть метод? ................................................................... 169
7.5. Советы по использованию параметров методов ................................................. 170
7.6. Отдельные соображения по использованию функций ................................. 177
7.7. Методы#макросы и встраиваемые методы ................................................................. 178
8 Защитное программирование ................................................................................ 182
8.1. Защита программы от неправильных входных данных .............................. 183
8.2. Утверждения .............................................................................................................................................. 184
8.3. Способы обработки ошибок .................................................................................................... 189
8.4. Исключения ............................................................................................................................................... 193
8.5. Изоляция повреждений, вызванных ошибками ................................................... 198
8.6. Отладочные средства ....................................................................................................................... 200
8.7. Доля защитного программирования в промышленной версии ........... 204
8.8. Защита от защитного программирования ................................................................. 206
9 Процесс программирования с псевдокодом ...................................................... 209
9.1. Этапы создания классов и методов .................................................................................... 210
9.2. Псевдокод для профи ....................................................................................................................... 211
9.3. Конструирование методов с использованием ППП ......................................... 214
9.4. Альтернативы ППП ............................................................................................................................. 225

Часть III

Переменные

10 Общие принципы использования переменных ................................................ 230
10.1. Что вы знаете о данных? ............................................................................................................. 231
10.2. Грамотное объявление переменных ............................................................................. 232
10.3. Принципы инициализации переменных ................................................................ 233
10.4. Область видимости ......................................................................................................................... 238
10.5. Персистентность ............................................................................................................................... 245
10.6. Время связывания ............................................................................................................................. 246
10.7. Связь между типами данных и управляющими структурами ............... 247
10.8. Единственность цели каждой переменной ............................................................ 249
11 Сила имен переменных ......................................................................................... 252
11.1. Общие принципы выбора имен переменных ..................................................... 253
11.2. Именование конкретных типов данных ................................................................... 257
11.3. Сила конвенций именования ............................................................................................... 263
11.4. Неформальные конвенции именования ................................................................... 264
11.5. Стандартизованные префиксы ........................................................................................... 272
11.6. Грамотное сокращение имен переменных ............................................................ 274
11.7. Имена, которых следует избегать ..................................................................................... 277

Содержание

IX

12 Основные типы данных ......................................................................................... 282
12.1. Числа в общем ...................................................................................................................................... 283
12.2. Целые числа ............................................................................................................................................ 284
12.3. Числа с плавающей запятой ................................................................................................... 286
12.4. Символы и строки ............................................................................................................................ 289
12.5. Логические переменные ............................................................................................................ 292
12.6. Перечислимые типы ...................................................................................................................... 294
12.7. Именованные константы .......................................................................................................... 299
12.8. Массивы ...................................................................................................................................................... 301
12.9. Создание собственных типов данных (псевдонимы) ................................. 303
13 Нестандартные типы данных ............................................................................... 310
13.1. Структуры ................................................................................................................................................. 310
13.2. Указатели ................................................................................................................................................... 314
13.3. Глобальные данные ......................................................................................................................... 326

Часть IV

Операторы

14 Организация последовательного кода .............................................................. 338
14.1. Операторы, следующие в определенном порядке ........................................... 338
14.2. Операторы, следующие в произвольном порядке ........................................... 342
15 Условные операторы ............................................................................................. 346
15.1. Операторы if ........................................................................................................................................... 346
15.2. Операторы case ................................................................................................................................... 353
16

Циклы ........................................................................................................................ 359
16.1. Выбор типа цикла ............................................................................................................................. 359
16.2. Управление циклом ........................................................................................................................ 365
16.3. Простое создание цикла — изнутри наружу ......................................................... 378
16.4. Соответствие между циклами и массивами ........................................................... 379

17 Нестандартные управляющие структуры ......................................................... 382
17.1. Множественные возвраты из метода ............................................................................ 382
17.2. Рекурсия ...................................................................................................................................................... 385
17.3. Оператор goto ....................................................................................................................................... 389
17.4. Перспективы нестандартных управляющих структур ................................ 401
18 Табличные методы ................................................................................................. 404
18.1. Основные вопросы применения табличных методов ................................ 405
18.2. Таблицы с прямым доступом ................................................................................................. 406
18.3. Таблицы с индексированным доступом .................................................................... 418
18.4. Таблицы со ступенчатым доступом ................................................................................ 419
18.5. Другие примеры табличного поиска ............................................................................ 422
19 Общие вопросы управления ................................................................................ 424
19.1. Логические выражения ............................................................................................................... 424
19.2. Составные операторы (блоки) ............................................................................................ 436
19.3. Пустые выражения ........................................................................................................................... 437
19.4. Укрощение опасно глубокой вложенности ........................................................... 438

Содержание

X

19.5. Основа программирования: структурное программирование .......... 448
19.6. Управляющие структуры и сложность ........................................................................ 450

Часть V

Усовершенствование кода

20 Качество ПО ............................................................................................................. 456
20.1. Характеристики качества ПО ............................................................................................... 456
20.2. Методики повышения качества ПО ................................................................................ 459
20.3. Относительная эффективность
методик контроля качества ПО ....................................................................................................... 462
20.4. Когда выполнять контроль качества ПО? ................................................................. 466
20.5. Главный Закон Контроля Качества ПО ....................................................................... 467
21 Совместное конструирование ............................................................................. 471
21.1. Обзор методик совместной разработки ПО ......................................................... 472
21.2. Парное программирование .................................................................................................... 475
21.3. Формальные инспекции ............................................................................................................ 477
21.4. Другие методики совместной разработки ПО .................................................... 484
21.5. Сравнение методик совместного конструирования ..................................... 487
22 Тестирование, выполняемое разработчиками ................................................. 490
22.1. Тестирование, выполняемое разработчиками, и качество ПО ........... 492
22.2. Рекомендуемый подход к тестированию, выполняемому
разработчиками ............................................................................................................................................... 494
22.3. Приемы тестирования ................................................................................................................. 496
22.4. Типичные ошибки ............................................................................................................................ 507
22.5. Инструменты тестирования ................................................................................................... 513
22.6. Оптимизация процесса тестирования ........................................................................ 518
22.7. Протоколы тестирования ......................................................................................................... 520
23 Отладка ..................................................................................................................... 524
23.1. Общие вопросы отладки ............................................................................................................ 524
23.2. Поиск дефекта ...................................................................................................................................... 529
23.3. Устранение дефекта ........................................................................................................................ 539
23.4. Психологические аспекты отладки ................................................................................ 543
23.5. Инструменты отладки — очевидные и не очень ............................................... 545
24 Рефакторинг ............................................................................................................ 551
24.1. Виды эволюции ПО ......................................................................................................................... 552
24.2. Введение в рефакторинг ............................................................................................................ 553
24.3. Отдельные виды рефакторинга .......................................................................................... 559
24.4. Безопасный рефакторинг ........................................................................................................ 566
24.5. Стратегии рефакторинга .......................................................................................................... 568
25 Стратегии оптимизации кода ............................................................................... 572
25.1. Общее обсуждение производительности ПО ...................................................... 573
25.2. Введение в оптимизацию кода ............................................................................................ 576
25.3. Где искать жир и патоку? ............................................................................................................ 583
25.4. Оценка производительности ................................................................................................ 588

Содержание

XI

25.5. Итерация .................................................................................................................................................... 590
25.6. Подход к оптимизации кода: резюме ........................................................................... 591
26 Методики оптимизации кода ................................................................................ 595
26.1. Логика ........................................................................................................................................................... 596
26.2. Циклы ............................................................................................................................................................ 602
26.3. Изменения типов данных ......................................................................................................... 611
26.4. Выражения ............................................................................................................................................... 616
26.5. Методы ......................................................................................................................................................... 625
26.6. Переписывание кода на низкоуровневом языке ............................................... 626
26.7. Если что#то одно изменяется, что#то
другое всегда остается постоянным ............................................................................................ 629

Системные вопросы

Часть VI

27 Как размер программы влияет на конструирование ...................................... 634
27.1. Взаимодействие и размер ......................................................................................................... 635
27.2. Диапазон размеров проектов ................................................................................................ 636
27.3. Влияние размера проекта на возникновение ошибок ................................ 636
27.4. Влияние размера проекта на производительность ........................................ 638
27.5. Влияние размера проекта на процесс разработки ......................................... 639
28 Управление конструированием ........................................................................... 645
28.1. Поощрение хорошего кодирования ............................................................................. 646
28.2. Управление конфигурацией .................................................................................................. 649
28.3. Оценка графика конструирования ................................................................................. 655
28.4. Измерения ................................................................................................................................................ 661
28.5. Гуманное отношение к программистам ..................................................................... 664
28.6. Управление менеджером ........................................................................................................... 670
29

Интеграция ............................................................................................................... 673
29.1. Важность выбора подхода к интеграции .................................................................. 673
29.2. Частота интеграции — поэтапная или инкрементная? .............................. 675
29.3. Стратегии инкрементной интеграции ....................................................................... 678
29.4. Ежедневная сборка и дымовые тесты ........................................................................... 686

30 Инструменты программирования ....................................................................... 694
30.1. Инструменты для проектирования ................................................................................. 695
30.2. Инструменты для работы с исходным кодом ....................................................... 695
30.3. Инструменты для работы с исполняемым кодом ............................................. 700
30.4. Инструменты и среды ................................................................................................................... 704
30.5. Создание собственного программного инструментария ....................... 705
30.6. Волшебная страна инструментальных средств .................................................. 707

Часть VII

Мастерство программирования

31 Форматирование и стиль ...................................................................................... 712
31.1. Основные принципы форматирования .................................................................... 713
31.2. Способы форматирования ...................................................................................................... 720
31.3. Стили форматирования ............................................................................................................. 721

XII

Содержание

31.4. Форматирование управляющих структур ............................................................... 728
31.5. Форматирование отдельных операторов ................................................................ 736
31.6. Размещение комментариев ..................................................................................................... 747
31.7. Размещение методов ...................................................................................................................... 750
31.8. Форматирование классов ......................................................................................................... 752
32 Самодокументирующийся код ............................................................................ 760
32.1. Внешняя документация ............................................................................................................... 760
32.2. Стиль программирования как вид документации ........................................... 761
32.3. Комментировать или не комментировать? ............................................................. 764
32.4. Советы по эффективному комментированию .................................................... 768
32.5. Методики комментирования ................................................................................................ 774
32.6. Стандарты IEEE .................................................................................................................................... 795
33 Личность ................................................................................................................... 800
33.1. Причем тут характер? ................................................................................................................... 801
33.2. Интеллект и скромность ............................................................................................................ 802
33.3. Любопытство ......................................................................................................................................... 803
33.4. Профессиональная честность ............................................................................................. 806
33.5. Общение и сотрудничество ................................................................................................... 809
33.6. Творчество и дисциплина ........................................................................................................ 809
33.7. Лень ................................................................................................................................................................. 810
33.8. Свойства, которые менее важны, чем кажется ..................................................... 811
33.9. Привычки .................................................................................................................................................. 813
34 Основы мастерства ................................................................................................ 817
34.1. Боритесь со сложностью ........................................................................................................... 817
34.2. Анализируйте процесс разработки ................................................................................ 819
34.3. Пишите программы в первую очередь для людей и лишь во вторую —
для компьютеров ............................................................................................................................................. 821
34.4. Программируйте с использованием языка, а не на языке ....................... 823
34.5. Концентрируйте внимание с помощью соглашений .................................. 824
34.6. Программируйте в терминах проблемной области ..................................... 825
34.7. Опасайтесь падающих камней ............................................................................................ 827
34.8. Итерируйте, итерируйте и итерируйте ...................................................................... 830
34.9. И да отделена будет религия от разработки ПО ................................................ 831
35 Где искать дополнительную информацию ....................................................... 834
35.1. Информация о конструировании ПО ......................................................................... 835
35.2. Не связанные с конструированием темы ................................................................. 836
35.3. Периодические издания ............................................................................................................ 838
35.4. Список литературы для разработчика ПО .............................................................. 839
35.5. Профессиональные ассоциации ...................................................................................... 841
Библиография ................................................................................................................. 842
Предметный указатель ................................................................................................. 863
Об авторе .......................................................................................................................... 868

Предисловие

Разрыв между самыми лучшими и средними методиками разработки ПО очень широк
— вероятно, шире, чем в любой другой инженерной дисциплине. Средство распро%
странения информации о хороших методиках сыграло бы весьма важную роль.
Фред Брукс (Fred Brooks)
Моей главной целью при написании этой книги было сокращение разрыва между знани#
ями гуру и лучших специалистов отрасли, с одной стороны, и общепринятыми методика#
ми разработки коммерческого ПО — с другой. Многие эффективные методики програм#
мирования годами скрываются в журналах и научных работах, прежде чем становятся
доступными программистской общественности.
Хотя передовые методики разработки ПО в последние годы быстро развивались, общепри#
нятые практически стояли на месте. Многие программы все еще полны ошибок, поставля#
ются с опозданием и не укладываются в бюджет, а многие не отвечают требованиям пользо#
вателей. Ученые обнаружили эффективные методики, устраняющие большинство проблем,
которые отравляют нашу жизнь с 1970#х годов. Однако из#за того, что эти методики редко
покидают страницы узкоспециализированных технических изданий, в большинстве ком#
паний по разработке ПО они еще не используются. Установлено, что для широкого распро#
странения исследовательских разработок обычно требуется от 5 до 15 и более лет (Raghavan
and Chand, 1989; Rogers, 1995; Parnas, 1999). Данная книга призвана ускорить этот процесс
и сделать важные открытия доступными средним программистам.

Кому следует прочитать эту книгу?
Исследования и опыт программирования, отраженные в этой книге, помогут вам созда#
вать высококачественное ПО и выполнять свою работу быстрее и эффективнее. Прочи#
тав ее, вы поймете, почему вы сталкивались с проблемами в прошлом, и узнаете, как избе#
гать их в будущем. Описанные мной методики программирования помогут вам сохранять
контроль над крупными проектами, а также успешно сопровождать и изменять ПО при
изменении требований.

Опытные программисты
Эта книга окажется полезной опытным программистам, желающим получить всесторон#
нее и удобное руководство по разработке ПО. Так как эта книга фокусируется на констру#
ировании — самой известной части жизненного цикла ПО, — описанные в ней методики
будут понятны и программистам, имеющим соответствующее образование, и программи#
стам#самоучкам.

Технические лидеры
Многие технические лидеры используют первое издание этой книги для обучения менее
опытных членов своих групп. Вы также можете использовать эту книгу для восполнения
пробелов в своих знаниях. Если вы — опытный программист, то, наверное, согласитесь
не со всеми моими выводами (обратное было бы странным), но, если вы прочитаете весь
материал и обдумаете каждый поднятый вопрос, едва ли какая#то возникшая проблема
конструирования окажется для вас новой.

XIV

Предисловие

Программисты-самоучки
Если вы не имеете специального образования, вы не одиноки. Ежегодно программистами
становятся около 50 000 человек (BLS, 2004, Hecker 2004), однако число дипломов, вруча#
емых ежегодно в нашей отрасли, составляет лишь около 35 000 (NCES, 2002). Легко прий#
ти к выводу, что многие программисты изучают разработку ПО самостоятельно. Програм#
мисты#самоучки встречаются среди инженеров, бухгалтеров, ученых, преподавателей, вла#
дельцев малого бизнеса и представителей других профессий, которые занимаются про#
граммированием в рамках своей работы, но не всегда считают себя программистами. Каким
бы ни было ваше программистское образование, в этом руководстве вы найдете инфор#
мацию об эффективных методиках программирования.

Студенты
В отличие от программистов, которые обладают опытом, но не могут похвастаться специ#
альным обучением, недавние выпускники вузов часто имеют обширные теоретические знания,
но плохо владеют практическими ноу#хау, связанными с созданием реальных программ.
Передача практических навыков хорошего кодирования зачастую идет медленно, в риту#
альных танцах архитекторов ПО, лидеров проектов, аналитиков и более опытных програм#
мистов. Еще чаще эти навыки приобретаются программистами в результате собственных
проб и ошибок. Эта книга — альтернатива традиционным неспешным интеллектуальным
ритуалам. В ней собраны полезные советы и эффективные стратегии разработки, которые
ранее можно было узнать главным образом только непосредственно у других людей. Это
трамплин для студентов, переходящих из академической среды в профессиональную.

Где еще можно найти эту информацию?
В этой книге собраны методики конструирования из самых разнообразных источников.
Многие знания о конструировании не только разрозненны, но и годами не попадают в
печатные издания (Hildebrand, 1989; McConnell, 1997a). В эффективных, мощных методи#
ках программирования, используемых лучшими программистами, нет ничего мистиче#
ского, однако в повседневной череде неотложных задач очень немногие эксперты выкра#
ивают время на то, чтобы поделиться своим опытом. Таким образом, программистам трудно
найти хороший источник информации о программировании.
Методики, описанные в этой книге, заполняют пустоту, остающуюся в знаниях програм#
мистов после прочтения вводных и более серьезных учебников по программированию.
Что читать человеку, изучившему книги типа «Introduction to Java», «Advanced Java» и
«Advanced Advanced Java» и желающему узнать о программировании больше? Вы можете
читать книги о процессорах Intel или Motorola, функциях ОС Microsoft Windows или Linux
или о другом языке программирования — невозможно эффективно программировать, не
имея хорошего представления о таких деталях. Но эта книга относится к числу тех не#
многих, в которых обсуждается программирование как таковое. Наибольшую пользу при#
носят те методики, которые можно использовать независимо от среды или языка. В дру#
гих источниках такие методики обычно игнорируются, и именно поэтому я сосредото#
чился на них.
Как показано ниже, информация, представленная в этой книге, выжата из многих источ#
ников. Единственным другим способом получения этой информации является изучение
горы книг и нескольких сотен технических журналов, дополненное значительным реаль#
ным опытом. Если вы уже проделали все это, данная книга все равно окажется вам полез#
ной как удобный справочник.

Предисловие

XV

Главные достоинства этой книги
Какой бы ни была ваша ситуация, эта книга поможет вам создавать более качественные
программы за меньшее время с меньшей головной болью.
Полное руководство по конструированию ПО В этой книге обсуждаются такие об#
щие аспекты конструирования, как качество ПО и подходы к размышлению о програм#
мировании. В то же время мы погрузимся в такие детали конструирования, как этапы со#
здания классов, использование данных и управляющих структур, отладка, рефакторинг и
методики и стратегии оптимизации кода. Чтобы изучить эти вопросы, вам не нужно чи#
тать книгу от корки до корки. Материал организован так, чтобы вы могли легко найти кон#
кретную интересующую вас информацию.
Готовые к использованию контрольные списки Эта книга включает десятки конт#
рольных списков, позволяющих оценить архитектуру программы, подход к проектирова#
нию, качество классов и методов, имена переменных, управляющие структуры, формати#
рование, тесты и многое другое.
Самая актуальная информация В этом руководстве вы найдете описания ряда самых
современных методик, многие из которых еще не стали общепринятыми. Так как эта книга
основана и на практике, и на исследованиях, рассмотренные в ней методики будут полез#
ны еще многие годы.
Более общий взгляд на разработку ПО Эта книга даст вам шанс подняться над суе#
той повседневной борьбы с проблемами и узнать, что работает, а что нет. Мало кто из прак#
тикующих программистов обладает временем, необходимым для прочтения сотен книг и
журнальных статей, обобщенных в этом руководстве. Исследования и реальный опыт, на
которых основана данная книга, помогут вам проанализировать ваши проекты и позво#
лят принимать стратегические решения, чтобы не приходилось бороться с теми же вра#
гами снова и снова.
Объективность Некоторые книги по программированию содержат 1 грамм информа#
ции на 10 граммов рекламы. Здесь вы найдете сбалансированные обсуждения достоинств
и недостатков каждой методики. Вы знаете свой конкретный проект лучше всех, и эта книга
предоставит вам объективную информацию, нужную для принятия грамотных решений
в ваших обстоятельствах.
Независимость от языка Описанные мной методики позволяют выжать максимум по#
чти из любого языка, будь то C++, C#, Java, Microsoft Visual Basic или другой похожий язык.
Многочисленные примеры кода Эта книга содержит почти 500 примеров хорошего
и плохого кода. Их так много потому, что лично я лучше всего учусь на примерах. Думаю,
это относится и к другим программистам.

XVI

Предисловие

Примеры написаны на нескольких языках, потому что освоение более одного языка час#
то является поворотным пунктом в карьере профессионального программиста. Как толь#
ко программист понимает, что принципы программирования не зависят от синтаксиса
конкретного языка, он начинает приобретать знания, позволяющие достичь новых высот
качества и производительности труда.
Чтобы как можно более облегчить бремя применения нескольких языков, я избегал ред#
ких возможностей языков, кроме тех фрагментов, в которых именно они и обсуждаются.
Вам не нужно понимать каждый нюанс фрагментов кода, чтобы понять их суть. Если вы
сосредоточитесь на обсуждаемых моментах, вы сможете читать код на любом языке. Что#
бы сделать вашу задачу еще легче, я пояснил важные части примеров.
Доступ к другим источникам информации В данном руководстве приводятся под#
робные сведения о конструировании ПО, но едва ли это последнее слово. В разделах «До#
полнительные ресурсы» я указал другие книги и статьи, которые вы можете прочитать, если
заинтересуетесь той или иной темой.
Web'сайт книги Обновленные контрольные списки, списки
книг и журнальных статей, Web#ссылки и другую информацию
можно найти на Web#сайте cc2e.com. Для получения информации,
связанной с «Code Complete, 2d ed.», введите в браузере cc2e.com/
и четырехзначное число, пример которого показан слева. Читая книгу, вы много раз на#
толкнетесь на такие ссылки.
http://cc2e.com/1234

Что побудило меня написать эту книгу?
Необходимость руководств, отражающих знания об эффективных методиках разработки
ПО, ясна всем членам сообщества разработчиков. Согласно отчету совета Computer Science
and Technology Board максимальное повышение качества и продуктивности разработки
ПО будет достигнуто благодаря систематизации, унификации и распространению суще#
ствующих знаний об эффективных методиках разработки (CSTB, 1990; McConnell, 1997a).
Совет пришел к выводу, что стратегия распространения этих знаний должна быть осно#
вана на концепции руководств по разработке ПО.

Тема конструирования игнорировалась
Одно время разработка ПО и кодирование рассматривались как одно и то же. Однако по
мере идентификации разных процессов цикла разработки ПО лучшие умы отрасли стали
посвящать время анализу и обсуждению методик управления проектами, выработки тре#
бований, проектирования и тестирования. Из#за пристального внимания к этим новым
областям конструирование кода превратилось в бедного родственника разработки ПО.
Кроме того, обсуждению конструирования препятствовало предположение, согласно ко#
торому подход к конструированию как к отдельному процессу разработки ПО подразуме#
вает, что конструирование нужно рассматривать при этом как отдельный этап. На самом
деле процессы и этапы разработки не обязаны быть связаны какими#то отношениями, и
обсуждение процесса конструирования полезно независимо от того, выполняются ли другие
процессы разработки ПО как этапы, итерации или как#то иначе.

Конструирование важно
Другая причина того, что конструирование игнорируется учеными и авторами, заключа#
ется в ошибочной идее, что в сравнении с другими процессами разработки ПО констру#
ирование является относительно механическим процессом, допускающим мало возмож#
ностей улучшения. Ничто не может быть дальше от истины.
На конструирование кода обычно приходятся около 65% работы в небольших и 50% в
средних проектах. Во время конструирования допускаются около 75% ошибок в неболь#

Предисловие

XVII

ших проектах и от 50 до 75% в средних и крупных. Очевидно, что любой процесс, связан#
ный с такой долей ошибок, можно значительно улучшить (подробнее эти статистические
данные рассматриваются в главе 27).
Некоторые авторы указывают, что, хотя ошибки конструирования и составляют высокий
процент от общего числа ошибок, их обычно дешевле исправлять, чем ошибки в требо#
ваниях или архитектуре, поэтому они менее важны. Утверждение, что ошибки конструи#
рования дешевле исправлять, верно, но вводит в заблуждение, потому что стоимость не#
исправленной ошибки конструирования может быть крайней высокой. Ученые обнару#
жили, что одними из самых дорогих ошибок в истории, приведшими к убыткам в сотни
миллионов долларов, были мелкие ошибки кодирования (Weinberg, 1983; SEN, 1990). Не#
высокая стоимость исправления ошибок не подразумевает, что их исправление можно
считать низкоприоритетной задачей.
Ирония ослабления внимания к конструированию состоит в том, что конструирование
— единственный процесс, который выполняется всегда. Требования можно предположить,
а не разработать, архитектуру можно обрисовать в самых общих чертах, а тестирование
можно сократить или вообще опустить. Но если вы собираетесь написать программу, из#
бежать конструирования не удастся, и это делает конструирование на редкость плодотвор#
ной областью улучшения методик разработки.

Отсутствие похожих книг
Когда я начал подумывать об этой книге, я был уверен, что кто#то другой уже написал об
эффективных методиках конструирования. Необходимость такой книги казалась очевид#
ной. Но я обнаружил лишь несколько книг о конструировании, описывающих лишь неко#
торые его аспекты. Одни были написаны 15 или более лет назад и были основаны на от#
носительно редких языках, таких как ALGOL, PL/I, Ratfor и Smalltalk. Другие были написа#
ны профессорами, не работавшими над реальным кодом. Профессора писали о методи#
ках, работающих в студенческих проектах, но часто не имели представления о том, как
эти методики проявят себя в полномасштабных средах разработки. В третьих книгах ав#
торы рекламировали новейшие методологии, игнорируя многие зрелые методики, эффек#
тивность которых прошла проверку временем.
Короче говоря, я не смог найти ни одной книги, автор которой
Когда вместе собираются крихотя бы попытался отразить в ней практические приемы програм#
тики, они говорят о Теме, Коммирования, возникшие благодаря накоплению профессионального
позиции и Идее. Когда вместе
опыта, отраслевым исследованиям и академическим изысканиям.
собираются художники, они гоОбсуждение конструирования нужно было привести в соответ#
ворят о том, где купить дешествие современным языкам программирования, объектно#ориен#
вый скипидар.
тированному программированию и ведущим методикам разработ#
ки. Ясно, что книгу о программировании должен был написать
Пабло Пикассо
человек, знакомый с последними достижениями в области теории
и в то же время создавший достаточно реального кода, чтобы хорошо представлять со#
стояние практической сферы. Я писал эту книгу как всестороннее обсуждение конструи#
рования кода, имеющее целью передачу знаний от одного программиста другому.

К читателям
Я буду рад получить от вас вопросы по темам, обсуждаемым в этой книге, сообщения об
обнаруженных ошибках, комментарии и предложения. Для связи со мной используйте адрес
stevemcc@construx.com или мой Web#сайт www.stevemcconnell.com.
Беллвью, штат Вашингтон
30 мая 2004 года

XVIII

Предисловие

Служба поддержки Microsoft Learning Technical Support
Мы приложили все усилия, чтобы обеспечить точность сведений, изложенных в этой книге.
Поправки к книгам издательства Microsoft Press публикуются в Интернете по адресу:
http://www.microsoft.com/learning/support/
Чтобы подключиться к базе знаний Microsoft и задать вопрос или запросить ту или иную
информацию, откройте страницу:
http://www.microsoft.com/learning/support/search.asp
Если у вас есть замечания, вопросы или предложения по поводу этой книги, присылайте
их в Microsoft Press по обычной почте:
Microsoft Press
Attn: Code Complete 2E Editor
One Microsoft Way
Redmond, WA 98052%6399
или по электронной почте:
mspinput@microsoft.com

Примечание издателя перевода
В книге приняты следующие условные графические обозначения:

Ключевой момент

Достоверные данные

Ужасный код

ГЛАВА 1 Добро пожаловатьв мир конструирования ПО!

XIX

Благодарности

Книги никогда не создаются в одиночку (по крайней мере это относится ко всем
моим книгам), а работа над вторым изданием — еще более коллективное пред#
приятие.
Мне хотелось бы поблагодарить всех, кто принял участие в обзоре данной книги:
это Хакон Агустссон (Hбkon Бgъstsson), Скотт Эмблер (Scott Ambler), Уилл Барнс
(Will Barns), Уильям Д. Бартоломью (William D. Bartholomew), Ларс Бергстром (Lars
Bergstrom), Ян Брокбанк (Ian Brockbank), Брюс Батлер (Bruce Butler), Джей Цин#
котта (Jay Cincotta), Алан Купер (Alan Cooper), Боб Коррик (Bob Corrick), Эл Кор#
вин (Al Corwin), Джерри Девилль (Jerry Deville), Джон Ивз (Jon Eaves), Эдвард Эс#
трада (Edward Estrada), Стив Гоулдстоун (Steve Gouldstone), Оуэйн Гриффитс (Owain
Griffiths), Мэтью Харрис (Matthew Harris), Майкл Ховард (Michael Howard), Энди
Хант (Andy Hunt), Кевин Хатчисон (Kevin Hutchison), Роб Джаспер (Rob Jasper),
Стивен Дженкинс (Stephen Jenkins), Ральф Джонсон (Ralph Johnson) и его группа
разработки архитектуры ПО из Иллинойского университета, Марек Конопка (Marek
Konopka), Джефф Лэнгр (Jeff Langr), Энди Лестер (Andy Lester), Митика Ману (Mitica
Manu), Стив Маттингли (Steve Mattingly), Гарет Маккоан (Gareth McCaughan), Ро#
берт Макговерн (Robert McGovern), Скотт Мейерс (Scott Meyers), Гарет Морган
(Gareth Morgan), Мэтт Пелокин (Matt Peloquin), Брайан Пфладж (Bryan Pflug),
Джеффри Рихтер (Jeffrey Richter), Стив Ринн (Steve Rinn), Даг Розенберг (Doug
Rosenberg), Брайан Сен#Пьер (Brian St. Pierre), Диомидис Спиннелис (Diomidis
Spinellis), Мэтт Стивенс (Matt Stephens), Дэйв Томас (Dave Thomas), Энди Томас#
Крамер (Andy Thomas#Cramer), Джон Влиссидес (John Vlissides), Павел Возенилек
(Pavel Vozenilek), Денни Уиллифорд (Denny Williford), Джек Вули (Jack Woolley) и
Ди Зомбор (Dee Zsombor).
Сотни читателей прислали комментарии к первому изданию этой книги, и еще
больше — ко второму. Спасибо всем, кто потратил время, чтобы поделиться в той
или иной форме своим мнением.
Хочу особо поблагодарить рецензентов из Construx Software, которые провели фор#
мальную инспекцию всей рукописи: это Джейсон Хиллз (Jason Hills), Брейди Хон#
сингер (Bradey Honsinger), Абдул Низар (Abdul Nizar), Том Рид (Tom Reed) и Па#
мела Перро (Pamela Perrott). Я был поистине удивлен тщательностью их обзора,
особенно если учесть, сколько глаз изучило эту книгу до того, как они начали
работать с ней. Спасибо также Брейди, Джейсону и Памеле за помощь в создании
Web#сайта cc2e.com.
Мне было очень приятно работать с Девон Масгрейв (Devon Musgrave) — редак#
тором этой книги. Я работал со многими прекрасными редакторами в других
проектах, но даже на их фоне Девон выделяется добросовестностью и легким

XX

Благодарности

характером. Спасибо, Девон! Благодарю Линду Энглман (Linda Engleman), кото#
рая поддержала идею второго издания — без нее эта книга не появилась бы. Бла#
годарю также других сотрудников издательства Microsoft Press, в их число входят
Робин ван Стинбург (Robin Van Steenburgh), Элден Нельсон (Elden Nelson), Карл
Дилтц (Carl Diltz), Джоэл Панчо (Joel Panchot), Патрисия Массерман (Patricia
Masserman), Билл Майерс (Bill Myers), Сэнди Резник (Sandi Resnick), Барбара Нор#
флит (Barbara Norfleet), Джеймс Крамер (James Kramer) и Прескотт Классен (Prescott
Klassen).
Я хочу еще раз сказать спасибо сотрудникам Microsoft Press, участвовавшим в
подготовке первого издания книги: это Элис Смит (Alice Smith), Арлен Майерс
(Arlene Myers), Барбара Раньян (Barbara Runyan), Кэрол Люк (Carol Luke), Конни
Литтл (Connie Little), Дин Холмс (Dean Holmes), Эрик Стру (Eric Stroo), Эрин О’Кон#
нор (Erin O’Connor), Джинни Макгиверн (Jeannie McGivern), Джефф Кэри (Jeff Carey),
Дженнифер Харрис (Jennifer Harris), Дженнифер Вик (Jennifer Vick), Джудит Блох
(Judith Bloch), Кэтрин Эриксон (Katherine Erickson), Ким Эгглстон (Kim Eggleston),
Лиза Сэндбург (Lisa Sandburg), Лиза Теобальд (Lisa Theobald), Маргарет Харгрейв
(Margarite Hargrave), Майк Халворсон (Mike Halvorson), Пэт Фоджетт (Pat Forgette),
Пегги Герман (Peggy Herman), Рут Петтис (Ruth Pettis), Салли Брунсмен (Sally
Brunsman), Шон Пек (Shawn Peck), Стив Мюррей (Steve Murray), Уоллис Болц (Wallis
Bolz) и Заафар Хаснаин (Zaafar Hasnain).
Наконец, я хотел бы выразить благодарность рецензентам, внесшим такой боль#
шой вклад в первое издание книги: это Эл Корвин (Al Corwin), Билл Кистлер (Bill
Kiestler), Брайан Догерти (Brian Daugherty), Дэйв Мур (Dave Moore), Грег Хичкок
(Greg Hitchcock), Хэнк Меуре (Hank Meuret), Джек Вули (Jack Woolley), Джой Уай#
рик (Joey Wyrick), Марго Пейдж (Margot Page), Майк Клейн (Mike Klein), Майк
Зевенберген (Mike Zevenbergen), Пэт Форман (Pat Forman), Питер Пэт (Peter Pathe),
Роберт Л. Гласс (Robert L. Glass), Тэмми Форман (Tammy Forman), Тони Пискулли
(Tony Pisculli) и Уэйн Бердсли (Wayne Beardsley). Особо благодарю Тони Гарланда
(Tony Garland) за его обстоятельный обзор: за 12 лет я еще лучше понял, как вы#
играла эта книга от тысяч комментариев Тони.

Библиография

XXI

Контрольные списки
Требования ................................................................................................................................................................................................................. 42
Архитектура ............................................................................................................................................................................................................ 54
Предварительные условия ....................................................................................................................................................................... 59
Основные методики конструирования ................................................................................................................................... 69
Проектирование при конструировании .............................................................................................................................. 122
Качество классов ............................................................................................................................................................................................ 157
Высококачественные методы ........................................................................................................................................................... 185
Защитное программирование ......................................................................................................................................................... 211
Процесс программирования с псевдокодом .................................................................................................................. 233
Общие вопросы использования данных ............................................................................................................................. 257
Именование переменных ..................................................................................................................................................................... 288
Основные данные .......................................................................................................................................................................................... 316
Применение необычных типов данных .............................................................................................................................. 343
Организация последовательного кода .................................................................................................................................. 353
Использование условных операторов ................................................................................................................................... 365
Циклы .......................................................................................................................................................................................................................... 388
Нестандартные управляющие структуры ........................................................................................................................... 410
Табличные методы ........................................................................................................................................................................................ 429
Вопросы по управляющим структурам ................................................................................................................................. 459
План контроля качества ......................................................................................................................................................................... 476
Эффективное парное программирование ........................................................................................................................ 484
Эффективные инспекции ..................................................................................................................................................................... 491
Тесты ............................................................................................................................................................................................................................. 532
Отладка ...................................................................................................................................................................................................................... 559
Разумные причины выполнения рефакторинга ......................................................................................................... 570
Виды рефакторинга ..................................................................................................................................................................................... 577
Безопасный рефакторинг ..................................................................................................................................................................... 584
Стратегии оптимизации кода .......................................................................................................................................................... 607
Методики оптимизации кода ........................................................................................................................................................... 642
Управление конфигурацией .............................................................................................................................................................. 669
Интеграция ............................................................................................................................................................................................................ 707
Инструменты программирования ............................................................................................................................................... 724
Форматирование ............................................................................................................................................................................................. 773
Самодокументирующийся код ........................................................................................................................................................ 780
Хорошие методики комментирования .................................................................................................................................. 816

Часть I

ОСНОВЫ РАЗРАБОТКИ ПО



Глава 1. Добро пожаловать в мир конструирования ПО!



Глава 2. Метафоры, позволяющие лучше понять
разработку ПО



Глава 3. Семь раз отмерь, один раз отрежь:
предварительные условия



Глава 4. Основные решения, которые приходится
принимать при конструировании

ЧАСТЬ I

2

Г Л А В А

Основы разработки ПО

1

Добро пожаловать в мир
конструирования ПО!

http://cc2e.com/0178

Содержание
 1.1. Что такое конструирование ПО?
 1.2. Почему конструирование ПО так важно?
 1.3. Как читать эту книгу

Связанные темы
 Кому следует прочитать эту книгу? (см. предисловие)
 Какую выгоду можно извлечь, прочитав эту книгу? (см. предисловие)
 Что побудило меня написать эту книгу? (см. предисловие)

Значение слова «конструирование» вне контекста разработки ПО известно всем: это
то, что делают строители при сооружении жилого дома, школы или небоскреба.
В детстве вы наверняка собирали разные предметы из «конструктора». Вообще под
«конструированием» понимают процесс создания какого#нибудь объекта. Этот про#
цесс может включать некоторые аспекты планирования, проектирования и тес#
тирования, но чаще всего «конструированием» называют практическую часть
создания чего#либо.

1.1.

Что такое конструирование ПО?

Разработка ПО — непростой процесс, который может включать множество ком#
понентов. Вот какие составляющие разработки ПО определили ученые за после#
дние 25 лет:
 определение проблемы;
 выработка требований;
 создание плана конструирования;
 разработка архитектуры ПО, или высокоуровневое проектирование;
 детальное проектирование;
 кодирование и отладка;

ГЛАВА 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.

Конструирование занимает центральное место в про'
цессе разработки ПО Требования к приложению и его
архитектура разрабатываются до этапа конструирования, чтобы гарантировать его
эффективность. Тестирование системы (в строгом смысле независимого тестиро#
вания) выполняется после конструирования и служит для проверки его правиль#
ности. Конструирование — центр процесса разработки ПО.

ЧАСТЬ I

6

Основы разработки ПО

Повышенное внимание к конструированию может
намного повысить производительность труда от'
дельных программистов В своем классическом иссле#
довании Сэкман, Эриксон и Грант показали, что произво#
дительность труда отдельных программистов во время кон#
струирования изменяется в 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). Эта книга поможет всем программистам изучить ме#
тоды, которые уже используются лучшими разработчиками.

Перекрестная ссылка О производительности труда программистов см. подраздел «Индивидуальные различия» раздела 28.5.

Результат конструирования — исходный код — часто является единствен'
ным верным описанием программы Зачастую единственным видом доступ#
ной программистам документации является сам исходный код. Спецификации тре#
бований и проектная документация могут устареть, но исходный код актуален
всегда, поэтому он должен быть максимально качественным. Последовательное при#
менение методов улучшения исходного кода — вот что отличает детальные, кор#
ректные и поэтому информативные программы от устройств Руба Голдберга1 . Эф#
фективнее всего применять эти методы на этапе конструирования.
Конструирование — единственный процесс, который выполняется
во всех случаях Идеальный программный проект до начала конструи#
рования проходит стадии тщательной выработки требований и проекти#
рования архитектуры. После конструирования в идеале должно быть выполнено ис#
черпывающее, статистически контролируемое тестирование системы. Однако в ре#
альных проектах нашего несовершенного мира разработчики часто пропускают
этапы выработки требований и проектирования, начиная прямо с конструирова#
ния программы. Тестирование также часто выпадает из расписания из#за огромно#
го числа ошибок и недостатка времени. Но каким бы срочным или плохо сплани#
рованным ни был проект, куда без конструирования деться? Так что повышение эф#
фективности конструирования ПО позволяет оптимизировать любой проект, ка#
ким бы несовершенным он ни был.

1.3.

Как читать эту книгу

Вы можете читать эту книгу от корки до корки или по отдельным темам. Если вы
предпочитаете первый вариант, переходите к главе 2. Если второй — можете на#
чать с главы 6 и переходить по перекрестным ссылкам к другим темам, которые
вас заинтересуют. Если вы не уверены, какой из этих вариантов вам подходит,
начните с раздела 3.2.

1

Голдберг, Рубен Лушес («Руб») [Goldberg, «Rube» (Reuben Lucius)] (1883–1970) — карика#
турист, скульптор. Известен своими карикатурами, в которых выдуманное им сложное обору#
дование («inventions») выполняет примитивные и никому не нужные операции. Лауреат Пулит#
церовской премии 1948 г. за политические карикатуры. — Прим. перев.

ГЛАВА 1 Добро пожаловать в мир конструирования ПО!

7

Ключевые моменты
 Конструирование — главный этап разработки ПО, без которого не обходится

ни один проект.
 Основные этапы конструирования: детальное проектирование, кодирование,

отладка, интеграция и тестирование приложения разработчиками (блочное
тестирование и интеграционное тестирование).
 Конструирование часто называют «кодированием» и «программированием».
 От качества конструирования во многом зависит качество ПО.
 В конечном счете ваша компетентность в конструировании ПО определяет то,

насколько хороший вы программист. Совершенствованию ваших навыков и
посвящена оставшаяся часть этой книги.

ЧАСТЬ I

8

Г Л А В А

Основы разработки ПО

2

Метафоры, позволяющие
лучше понять разработку ПО

http://cc2e.com/0278

Содержание
 2.1. Важность метафор
 2.2. Как использовать метафоры?
 2.3. Популярные метафоры, характеризующие разработку ПО

Связанная тема
 Эвристика при проектировании: подраздел «Проектирование — эвристический

процесс» в разделе 5.1
Терминология компьютерных наук — одна из самых красочных. Действительно,
в какой еще области существуют стерильные комнаты с тщательно контролируе#
мой температурой, заполненные вирусами, троянскими конями, червями, жучка#
ми и прочей живностью и нечистью?
Все эти яркие метафоры описывают специфические аспекты мира программиро#
вания. Более общие явления характеризуются столь же красочными метафорами,
позволяющих лучше понять процесс разработки ПО.
Остальная часть книги не зависит от обсуждения метафор в этой главе. Можете
пропустить ее, если хотите быстрее добраться до практических советов. Если хотите
яснее представлять разработку ПО, читайте дальше.

2.1.

Важность метафор

Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем
понятное явление с чем#то похожим, но более понятным, вы можете догадаться,
как справиться с проблемой. Такое использование метафор называется «модели#
рованием».
История науки полна открытий, сделанных благодаря метафорам. Так, химик Ке#
куле однажды во сне увидел змею, схватившую себя за хвост. Проснувшись, он
понял, что свойства бензола объяснила бы молекулярная структура, имеющая
похожую кольцевую форму. Дальнейшие эксперименты подтвердили его гипоте#
зу (Barbour, 1966).

ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО

9

Кинетическая теория газов была создана на основе модели «бильярдных шаров»,
согласно которой молекулы газа, подобно бильярдным шарам, имеют массу и
совершают упругие соударения.
Волновая теория света была разработана преимущественно путем исследования
сходств между светом и звуком. И свет, и звук имеют амплитуду (яркость — гром#
кость), частоту (цвет — высота) и другие общие свойства. Сравнение волновых
теорий звука и света оказалось столь продуктивным, что ученые потратили мно#
го сил, пытаясь обнаружить среду, которая распространяла бы свет, как воздух
распространяет звук. Они даже дали этой среде название — «эфир», но так и не
смогли ее обнаружить. В данном случае аналогия была такой убедительной, что
ввела ученых в заблуждение.
В целом эффективность моделей объясняется их яркостью и концептуальной
целостностью. Модели подсказывают ученым свойства, отношения и перспективные
области исследований. Иногда модели вводят в заблуждение; как правило, к это#
му приводит чрезмерное обобщение метафоры. Поиск эфира — наглядный при#
мер чрезмерного обобщения модели.
Разумеется, некоторые метафоры лучше других. Хорошими метафорами можно
считать те, что отличаются простотой, согласуются с другими релевантными мета#
форами и объясняют многие экспериментальные данные и наблюдаемые явления.
Рассмотрим, к примеру, колебания камня, подвешенного на веревке. До Галилея
сторонники Аристотеля считали, что тяжелый объект перемещается из верхней
точки в нижнюю, переходя в состояние покоя. В данном случае они подумали бы,
что камень падает, но с осложнениями. Когда Галилей смотрел на раскачивающийся
камень, он видел маятник, поскольку камень снова и снова повторял одно и то
же движение.
Указанные модели фокусируют внимание на совершенно разных факторах. Пос#
ледователи Аристотеля, рассматривавшие раскачивающийся камень как падающий
объект, принимали в расчет вес камня, высоту, на которую он был поднят, и время,
проходящее до достижения камнем состояния покоя. В модели Галилея важными
были другие факторы. Он обращал внимание на вес камня, угловое смещение, ра#
диус и период колебаний маятника. Благодаря этому Галилей открыл законы, кото#
рые последователи Аристотеля открыть не смогли, так как их модель заставила их
наблюдать за другими явлениями и задавать другие вопросы.
Аналогичным образом метафоры способствуют и лучшему пониманию вопросов
разработки ПО. Во время лекции по случаю получения премии Тьюринга в 1973 г.,
Чарльз Бахман (Charles Bachman) упомянул переход от доминировавшего геоцен#
трического представления о Вселенной к гелиоцентрическому. Геоцентрическая
модель Птолемея не вызывала почти никаких сомнений целых 1400 лет. Затем, в
1543 г., Коперник выдвинул гелиоцентрическую теорию, предположив, что цент#
ром Вселенной на самом деле является Солнце, а не Земля. В конечном итоге та#
кое изменение умозрительных моделей привело к открытию новых планет, ис#
ключению Луны из категории планет и переосмыслению места человечества во
Вселенной.

10

ЧАСТЬ I

Основы разработки ПО

Не стоит недооценивать важность метафор. Метафоры имеют одно неоспоримое достоинство: описываемое ими поведение предсказуемо и понятно
всем людям. Это сокращает
объем ненужной коммуникации,
способствует достижению взаимопонимания и ускоряет обучение. По сути метафора — это
способ осмысления и абстрагирования концепций, позволяющий думать в более высокой
плоскости и избегать низкоуровневых ошибок.

Переход от геоцентрического представления к гелиоцент#
рическому в астрономии Бахман сравнил с изменением,
происходившим в программировании в начале 1970#х. В это
время центральное место в моделях обработки данных стали
отводить не компьютерам, а базам данных. Бахман указал,
что создатели ранних моделей стремились рассматривать
все данные как последовательный поток карт, «протекаю#
щий» через компьютер (компьютеро#ориентированный
подход). Суть изменения заключалась в отведении централь#
ного места пулу данных, над которыми компьютер выпол#
няет некоторые действия (подход, ориентированный на БД).

Сегодня почти невозможно найти человека, считающего, что
Солнце вращается вокруг Земли. Столь же трудно предста#
Фернандо Дж. Корбати
вить программиста, который бы думал, что все данные мож#
(Fernando J. Corbatу)
но рассматривать как последовательный поток карт. После
опровержения старых теорий трудно понять, как кто#то
когда#то мог в них верить. Еще удивительнее то, что приверженцам этих старых
теорий новые теории казались такими же нелепыми, как нам старые.
Геоцентрическое представление о Вселенной мешало астрономам, которые сохра#
нили верность этой теории после появления лучшей. Аналогично компьютеро#
ориентированное представление о компьютерной вселенной тянуло назад ком#
пьютерных ученых, которые продолжили придерживаться его после появления
теории, ориентированной на БД.
Иногда люди упрощают суть метафор. На каждый из описанных примеров так и
тянет ответить: «Разумеется, правильная метафора более полезна. Другая метафора
была неверной!» Так#то оно так, но это слишком упрощенное представление. Ис#
тория науки — не серия переходов от «неверных» метафор к «верным». Это серия
переходов от «менее хороших» метафор к «лучшим», от менее полных теорий к более
полным, от адекватного описания одной области к адекватному описанию другой.
В действительности многие модели, на смену которым приходят лучшие модели,
сохраняют свою полезность. Так, инженеры до сих пор решают большинство своих
задач, опираясь на ньютонову динамику, хотя в теоретической физике ее вытес#
нила теория Эйнштейна.
Разработка ПО — относительно молодая область науки. Она еще недостаточно
зрелая, чтобы иметь набор стандартных метафор. Поэтому она включает массу
второстепенных и противоречивых метафор. Одни из них лучше другие — хуже.
Оттого, насколько хорошо вы понимаете метафоры, зависит и ваше понимание
разработки ПО.

2.2.

Как использовать метафоры?

Метафора, характеризующая разработку ПО, больше похожа на про#
жектор, чем на дорожную карту. Она не говорит, где найти ответ —
она говорит, как его искать. Метафора — это скорее эвристический
подход, а не алгоритм.

ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО

11

Алгоритмом называют последовательность четко определенных команд, которые
необходимо выполнить для решения конкретной задачи. Алгоритм предсказуем,
детерминирован и не допускает случайностей. Алгоритм говорит, как пройти из
точки А в точку Б не дав крюку, без посещения точек В, Г и Д и без остановок на
чашечку кофе.
Эвристика — это метод, помогающий искать ответ. Результаты его применения
могут быть в некоторой степени случайными, потому что эвристика указывает
только способ поиска, но не говорит, что искать. Она не говорит, как дойти пря#
мо из точки А в точку Б; даже положение этих точек может быть неизвестно. Эв#
ристика — это алгоритм в шутовском наряде. Она менее предсказуема, более за#
бавна и поставляется без 30#дневной гарантии с возможностью возврата денег.
Вот алгоритм, позволяющий добраться до чьего#то дома: поезжайте по шоссе 167
на юг до городка Пюиолап. Сверните на аллею Сауз#Хилл, а дальше 4,5 мили вверх
по холму. Поверните у продуктового магазина направо, а на следующем перекре#
стке — налево. Доехав до дома 714, расположенного на левой стороне улицы,
остановитесь и выходите из автомобиля.
А эвристическое правило может быть таким: найдите наше
последнее письмо. Езжайте в город, указанный на конвер#
те. Оказавшись в этом городе, спросите кого#нибудь, где
находится наш дом. Все нас знают — кто#нибудь с радос#
тью вам поможет. Если никого не встретите, позвоните нам
из телефона#автомата, и мы за вами приедем.

Перекрестная ссылка Об использовании эвристики при
проектировании ПО см. подраздел «Проектирование — эвристический процесс» раздела 5.1.

Различия между алгоритмом и эвристикой тонки, и в чем#то эти два понятия пе#
рекрываются. В этой книге основным различием между ними я буду считать сте#
пень косвенности решения. Алгоритм предоставляет вам сами команды. Эвристика
сообщает вам, как обнаружить команды самостоятельно или по крайней мере где
их искать.
Наличие директив, точно определяющих способ решения проблем программи#
рования, непременно сделало бы программирование более легким, а результаты
более предсказуемыми. Но наука программирования еще не продвинулась так
далеко, а может, этого никогда и не случится. Самая сложная часть программиро#
вания — концептуализация проблемы, и многие ошибки программирования яв#
ляются концептуальными. С концептуальной точки зрения каждая программа
уникальна, поэтому трудно или даже невозможно разработать общий набор ди#
ректив, приводящих к решению во всех случаях. Так что знание общего подхода
к проблемам не менее, а то и более ценно, чем знание точных решений конкрет#
ных проблем.
Как использовать метафоры, характеризующие разработку ПО? Используйте так,
чтобы лучше разобраться в проблемах и процессах программирования, чтобы они
помогали вам размышлять о выполняемых действиях и придумывать лучшие ре#
шения задач. Конечно, вы не сможете взглянуть на строку кода и сказать, что она
противоречит одной из метафор, описываемых в этой главе. Но со временем тот,
кто использует метафоры, лучше поймет программирование и будет быстрее со#
здавать более эффективный код, чем тот, кто их не использует.

12

ЧАСТЬ I

2.3.

Популярные метафоры,
характеризующие разработку ПО

Основы разработки ПО

Множество метафор, описывающих разработку ПО, смутит кого угодно. Дэвид Грайс
утверждает, что написание ПО — это наука (Gries, 1981). Дональд Кнут считает это
искусством (Knuth, 1998). Уоттс Хамфри говорит, что это процесс (Humphrey, 1989).
Ф. Дж. Плоджер и Кент Бек утверждают, что разработка ПО похожа на управле#
ние автомобилем, однако приходят к почти противоположным выводам (Plauger,
1993, Beck, 2000). Алистер Кокберн сравнивает разработку ПО с игрой (Cockburn,
2002), Эрик Реймонд — с базаром (Raymond, 2000), Энди Хант (Andy Hunt) и Дэйв
Томас (Dave Thomas) — с работой садовника, Пол Хекель — со съемкой фильма
«Белоснежка и семь гномов» (Heckel, 1994). Фред Брукс упоминает фермерство,
охоту на оборотней и динозавров, завязших в смоляной яме (Brooks, 1995). Ка#
кие метафоры самые лучшие?

Литературная метафора: написание кода
Самая примитивная метафора, описывающая разработку ПО, берет начало в вы#
ражении «написание кода». Согласно литературной метафоре разработка програм#
мы похожа на написание письма: вы садитесь за стол, берете бумагу, перо и пи#
шете письмо с начала до конца. Это не требует никакого формального планиро#
вания, а мысли, выражаемые в письме, формулируются автором по ходу дела.
На этой метафоре основаны и многие другие идеи. Джон Бентли (Jon Bentley)
говорит, что программист должен быть способен сесть у камина со стаканом брен#
ди, хорошей сигарой, охотничьей собакой у ног и «сформулировать программу»
подобно тому, как писатели создают романы. Брайан Керниган и Ф. Дж. Плоджер
назвали свою книгу о стиле программирования «The Elements of Programming Style»
(Kernighan and Plauger, 1978), обыгрывая название книги о литературном стиле
«The Elements of Style» (Strunk and White, 2000). Программисты часто говорят об
«удобочитаемости программы».
Индивидуальную работу над небольшими проектами метафора написа#
ния письма характеризует довольно точно, но в целом она описывает
разработку ПО неполно и неадекватно. Письма и романы обычно принад#
лежат перу одного человека, тогда как над программами обычно работают группы
людей с разными сферами ответственности. Закончив писать письмо, вы запечаты#
ваете его в конверт и отправляете. С этого момента изменить вы его не можете, и
письмо во всех отношениях является завершенным. Изменить ПО не так уж трудно,
и вряд ли работу над ним можно когда#нибудь признать законченной. Из общего
объема работы над типичной программной системой две трети обычно выполня#
ются после выпуска первой версии программы, а иногда эта цифра достигает целых
90 % (Pigoski, 1997). В литературе поощряется оригинальность. При конструирова#
нии ПО оригинальный подход часто оказывается менее эффективным, чем повтор#
ное использование идей, кода и тестов из предыдущих проектов. Словом, процесс
разработки ПО, соответствующий литературной метафоре, является слишком про#
стым и жестким, чтобы быть полезным.

ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО

13

К сожалению, литературная метафора была увековечена в одной из самых попу#
лярных книг по разработке ПО — книге Фреда Брукса «The Mythical Man#Month»
(«Мифический человеко#месяц») (Brooks, 1995). Брукс пишет: «Планируйте вы#
бросить первый экземпляр программы: вам в любом случае придется это сделать».
Перед глазами невольно возникает образ мусорного ведра, полного черновиков
(рис. 2#1).

Рис. 2'1. Литературная метафора наводит на мысль, что процесс
разработки ПО основан на дорогостоящем методе проб и ошибок,
а не на тщательном планировании и проектировании

Подобный подход может быть практичным, если вы пише#
Планируйте выбросить первый
те банальное письмо своей тетушке. Однако расширение
экземпляр программы: вам в люметафоры «написания» ПО вплоть до выбрасывания первого
бом случае придется это сделать.
экземпляра программы — не лучший совет в мире разработ#
Фред Брукc
ки ПО, где крупная система по стоимости уже сравнялась с
10#этажным офисным зданием или океанским лайнером.
Если вы планируете выбросить
Конечно, это не имело бы значения, если б вы имели бес#
первый экземпляр программы,
вы выбросите и второй.
конечные запасы времени и средств. Однако реальные ус#
Крейг Зеруни (Craig Zerouni)
ловия таковы, что разработчики должны создавать програм#
мы с первого раза или хотя бы минимизировать объем до#
полнительных расходов в случае неудач. Другие метафоры лучше иллюстрируют
достижение таких целей.

Сельскохозяйственная метафора: выращивание системы
Некоторые разработчики заявляют, что создание ПО следует рассматривать по
аналогии с выращиванием сельскохозяйственных культур. Вы проектируете от#
дельный блок, кодируете его, тестируете и добавляете в систему, чуть расширяя с
каждым разом ее функциональность. Такое разбиение задачи на множество не#
больших действий позволяет минимизировать проблемы, с которыми можно стол#
кнуться на каждом этапе.
Иногда хороший метод описывается плохой метафорой. В таких случа#
ях попытайтесь сохранить метод и обнаружить лучшую метафору. В дан#
ном случае инкрементный подход полезен, но сельскохозяйственная
метафора просто ужасна.

14

ЧАСТЬ I

Основы разработки ПО

Возможно, идея выполнения небольшого объема работы
зараз и напоминает рост растений, но сельскохозяйствен#
ная аналогия неубедительна и неинформативна, к тому же
ее легко заменить лучшими метафорами, которые описаны
ниже. Сельскохозяйственную метафору трудно расширить
за пределы идеи выполнения чего#либо небольшими час#
тями. Ее приверженцы (рис. 2#2) рискуют в итоге заговорить
об удобрении плана системы, прореживании детального
проекта, повышении урожайности кода путем оптимизации землеустройства и
уборке урожая самого кода. Вы начнете говорить о чередовании посевов C++ и о
том, что было бы неплохо оставить систему под паром для повышения концент#
рации азота на жестком диске.

Дополнительные сведения О другой сельскохозяйственной метафоре, употребляемой в контексте сопровождения ПО, см. главу «On the Origins of Designer
Intuition» книги «Rethinking Systems Analysis and Design» (Weinberg, 1988).

Слабость данной метафоры заключается в предположении, что у вас нет прямого
контроля над развитием ПО. Вы просто сеете семена кода весной и, если на то
будет воля Великой Тыквы, осенью получите невиданный урожай кода.

Рис. 2'2. Нелегко адекватно расширить сельскохозяйственную метафору
на область разработки ПО

Метафора жемчужины: медленное приращение системы
Иногда, говоря о выращивании ПО, на самом деле имеют в виду приращение, или
аккрецию (accretion). Две этих метафоры тесно связаны, но вторая более убеди#
тельна. Приращение характеризует процесс формирования жемчужины за счет
отложения небольших объемов карбоната кальция. В геологии и юриспруденции
под аккрецией понимают увеличение территории суши посредством отложения
содержащихся в воде пород.
Это не значит, что вы должны освоить создание кода из оса#
дочных пород; это означает, что вы должны научиться добав#
лять в программные системы по небольшому фрагменту за
раз. Другими словами, которые в связи с этим приходят на
ум, являются термины «инкрементный», «итеративный», «адап#
тивный» и «эволюционный». Инкрементное проектирование, конструирование и
тестирование — одни из самых эффективных концепций разработки ПО.

Перекрестная ссылка О применении инкрементных стратегий
при интеграции системы см.
раздел 29.2.

При инкрементной разработке вы сначала создаете самую простую версию систе#
мы, которую можно было бы запустить. Она может не принимать реальных дан#
ных, может не выполнять над ними реальных действий, может не генерировать
реальные результаты — она должна быть просто скелетом, достаточно крепким,

ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО

15

чтобы поддерживать реальную систему по мере ее разработки. Она может вызы#
вать поддельные классы для каждой из определенных вами основных функций. Такая
система похожа на песчинку, с которой начинается образование жемчужины.
Создав скелет, вы начинаете понемногу наращивать плоть. Каждый из фиктивных
классов вы заменяете реальным. Вместо того чтобы имитировать ввод данных, вы
пишете код, на самом деле принимающий реальные данные. А вместо имитации
вывода данных — код, на самом деле выводящий данные. Вы продолжаете добав#
лять нужные фрагменты, пока не получаете полностью рабочую систему.
Эффективность такого подхода можно подтвердить двумя впечатляющими при#
мерами. Фред Брукс, который в 1975 г. предлагал выбрасывать первый экземпляр
программы, заявил, что за десять лет, прошедших с момента написания им зна#
менитой книги «Мифический человеко#месяц», ничто не изменяло его работу и
ее эффективность так радикально, как инкрементная разработка (Brooks, 1995).
Аналогичное заявление было сделано Томом Гилбом в революционной книге
«Principles of Software Engineering Management» (Gilb, 1988), в которой он пред#
ставил метод эволюционной поставки программы (evolutionary delivery) и разрабо#
тал многие основы современного гибкого программирования (agile programming).
Многие другие современные методологии также основаны на идее инкрементной
разработки (Beck, 2000; Cockburn, 2002; Highsmith, 2002; Reifer, 2002; Martin, 2003;
Larman, 2004).
Достоинство инкрементной метафоры в том, что она не дает чрезмерных обеща#
ний. Кроме того, она не так легко поддается неуместному расширению, как сель#
скохозяйственная метафора. Раковина, формирующая жемчужину, — хороший
вариант визуализации инкрементной разработки, или аккреции.

Строительная метафора: построение ПО
Метафора «построения» ПО полезнее, чем метафоры «написания» или «вы#
ращивания» ПО, так как согласуется с идеей аккреции ПО и предостав#
ляет более детальное руководство. Построение ПО подразумевает нали#
чие стадий планирования, подготовки и выполнения, тип и степень выраженно#
сти которых зависят от конкретного проекта. При изучении этой метафоры вы
найдете и другие параллели.
Для построения метровой башни требуется твердая рука, ровная поверхность и
10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в
100 раз больше пивных банок. Такой проект требует совершенно иного плани#
рования и конструирования.
Если вы строите простой объект, скажем, собачью конуру, вы можете пойти в
хозяйственный магазин, купить доски, гвозди, и к вечеру у Фидо будет новый дом.
Если вы забудете про лаз или допустите какую#нибудь другую ошибку, ничего
страшного: вы можете ее исправить или даже начать все сначала (рис. 2#3). Все,
что вы при этом потеряете, — время. Такой свободный подход уместен и в неболь#
ших программных проектах. Если вы плохо спроектируете 1000 строк кода, то
сможете выполнить рефакторинг или даже начать проект заново, и это не приве#
дет к крупным потерям.

16

ЧАСТЬ I

Основы разработки ПО

Рис. 2'3. За ошибку, допущенную при создании простого объекта,
приходится расплачиваться лишь потраченным временем и, возможно,
некоторым разочарованием

Построить дом сложнее, и плохое проектирование при этом приводит к куда более
серьезным последствиям. Сначала вы должны решить, какой тип здания вы хоти#
те построить, что аналогично определению проблемы при разработке ПО. Затем
вы с архитектором должны разработать и утвердить общий план, что похоже на
разработку архитектуры. Далее вы чертите подробные чертежи и нанимаете бри#
гаду строителей — это аналогично детальному проектированию ПО. Вы готовите
стройплощадку, закладываете фундамент, создаете каркас дома, обшиваете его,
кроете крышу и проводите в дом все коммуникации — это похоже на конструи#
рование ПО. Когда строительство почти завершено, в дело вступают ландшафт#
ные дизайнеры, маляры и декораторы, делающие дом максимально удобным и
привлекательным. Это напоминает оптимизацию ПО. Наконец, на протяжении
всего строительства вас посещают инспекторы, проверяющие стройплощадку, фун#
дамент, электропроводку и все, что можно проверить. При разработке ПО этому
соответствуют обзоры и инспекция проекта.
И в строительстве, и в программировании увеличение сложности и масштаба
проекта сопровождается ростом цены ошибок. Конечно, для создания дома нуж#
ны довольно дорогие материалы, однако главной статьей расходов является
оплата труда рабочих. Перемещение стены на 15 см обойдется дорого не потому,
что при этом будет потрачено много гвоздей, а потому, что вам придется опла#
тить дополнительное время работы строителей. Чтобы не тратить время на ис#
правление ошибок, которых можно избежать, вы должны как можно лучше вы#
полнить проектирование (рис. 2#4). Материалы, необходимые для создания про#
граммного продукта, стоят дешевле, чем стройматериалы, однако затраты на ра#
бочую силу в обоих случаях примерно одинаковы. Изменение формата отчета
обходится ничуть не дешевле, чем перемещение стены дома, потому что главным
компонентом затрат в обоих случаях является время людей.

ГЛАВА 2 Метафоры, позволяющие лучше понять разработку ПО

Рис. 2'4.

17

Более сложные объекты требуют более тщательного планирования

Какие еще параллели можно провести между сооружением дома и разработкой
ПО? При возведении дома никто не пытается конструировать вещи, которые можно
купить. Здравомыслящему человеку и в голову не придет самостоятельно разра#
батывать и создавать стиральную машину, холодильник, шкафы, окна и двери, если
все это можно приобрести. Создавая программную систему, вы поступите так же.
Вы будете в полной мере использовать возможности высокоуровневого языка
вместо того, чтобы писать собственный код на уровне ОС. Возможно, вы исполь#
зуете также встроенные библиотеки классов#контейнеров, научные функции, клас#
сы пользовательского интерфейса и классы для работы с БД. Обычно невыгодно
писать компоненты, которые можно купить готовыми.
Однако если вы хотите построить нестандартный дом с первоклассной меблиров#
кой, мебель, возможно, придется заказать. Вы можете заказать встроенные посу#
домоечную машину и холодильник, чтобы они выглядели как часть обстановки.
Вы можете заказать окна необычных форм и размеров. Такое изготовление пред#
метов на заказ имеет параллели и в мире разработки ПО. При работе над прило#
жением высшего класса для достижения более высокой скорости и точности рас#
четов или реализации необычного интерфейса иногда приходится создавать соб#
ственные научные функции, собственные классы#контейнеры и другие компоненты.
И конструирование дома, и конструирование ПО можно оптимизировать, выполнив
адекватное планирование. Если создавать ПО в неверном порядке, его будет трудно
писать, тестировать и отлаживать. Сроки затянутся, да и весь проект может завер#
шиться неудачей из#за чрезмерной сложности отдельных компонентов, не позво#
ляющей разработчикам понять работу всей системы.
Тщательное планирование не значит исчерпывающее и