Новые технологии в программировании

Министерство образования и науки Российской Федерации

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР)

А. А. Калентьев, Д. В. Гарайс, А. Е. Горяинов

НОВЫЕ ТЕХНОЛОГИИ
В ПРОГРАММИРОВАНИИ

Учебное пособие

Томск

«Эль Контент»
2014

УДК
004.413.002(075.8)
ББК
32.973.2-018я73
К 171

Рецензенты:
Хабибулина Н. Ю., канд. техн. наук, доцент кафедры компьютерных систем
в управлении и проектировании ТУСУРа;
Самуилов А. А., генеральный директор компании по разработке мобильных
приложений ООО «Арвью».

Калентьев А. А.
К 171
Новые технологии в программировании : учебное пособие / А. А. Калентьев, Д. В. Гарайс, А. Е. Горяинов — Томск : Эль Контент, 2014. — 176 с.

ISBN 978-5-4332-0185-9

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

УДК
004.413.002(075.8)
ББК
32.973.2-018я73

ISBN 978-5-4332-0185-9
©
Калентьев А. А.,
Гарайс Д. В.,
Горяинов А. Е., 2014
©
Оформление.
ООО «Эль Контент», 2014

ОГЛАВЛЕНИЕ

Введение
5

1
Процесс создания программного обеспечения
9
1.1
Метафоры при создании ПО . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2
Этапы разработки ПО . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16

2
Техническое задание
25
2.1
Составление технического задания . . . . . . . . . . . . . . . . . . . . .
27

3
Командные роли
34
3.1
Командные роли по Белбину . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2
Функциональные роли . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37

4
Методологии разработки ПО
40
4.1
Что такое методология разработки ПО и зачем она нужна? . . . . . .
40
4.2
Используемые методологии ПО . . . . . . . . . . . . . . . . . . . . . . .
42
4.2.1
Водопадная методология . . . . . . . . . . . . . . . . . . . . . . .
43
4.2.2
Гибкие методологии . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.3
Другие методологии . . . . . . . . . . . . . . . . . . . . . . . . . .
57

5
Пользовательские интерфейсы
60
5.1
Правила верстки пользовательского интерфейса . . . . . . . . . . . . .
61
5.2
Шаблоны пользовательского поведения . . . . . . . . . . . . . . . . . .
66
5.3
Прототипирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70

6
Документация
74
6.1
Описание IDEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.1.1
IDEF0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.1.2
IDEF3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6.2
Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . .
80
6.2.1
Диаграмма деятельности . . . . . . . . . . . . . . . . . . . . . . .
82
6.2.2
Диаграмма вариантов использования . . . . . . . . . . . . . . .
84
6.2.3
Диаграмма классов
. . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.2.4
Диаграмма пакетов
. . . . . . . . . . . . . . . . . . . . . . . . . .
92
6.3
Блок-схемы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94

7
Техники написания и поддержки кода
102
7.1
Паттерны проектирования . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.1.1
Порождающие паттерны . . . . . . . . . . . . . . . . . . . . . . . 104
7.1.2
Структурные паттерны . . . . . . . . . . . . . . . . . . . . . . . . 117

Оглавление

7.2
Антипаттерны . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.3
Оформление кода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.4
Рецензирование кода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.5
Рефакторинг . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.6
Оптимизация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8
Тестирование
146
8.1
Что такое тестирование? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8.2
Тестовые случаи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.3
Классификация тестов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
8.4
Блочное тестирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

9
Информационное обеспечение процесса разработки
156
9.1
Система управления проектами . . . . . . . . . . . . . . . . . . . . . . . 156
9.2
Системы контроля версий . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
9.3
Непрерывная интеграция . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Заключение
165

Литература
166

Список условных обозначений и сокращений
170

Глоссарий
171

ВВЕДЕНИЕ

Учебное пособие по курсу «Новые технологии в программировании» предназначено для студентов программистских специальностей и направлений подготовки. Следует сказать, что представленный в пособии материал будет полезен
больше новичкам в программировании, чем специалистам с большим опытом, однако из-за большого охвата материала некоторые главы всё-таки смогут удивить
и искушённого читателя.
Учебное пособие не является истиной в последней инстанции, т. к. нельзя в одну небольшую книгу уложить подробное изложение материала, необходимое для
студента-программиста. Вполне возможно, что на момент прочтения пособия уже
появятся новые методы, методики и технологии в программировании, по сравнению с которыми представленный материал покажется некорректным. Авторы
вполне допускают подобное развитие событий, и их наступление является даже наиболее вероятным. Это обусловлено стремительным развитием IT-индустрии
и выражено как в новых технологиях программирования (распределённые вычисления, кластерные вычисления), так и в новых платформах для разработки (появление мобильных устройств, таких как планшеты, смартфоны и пр.; переход
инфраструктуры предприятий в облачные сервисы).
Для успешного освоения материала читатель должен обладать знаниями в области объектно-ориентированного программирования и проектирования систем,
уметь пользоваться одним из объектно-ориентированных языков, оптимальным
было бы знание С-подобных языков: С++, С#, Java и пр. В рамках курса НТвП
для описания примеров будет использоваться язык C#.
Изучать пособие можно несколькими способами. Для новичков в программировании рекомендуется ознакомиться со всеми главами в представленном порядке,
т. к. рассматриваются все стадии разработки ПО и инструментарий, для этого необходимый. В случае большего интереса к практическим аспектам написания кода,
а не к организации инфраструктуры разработки, рекомендуется начинать с главы 7,
а потом уже в интересующем порядке ознакомиться с другими главами.
Вкратце, о чём же это учебное пособие?
В главе 1 рассмотрены этапы создания программного обеспечения, приведены примеры, облегчающие восприятие разработки ПО. Обязательная глава для
начинающих разработчиков, т. к. не все до конца понимают, что из себя представляет процесс создания ПО, иногда его даже романтизируют. Никакой романтики,

Введение

часто всё прагматично и жёстко, особенно при работе с заказчиком. Однако при
жёсткости сроков и ресурсов, сам процесс разработки (кодирование, тестирование,
отладка) являет очень творческим и интересным, что должно убедить читателя
в правильности выбора профессии.
Глава 2 рассказывает о необходимости составления технического задания к проекту. В ней также приведены основные пункты, которые должны содержать техническое задание к программе. Данная глава будет полезна для понимания важности
составления технического задания, потому что при его низком качестве или полном отсутствии ТЗ (вы будете думать, что это техническое задание) может легко
превратиться в Точку Зрения заказчика.
В главе 3 описаны основные командные роли в проекте, т. е. кто и за что отвечает в процессе разработки. Так как даже средние проекты не делаются в одиночку,
читателю будет полезно знать об основных командных ролях. В контексте тех или
иных методологий разработки роли будут представлены в главе 4.
Методологии разработки, т. е. учения о методах, методиках, способах и средствах разработки ПО, приведены в главе 4. Изучение этой главы позволит читателю
сложить мнение об особенностях используемых сегодня методологий разработки
ПО. Помимо этого, в главе приводятся преимущества и недостатки тех или иных
методологий, что позволит читателю при работе в реальном проекте предлагать
их для повышения эффективности разработки или быстро встраиваться в процесс
разработки, обладая знаниями о существующих методологиях.
Глава 5 описывает основные этапы разработки пользовательского интерфейса
программы, что является одним из важнейших этапов, т. к. интерфейс, при его
наличии, это то, что увидит пользователь, и на основе чего, скорее всего, он будет
делать вывод о вашей программе. Эта глава поможет читателю формально подойти
к разработке пользовательских интерфейсов, получив инструментарий и чёткие
рекомендации, что нужно и что не нужно делать.
В главе 6 приводится описание нотаций для документации ПО: IDEF, UML,
ЕСПД (ГОСТ 19.XXX-XX). Представлены основные аспекты разработки, которые
могут быть задокументированы с помощью той или иной нотации. Для читателя
данная глава может послужить хорошим стартом в изучении имеющихся способов
документации разработки ПО, из-за сокращённого, по сравнению с первоисточниками, объёма излагаемого материала.
Глава 7 является наиболее объёмной во всём учебном пособии и имеет наибольшую практическую ценность для разработчика. В главе подробно с примерами
разобраны основные паттерны проектирования ПО (строительные блоки средних
и больших программных продуктов). Примеры программного кода приведены на
языке C#. Помимо паттернов, т. е. как надо делать, приведены и антипаттерны, т. е.
негативные практики разработки, что может значительно повысить качество кода
читателя, при избегании последним подобных практик. Также в главе описывается
важность оформления кода, чем обычно страдают новички в программировании.
Также приводятся несколько мощных практик поддержки и модификации кода:
рецензирование кода, рефакторинг кода, оптимизация кода.
В главе 8 приводятся классификация и описание различных видов тестирования программ. Изучение тестирования позволит читателю в значительной степени
улучшить качество программы, автоматизировав тестирование продукта и тем са

Соглашения, принятые в книге
7

мым выйдя на уровень управления качеством ПО. Достижение подобного уровня
позволит формально контролировать наличие и появление ошибок в разрабатываемом программном продукте, не к этому ли мы все стремимся?
Глава 9 описывает информационное обеспечение процесса разработки. Программирование в блокноте, перенос программного кода к коллеге на флеш-носителе и ручная сборка установочного файла, это, конечно, хорошо, но уже создано
большое количество инструментов и определено большое количество позитивных
практик, позволяющих в значительной степени избавиться от рутины, переложив
её на компьютер, оставив разработчику, только творчество в виде написания кода.
О подобных инструментах и подходах и рассказывает эта глава.
При написании этого пособия авторы надеялись создать простой и ёмкий ресурс, воспользовавшись которым, можно быстро влиться в сложный и интересный
мир разработки ПО. Надеемся, что это у нас получилось!

Соглашения, принятые в книге

Для улучшения восприятия материала в данной книге используются пиктограммы и специальное выделение важной информации.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Этот блок означает определение или новое понятие.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Этот блок означает внимание. Здесь выделена важная информация, требующая акцента на ней. Автор здесь может поделиться
с читателем опытом, чтобы помочь избежать некоторых ошибок.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Эта пиктограмма означает цитату.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
В блоке «На заметку» автор может указать дополнительные сведения или другой взгляд на изучаемый предмет, чтобы помочь читателю лучше понять основные идеи.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . .. . . . . . . . . . . . . . . . . . . . . .
Пример
. . .. . . . . . . . . . . . . . . . . . . . . .

Эта пиктограмма означает пример. В данном блоке автор может привести практический пример для пояснения и разбора основных моментов, отраженных в теоретическом материале.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Введение

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

. . .. . . . . . . . . . . . . . . . . . . . . .
Выводы
. . .. . . . . . . . . . . . . . . . . . . . . .

Эта пиктограмма означает выводы. Здесь автор подводит итоги, обобщает изложенный материал или проводит анализ.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы по главе
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Глава 1

ПРОЦЕСС СОЗДАНИЯ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ

Сегодня практически нет людей, которые не знают, что такое компьютер. Помимо этого, достаточно распространённой тенденцией является наличие не одного,
а нескольких компьютеров, которые могут быть представлены большим количеством различных электронных приборов, это и как различные мобильные устройства: ноутбуки, смартфоны, планшеты и пр., так и менее мобильные: персональные
компьютеры, мейнфреймы, серверы и суперкомпьютеры. Компьютеры представляют собой сложные высокотехнологичные электронные устройства, способные
выполнять большое количество действий за небольшой промежуток времени. Для
корректной (и не очень в случае вирусов) работы компьютеров программистами
пишется невообразимо огромное количество компьютерных программ на множестве различных языков программирования.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Процесс создания компьютерных программ называется программированием.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Глава 1. Процесс создания программного обеспечения

зон простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 109, или разнице в девять порядков [1].
Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так:

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
«По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность
в глубоких концептуальных иерархиях, компьютерные технологии
бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории».
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Разумеется, за прошедшее с 1989 г. время сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками.
Дейкстра пишет, что ни один человек не обладает интеллектом, способным
вместить все детали современной компьютерной программы [2], поэтому нам —
разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо
этого мы должны попытаться организовать программы так, чтобы можно было
безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объёма программы, о котором можно думать в конкретный
момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе,
тем выше вероятность того, что вы уроните один из них и допустите ошибку при
проектировании и кодировании.
Всё перечисленное выше приводит нас к выводу, что любая программа должна создаваться с должной ответственностью и в процессе создания ПО разработчик должен учитывать большое количество разных, зачастую взаимоисключающих
требований. За всё время создания программ сам процесс создания ПО претерпел
незначительные изменения. Менялись технологии и инструменты разработки ПО,
появлялись новые парадигмы программирования, однако основные этапы разработки ПО остались практически неизменными.
Прежде чем остановиться подробнее на этапах разработки ПО, необходимо
остановиться на метафорах, которые используются при разработке. Важность использования метафор при разработке объясняется их простотой. Всегда проще ориентироваться на какую-то знакомую концепцию для понимания сложного процесса, чем не опираться ни на что.

1.1 Метафоры при создании ПО

Сама концепция и классификация метафор взята у автора бестселлера «Совершенный код» Стивена Макконнелла [3].
Нельзя недооценивать важность использования метафор для описания определённых процессов. Применение метафор для описания чего-либо позволяет нам
абстрагироваться от определённых аспектов самого процесса, остановившись на
значимых частях и описав с помощью наиболее простых и знакомых концепций.
Многие открытия в науке были сделаны при помощи метафор.

1.1 Метафоры при создании ПО
11

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

Глава 1. Процесс создания программного обеспечения

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

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

Множество метафор, описывающих разработку ПО, смутит кого угодно. Дэвид Грайс утверждает, что написание ПО — это наука [4]. Дональд Кнут считает
это искусством [5]. Уоттс Хамфри говорит, что это процесс [6]. Ф. Дж. Плождер
и Кент Бек утверждают, что разработка ПО похожа на управление автомобилем,
однако почти все приходят к почти противоположным выводам [7, 8]. Алистар
Кокберн сравнивает разработку ПО с игрой [9], Эрик Реймонд — с базаром [10],
Энди Хант и Дэйв Томас — с работой садовника, Пол Хекель — со съёмкой фильма
«Белоснежка и семь гномов» [11]. Фред Брукс упоминает фермерство, охоту на
оборотней и динозавров, завязших в смоляной яме [12]. Какие метафоры самые
лучшие?
Литературная метафора: написание кода.
Самая примитивная метафора берёт своё начало во фразе «написание кода».
В этом случае разработка ПО представляется как написание литературного произведения. Программист представляется писателем, который строка за строкой пишет код и превращает его в работающую программу.
Эта метафора достаточно полно описывает разработку ПО в одиночку, однако
разработку ПО в общем она описывает не очень адекватно. Разработка над современным программным продуктом редко ведётся в одиночку, что значительно
усложняет восприятие этой метафоры. Как можно представить добавление нового
текста в уже законченное произведение. При этом добавление текста может носить
не только характер добавления «главы», но и добавление нескольких новых строк.
Понятно, что в таком случае уже не получится «целого» литературного произведения, а в случае с ПО, такой вариант вполне возможен.
Помимо этого, литературная метафора подразумевает, что уже готовое произведение не изменяется, а печатается и далее остаётся неизменным. В случае разработки ПО большая часть работы может приходиться на период после разработки.
Из общего объёма работы над типичной программой обычно две трети выполняется после выпуска первой версии программы, а очень часто эта цифра достигает
90% [13].
В литературе поощряется оригинальность идей, в то время как при разработке
ПО такие подходы носят названия «изобретения квадратного колеса» и «создание
своего велосипеда». При разработке ПО принято повторно использовать существующие компоненты для ускорения выпуска программного продукта.
К сожалению, литературная метафора была увековечена в одной из самых популярных книг по разработке ПО — книге Фреда Брукса «The Mythical Man-Month»
(«Мифический человеко-месяц») [12]. Брукс пишет: «Планируйте выбросить первый экземпляр программы: вам в любом случае придётся это сделать». Перед глазами невольно возникает образ мусорного ведра, полного черновиков.