Человеческий фактор в программировании
Добавить в закладки К обложке
- Предисловие - Страница 1
- Предисловие к первому изданию - Страница 3
- IГрупповая разработка - Страница 5
- 2Консенсус и компромисс - Страница 7
- 4Скромный и высокопоставленный писарь - Страница 11
- 5Официальное пространство - Страница 14
- 6Раздражающие прерывания - Страница 17
- IIКовбои и ковгерлы - Страница 19
- 8Возвращение блудного ковбоя - Страница 22
- 9Единство в разнообразии - Страница 25
- 10Кодеры-ковбои и программисты-мудрецы - Страница 28
- IIIОрганизация работы - Страница 33
- 12Методы хаоса - Страница 36
- 13Открытая архитектура - Страница 39
- 14Синхронное плавание - Страница 42
- 15Командная политика - Страница 45
- 16Все сразу - Страница 47
- 17Заговор упрямцев - Страница 49
- IVИнструменты, модели и методы - Страница 51
- 19Вопросы моделирования - Страница 54
- 20Свет мой, зеркальце - Страница 56
- 21Методичное сумасшествие - Страница 58
- 22Говоря по существу - Страница 60
- 23Будущие формы - Страница 63
- 24Цели программного обеспечения - Страница 66
- 25Шито белыми нитками - Страница 69
- VСовершенствование процесса - Страница 73
- 27Повторение и вознаграждение - Страница 76
- 28Суперобучение - Страница 79
- 29Вверх по водопаду - Страница 81
- 30Своевременная поставка - Страница 83
- 31Под давлением - Страница 85
- 32Re: Архитектура - Страница 87
- 33Пошаговое улучшение качества - Страница 89
- VIЮзабилити программного обеспечения - Страница 95
- 35Сложность и прогрессирующий функционизм - Страница 98
- 36Назад к истокам - Страница 101
- 37Цветной язык - Страница 104
- 38Совершенствующиеся середнячки - Страница 107
- 39Пригодны ли вы - Страница 110
- 40Редактирование интерфейсов - Страница 113
- 41Сервис - Страница 115
- VIIУдобные объекты - Страница 117
- 43Глубокое понимание - Страница 121
- 44Абстрактные объекты - Страница 125
- 45Новая среда - Страница 128
- 46Полезные ситуации - Страница 132
- 47Эффективные объекты - Страница 136
- 48Связанные объекты - Страница 140
- VIIIЭто превосходное новое программное обеспечение - Страница 143
- 50Интерфейсы разнообразные - Страница 146
- 51Мастеры - Страница 148
- 52Образы будущего - Страница 150
- IXКультура и качество - Страница 152
- 54Агенты изменения - Страница 154
- 55Встроено самое лучшее - Страница 156
- 56Заметки из итальянского ресторана - Страница 159
- 57Наставничество - Страница 162
- 58На обучение - Страница 164
- 59Одаренные программисты - Страница 166
- 60Иконы отрасли - Страница 168
- 61Импресарио - Страница 170
- Приложение - Страница 172
- Библиография - Страница 174
32Re: Архитектура
Что произошло с архитектурой программного обеспечения? В типичном приложении для малого бизнеса или в стандартном коммерческом пакете зачастую бывает трудно обнаружить присутствие хоть какой-то структуры. Архитектура — будь то внутренняя функциональная структура или структура пользовательского интерфейса — сегодня часто оказывается первой жертвой сжатых по времени разработок, коротких периодов между релизами и быстрого проектирования приложений. Иногда просто не остается времени на обдумывание всех последствий архитектурных решений. Зачастую едва хватает времени на то, чтобы просто подумать. Приехали. Системы собираются сразу, как только придумываются их новые компоненты, без особого внимания к общей структуре. Темпы настолько высоки, что разработчики не видят дальше следующей строки кода или следующего элемента.
Новая технология помогла мало. Инструменты визуального проектирования (см. главу 23) открывают новые пути к быстрому созданию сложных систем, однако скорость визуального проектирования и легкость построения рабочих приложений также способствуют недостаточному планированию. Инструменты даже могут приводить к такому стилю разработки, когда небольшие куски кода, связывающие логику ведения бизнеса с элементами интерфейса и базовой функциональностью, подвешиваются к визуальным компонентам. Все это объединяется паутиной из передаваемых сообщений и цепочек событий, в которой никто не может толком разобраться. В результате сегодня у нас есть классический «спа-гетти-код», в котором все связано со всем. Когда каждое изменение не-предсказуемо передается по всей сети взаимосвязанного кода, возможности для дальнейшего развития программного обеспечения иссякают.
Второй шансДобавьте к быстрому созданию прототипов итеративную доработку, и последние остатки архитектуры могут утонуть в программном болоте. Это вызывает сожаление, потому что итеративное создание прототипов является мощным методом для разработки более удобного программного обеспечения за меньшее время. Создание прототипов позволяет своевременно поставлять функциональные программы или перепробовать различные подходы. Прототипы компонентов необходимы для получения отзывов пользователей, основанных на их реальных потребностях. Даже при создании пользовательского интерфейса для относительно скромных систем все предусмотреть с первого раза невозможно. Это не зависит от того, сколько времени и сил вы затратили на проектирование. Создание прототипов и итеративная доработка дают второй шанс (а также третий и четвертый) для того, чтобы довести до ума интерфейс пользователя. С каждой новой итерацией интерфейс и его внутренние компоненты становятся качественнее и функциональнее, обеспечивая все большие возможности и большую эффективность.
К сожалению, структура первого прототипа, которая удачно вписалась в общую концепцию, сильно зависит от основной архитектуры развивающейся системы. Система растет с каждой новой доработкой. Появляются новые слои компонентов, создаются новые функциональные возможности. Все это продолжается до тех пор, пока основная структура, казавшаяся такой разумной при небольшом размере системы, не начинает разваливаться под грузом доработок и уточнений.
Было бы большим соблазном просто вернуться к тем легендарным дням функциональной декомпозиции, когда дисциплинированные разработчики с помощью CASE-инструментов проектировали устойчивую и упорядоченную архитектуру всей системы. Такое проектирование велось до написания первых строк кода. Однако к тому времени, когда одна команда при помощи традиционных методов создает лишь системную архитектуру, RAD-команда1, оснащенная инструментами быстрого визуального проектирования, уже сдает готовую рабочую систему. Поэтому методы построения системной архитектуры необходимо включить в ускоренный цикл разработки. Построение надежной структуры не должно существенно замедлять процесс разработки в целом.
Возможно, для этого надо заново пересмотреть место архитектуры программного обеспечения в процессе разработки. Обычно под архитектурой мы понимаем нечто, предшествующее построению. Однако так же, как можно переписать код, можно перестроить и архитектуру (в мире экстремального программирования такая процедура называется рефакторин-гом). Например, одному большому банку в Австралии пришлось вернуться к своим традиционным системам после того, как был прекращен один претенциозный и чрезмерно крупный проект построения новой общебанковской информационной системы. Прежняя система объединяла многие поколения клуджей[Клудж (от англ. kludge) — устройство, программа или ее часть, которые теоретически не должны работать, но почему-то работают. — Примеч. ред.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
В конце февраля 2009 года в продаже на Amazon появил
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.