Программист-прагматик. Путь от подмастерья к мастеру
Добавить в закладки К обложке
- Высказывания программистов-практиков о книге "Программист-прагматик" - Страница 1
- Предисловие - Страница 2
- От авторов - Страница 4
- Кому адресована эта книга? - Страница 5
- Как происходит становление программиста-прагматика? - Страница 6
- Прагматики-одиночки и большие команды - Страница 7
- Непрерывность процесса - Страница 8
- Как составлена эта книга - Страница 9
- Исходные тексты программ и другие ресурсы - Страница 10
- Ваши отклики - Страница 11
- Благодарности - Страница 12
- Глава 1Прагматическая философия - Страница 13
- 1Мой исходный текст съел кот Мурзик - Страница 14
- Принятие ответственности - Страница 15
- 2Энтропия в программах - Страница 16
- 3Суп из камней и сварившиеся лягушки - Страница 18
- 4Приемлемые программы - Страница 20
- Находите компромисс с пользователями - Страница 21
- Знайте меру - Страница 22
- 5Портфель знаний - Страница 23
- Ваш портфель знаний - Страница 24
- Построение вашего портфеля - Страница 25
- Цели - Страница 26
- Возможности обучения - Страница 27
- Критическое осмысление - Страница 28
- 6Общайтесь! - Страница 29
- Глава 2Прагматический подход - Страница 32
- 7Пороки дублирования - Страница 33
- Как возникает дублирование? - Страница 34
- Навязанное дублирование - Страница 35
- Неумышленное дублирование - Страница 37
- Нетерпеливое дублирование - Страница 38
- Коллективное дублирование - Страница 39
- 8Ортогональность - Страница 40
- Что такое ортогональность? - Страница 41
- Преимущества ортогональности - Страница 42
- Проектные группы - Страница 43
- Проектирование - Страница 44
- Инструментарии и библиотеки - Страница 45
- Написание текста программы - Страница 46
- Тестирование - Страница 47
- Документация - Страница 48
- Жизнь в условиях ортогональности - Страница 49
- 9Обратимость - Страница 50
- Гибкая архитектура - Страница 52
- 10Стрельба трассирующими - Страница 53
- Программа, которую видно в темноте - Страница 54
- При стрельбе трассирующими вы не всегда попадаете в цель - Страница 56
- Программа трассировки и создание прототипов - Страница 57
- 11Прототипы и памятные записки - Страница 58
- Для чего создаются прототипы - Страница 59
- Как использовать прототипы - Страница 60
- Создание прототипов архитектуры - Страница 61
- Как не надо использовать прототипы - Страница 62
- 12Языки, отражающие специфику предметной области - Страница 63
- 13Оценка - Страница 67
- Насколько точной является "приемлемая точность"? - Страница 68
- Из чего исходят оценки? - Страница 69
- Что сказать, если вас просят оценить что-либо - Страница 71
- Глава 3Походный набор инструментов - Страница 72
- 14Преимущества простого текста - Страница 73
- Что такое простой текст? - Страница 74
- Недостатки - Страница 75
- Преимущества простого текста - Страница 76
- Подводим итог - Страница 77
- 15Игры с оболочками - Страница 78
- Утилиты оболочек и системы Windows - Страница 80
- 16Мощь редактирования - Страница 81
- Один-единственный редактор - Страница 82
- Средства редактирования - Страница 83
- Производительность - Страница 84
- Куда же направиться? - Страница 85
- Какой же редактор выбрать? - Страница 86
- 17Управление исходным текстом программ - Страница 87
- Команда, в которой я работаю, не использует систему управления исходным текстом - Страница 89
- Программы управления исходным текстом - Страница 90
- 18Отладка - Страница 91
- Психология процесса отладки - Страница 92
- Умонастроение отладки - Страница 93
- С чего начать? - Страница 94
- Стратегии отладки - Страница 95
- Элемент удивления - Страница 98
- Контрольные вопросы при отладке - Страница 99
- 19Обработка текста - Страница 100
- 20Генераторы текстов программ - Страница 102
- Пассивные генераторы - Страница 103
- Активные генераторы текста - Страница 104
- Генераторы текста не должны быть слишком сложными - Страница 105
- Генераторы текста не всегда генерируют тексты программ - Страница 106
- Глава 4Прагматическая паранойя - Страница 107
- 21Проектирование по контракту - Страница 108
- Реализация принципа ППК - Страница 111
- ППК и аварийное завершение работы программы - Страница 112
- Другие случаи применения инвариантов - Страница 113
- Динамические контракты и агенты - Страница 114
- 22Мертвые программы не лгут - Страница 116
- Аварийное завершение не означает "отправить в корзину для мусора" - Страница 117
- 23Программирование утверждений - Страница 118
- Не отключайте утверждения - Страница 119
- 24Случаи, в которых используются исключения - Страница 120
- Что является исключительным? - Страница 121
- Обработчики ошибок как альтернатива исключению - Страница 122
- 25Балансировка ресурсов - Страница 123
- Объекты и исключения - Страница 125
- Балансировка и исключения - Страница 126
- Случаи, при которых балансировка ресурсов невозможна - Страница 127
- Проверка баланса - Страница 128
- Глава 5Гибкость против хрупкости - Страница 129
- 26Несвязанность и закон Деметера - Страница 130
- Сведение связанности к минимуму - Страница 131
- Закон Деметера для функций - Страница 132
- А не все ли равно? - Страница 133
- 27Метапрограммирование - Страница 135
- Динамическая конфигурация - Страница 136
- Приложения, управляемые метаданными - Страница 137
- 28Временное связывание - Страница 139
- Последовательность операций - Страница 140
- Архитектура - Страница 141
- Проектирование с использованием принципа параллелизма - Страница 142
- Развертывание - Страница 144
- 29Всего лишь визуальное представление - Страница 145
- Протокол "Публикация и подписка" - Страница 146
- Принцип "модель-визуальное представление-контроллер» - Страница 147
- Отходя от графических интерфейсов - Страница 149
- Все такой же связанный (после стольких лет) - Страница 150
- 30Доски объявлений - Страница 151
- Реализация концепции доски объявлений - Страница 152
- Пример приложения - Страница 153
- Глава 6Пока вы пишете программу - Страница 154
- 31Программирование в расчете на стечение обстоятельств - Страница 155
- Как программировать в расчете на стечение обстоятельств - Страница 156
- Преднамеренное программирование - Страница 158
- 32Скорость алгоритма - Страница 159
- Что подразумевается под оценкой алгоритмов? - Страница 160
- Система обозначений О() - Страница 161
- Оценка с точки зрения здравого смысла - Страница 162
- Скорость алгоритма на практике - Страница 163
- 33Реорганизация - Страница 165
- Когда осуществлять реорганизацию? - Страница 166
- Как производится реорганизация? - Страница 167
- 34Программа, которую легко тестировать - Страница 169
- Модульное тестирование - Страница 170
- Тестирование в рамках контракта - Страница 171
- Создание модульных тестов - Страница 172
- Применение тестовых стендов - Страница 173
- Построение тестового окна - Страница 174
- Культура тестирования - Страница 175
- 35Злые волшебники - Страница 176
- Глава 7Перед тем, как начать проект - Страница 178
- 36Карьер для добычи требований - Страница 179
- В поисках требований - Страница 180
- Документация требований - Страница 181
- Чрезмерная спецификация - Страница 183
- Видеть перспективу - Страница 184
- Еще одна мелочь… - Страница 185
- Поддержка глоссария - Страница 186
- Прошу слова… - Страница 187
- 37Разгадка невероятных головоломок - Страница 188
- Степени свободы - Страница 189
- Есть более простой способ! - Страница 190
- 38Чувство готовности - Страница 191
- Здравое суждение или промедление? - Страница 192
- 39Западня со стороны требований - Страница 193
- 40Круги и стрелки - Страница 195
- Какова отдача от методов? - Страница 196
- Нужно ли использовать формальные методы? - Страница 197
- Глава 8Прагматические проекты - Страница 198
- 41Команды прагматиков - Страница 199
- Никаких разбитых окон - Страница 200
- Сварившиеся лягушки - Страница 201
- Общайтесь - Страница 202
- Не повторяйте самого себя - Страница 203
- Ортогональность - Страница 204
- Автоматизация - Страница 206
- Чувствуйте момент, когда нужно остановиться - Страница 207
- 42Вездесущая автоматизация - Страница 208
- Все в автоматическом режиме - Страница 209
- Компилирование проекта - Страница 210
- Автоматизация процесса сборки - Страница 211
- Автоматические административные процедуры - Страница 212
- Дети сапожника - Страница 213
- 43Безжалостное тестирование - Страница 214
- Что тестировать - Страница 215
- Как проводить тестирование - Страница 217
- Когда тестировать - Страница 220
- Кольцо сжимается - Страница 221
- 44Все эти сочинения - Страница 222
- Комментарии в программе - Страница 223
- Исполняемые документы - Страница 225
- Технические писатели - Страница 226
- Печатать документ или ткать его на холсте? - Страница 227
- Языки разметки - Страница 228
- 45Большие надежды - Страница 229
- Передача надежд - Страница 230
- Небольшой довесок - Страница 231
- 46Гордость и предубеждение - Страница 232
- Приложение АИнформационные ресурсы - Страница 233
- Профессиональные общества - Страница 234
- Собираем библиотеку - Страница 235
- Интернет-ресурсы - Страница 237
- Библиография - Страница 242
- Приложение ВОтветы к упражнениям - Страница 244
Проектирование с использованием принципа параллелизма
Поскольку Java все чаще принимается в качестве платформы, многие разработчики перешли к многопоточному программированию. Но программирование с использованием потоков налагает на конструкцию некоторые ограничения – и это хорошо. Эти ограничения настолько полезны, что нам хотелось бы пребывать под их благодатным покровом, когда бы мы ни занимались написанием программ. Это поможет нам делать нашу программу несвязанной и бороться с так называемым "программированием в расчете на стечение обстоятельств" (см. ниже одноименный раздел).
При работе с линейной программой легко сделать предположения, которые в конечном итоге приведут к небрежно написанным программам. Но параллелизм заставляет задумываться о происходящем несколько глубже – вы больше не находитесь в безвоздушном пространстве. Поскольку многие события могут теперь происходить "в одно и то же время", вы можете внезапно столкнуться с зависимостями, основанными на факторе времени. Прежде всего необходимо защитить любые глобальные или статические переменные от параллельного доступа. Теперь можно задать самому себе вопрос, зачем нужна глобальная переменная на первом месте. Кроме того, необходимо убедиться в том, что вы предоставляете непротиворечивую информацию о состоянии независимо от порядка вызовов. Например, в какой момент допускается опрашивание состояния вашего объекта? Если ваш объект находится в недопустимом состоянии в период между определенными вызовами, то вы, вероятно, полагаетесь на стечение обстоятельств – никто не вызовет ваш объект в этот момент времени.
Предположим, что есть подсистема работы с окнами, в которой интерфейсные элементы вначале создаются, а затем отображаются на дисплее. Вам не разрешается задавать состояние в элементе, пока он не отобразится. В зависимости от заданных параметров программы вы можете полагаться на то условие, что ни один другой объект не может воспользоваться созданным элементом, пока вы не выведете его на дисплей.
Но в параллельной системе это может и не выполняться. При вызове объекты всегда обязаны находиться в допустимом состоянии, а они могут вызываться в самое неподходящее время. Вы обязаны убедиться, что объект находится в допустимом состоянии в любой момент, когда потенциально он может быть вызван. Зачастую эта проблема возникает с классами, которые определяют отдельные программы конструктора и инициализации (где конструктор не оставляет объект в инициализированном состоянии). Используя инварианты класса, обсуждаемые в разделе "Проектирование по контракту", вы сможете избежать этой ловушки.
Четкие интерфейсыРазмышления о параллелизме и зависимостях, упорядоченных во времени, могут заставить вас проектировать более четкие интерфейсы. Рассмотрим библиотечную подпрограмму на языке С под названием strtok, которая расщепляет строку на лексемы.
Конструкция strtok не является поточно-ориентированной [33], но это не самое плохое, рассмотрим временную зависимость. Первый раз вы обязаны вызвать подпрограмму Strtok с переменной, которую вы хотите проанализировать, а во всех последующих вызовах использовать NULL вместо этой переменной. Если переменная принимает значение, отличное от NULL, программа повторно производит разбор содержимого буфера. Не принимая во внимание потоки, предположим, что вы собираетесь использовать Strtok для одновременного синтаксического анализа двух отдельных строк:
char buf1[BUFSIZ];
char buf2[BUFSIZ];
char *p, *q;
strcpy(bufl, "это тестовая программа");
strcpy(buf2, "которая не будет работать");
р = strtck(buf1," ");
q = strtok(buf2," ");
while (p && q) {
printf("%s %s\n", p, q);
p = strtok(NULL, " ");
q = strtok(NULL, " ");
}
Представленная программа работать не будет: существует неявное состояние, сохраняющееся в strtok между запросами. Вам придется использовать Strtok одновременно только с одним буфером.
Конструкция синтаксического анализатора строк на языке Java будет отличаться от указанной выше. Она должна быть поточно-ориентированной и представлять непротиворечивое состояние.
StringTokenizer st1 = new StringTokenizer("this is a test");
StrJngTokenlzer st2 = new StringTokenizer("this test will work");
while (st1.hasMoreTokens() && st2.hasMoreTokens()) {
- 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
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248
- 249
- 250
- 251
- 252
- 253