Главная - Литература

0 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 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

сто должны убедиться в проведении достаточного планирования, чтобы его недостаток не привел позднее к серьезным проблемам.

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

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

Наконец, проведение аналогии с домостроительством позволяет лучше понять работу над очень крупными программными проектами. При создании очень крупного объекта цена неудачи слишком высока, поэтому объект надо спроектировать тщательнейшим образом. Строительные организации скрупулезно разрабатывают и инспектируют свои планы. Все крупные здания создаются с большим запасом прочности; лучше заплатить на 10 % больше за более прочный материал, чем рисковать крушением небоскреба. Кроме того, большое внимание уделяется времени. При возведении Эмпайр Стейт Билдинг время прибытия каждого грузовика, поставлявшего материалы, задавалось с точностью до 15 минут. Если грузовик не прибывал в нужное время, задерживалась работа над всем проектом.

Аналогично, очень крупные программные проекты требуют планирования более высокого порядка, чем просто крупные проекты. Кейперс Джонс сообщает, что программная система из одного миллиона строк кода требует в среднем 69 видов документации (Jones, 1998). Спецификация требований к такой системе обычно занимает 4000-5000 страниц, а проектная документация вполне может быть еще в 2 или 3 раза более объемной. Маловероятно, чтобы один человек мог понять весь проект такого масштаба или даже прочитать всю документацию, поэтому подобные проекты требуют более тщательной подготовки.

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

Дшшштйш ш$т Гра- Метафора построения-конструирования может быть расши-Momie тштчрм по тоо- рена во многих других направлениях, именно поэтому она

рштщтт метафоры кон- столь эффективна. Благодаря этой метафоре отрасль раз-отррроваш см. в статье *Whal работки ПО обогатилась многими популярными термина-Sappoftsthe Roof?« (Starr 2003). такими как архитектура ПО, леса (scaffolding), конструирование и фундаментальные классы. Наверное, вы сможете

назвать и другие примеры.



Дополнительные ресурсы

Среди книг общего плана, посвященных метафорам, моделям и парадигмам, главное место занимает «The Structure of ШрШо(йьмШй2Ш Scientific Revolutions* (3d ed. Chicago, IL: The University of

Chicago Press, 1996) Томаса Куна (Thomas S. Kuhn). В своей книге, увидевшей свет в 1962 г. Кун рассказывает о возникновении, развитии и смене теорий. Этот труд, вызвавший множество споров по вопросам философии науки, отличается ясностью, лаконичностью и включает массу интересных примеров взлетов и падений научных метафор, моделей и парадигм.

Применение методов разработки ПО: интеллектуальный инструментарий

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

Консульганты по вопросам разработки ПО иноща совету- щщ сшика О тЫ-ют программистам придерживаться одних методов разра- ре методов проектртиия них ботки ПО в ущерб другим. Это печально, потому что, если комбшироаанин см. раздел 5Ж вы станете использовать только одну методологию, вы увидите весь мир в терминах этой методологии. В некоторых случаях это сделает недоступными для вас другие методы, лучше подходящие для решения текущей проблемы. Метафора инструментария поможет вам держать все методы, способы и хитрости в пределах досягаемости и применять их в уместных обстоятельствах.

Комбинирование метафор

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

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



Статья «The Paradigms of Programming». 1978 Turing Award Lecture («Communications of the АСМ», August 1979, pp. 455-60) Роберта У. Флойда (Robert W. Floyd) представляет собой увлекательное обсуждение использования моделей при разработке ПО; некоторые аспекты рассматриваются в ней в контексте идей Томаса Куна.

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

Метафоры являются по природе эвристическими, а не алгоритмическими, поэтому зачастую они немного небрежны.

Метафоры помогают понять процесс разработки ПО, сопоставляя его с другими, более знакомыми процессами.

Некоторые метафоры лучше, чем другие.

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

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

Метафоры не исключают друг друга. Используйте комбинацию метафор, наиболее эффективную в вашем случае.



0 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 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0032