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

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

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

Брукс замечает, что главные несущественные проблемы nejiejecimm 0сыш 0 ранних разработки ПО уже давно решены. Например, несуществен- .рд несущественные пробяе-ные проблемы, связанные с неудобным синтаксисом язы- мы прояйляются сильнее, нем е ков программирования, постепенно утратили свою значи- зрелых (см. раздел 4.3). мость по мере эволюции языков. Несущественные проблемы, связанные с неинтерактивностью компьютеров, исчезли, когда на смену ОС, работающим в пакетном режиме, пришли системы с разделением времени. Среды интегрированной разработки избавили программистов от проблем, обусловленных плохим взаимодействием инструментов.

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

Источник всех этих существенных проблем - сложность как несущественная, так и существенная.

Важность управления сложностью

Программные проекты редко терпят крах по техническим разработки причинам. Чаще всего провал объясняется неадекватной проекта приложения: сделать выработкой требований, неудачным планированием или его настолько простым, чтобы неэффективным управлением. Если же провал обусловлен ло очевидно, что в нем нет все-таки преимущественно технической причиной, очень «едостаткое, или сделать его „ таким сложным, чтобы в нем не

часто ею оказывается неконтролируемая сложность. Иначе очевидных недостатков.

говоря, приложение стало таким сложным, что разработчики v Я Хойр (CAR Нот) перестали по-настоящему понимать, что же оно делает. Если

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

Управление сложностью - самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.

Сложность - не новинка в мире разработки ПО. Один из пионеров информатики Эдсгер Дейкстра обращал внимание на то, что компьютерные технологии -

4-403



единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 10, или разнице в девять порядков (Dijkstra, 1989). Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так: «По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность в глубоких концептуальных иерархиях, компьютерные технологии бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории». Разумеется, за прошедшее с 1989 г время сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками.

Дейкстра пишет, что ни один человек не обладает интел-Однйм т симптомов того, что

вы погрязни в чрезмерной лектом, способным вместить все детали современной ком-спожности, является упрямое пьютерной программы (Dijkstra, 1972), поэтому нам - раз-применение метода, нерелеван- работчикам ПО - не следует пытаться охватить всю про-тность которого очевидна по грамму сразу. Вместо этого мы должны попытаться орга-крайней мере пЫт внешне- низовать программы так, чтобы можно было безопасно му наблюдателю, Лри 0TOM вы ,

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

ляет поддерживать в воздухе, тем выше вероятность того,

Ф. Лж Плолжео

п) I DI I уроните один из них и допустите ошибку при про-

ектировании или кодировании.

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

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

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

Как бороться со сложностью?

Чаще всего причинами неэффективности являются:

сложное решение простой проблемы;

простое, но неверное решение сложной проблемы;

неадекватное сложное решение сложной проблемы.



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

старайтесь свести к минимуму объем существенной сложности, с которым придется работать в каждый конкретный момент времени;

сдерживайте необязательный рост несущественной сложности.

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

Желательные характеристики проекта

Высококачественные проекты программ имеют несколько

„ Работая над проблемой, я ни-

общих характеристик. Если вы сумеете достичь всех этих

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

сывают и качество программы, тогда как другие являются ВтктШШ Ывг}

внутренними характеристиками проекта.

Перекрестная ссьита Эти харак-

Вот список таких внутренних характеристик проекта. з

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

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

Слабое сопряжение Слабое сопряжение (loose coupling) предполагает сведение к минимуму числа соединений между разными частями программы. Для проектирования классов с минимальным числом взаимосвязей используйте принципы адекватной абстракции интерфейсов, инкапсуляцию и сокрытие информации. Это позволит максимально облегчить интеграцию, тестирование и сопровождение программы.

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



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.0083