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

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

Одной из единиц измерения «программной сложности» яв- дц нттьт роняется число воображаемых объектов, которые вам прихо- шт, ншшт это вошш-дится одновременно держать в уме, чтобы разобраться в но. но т щощ* программе. Это умственное жонглирование - один из са- Аяьбщ ШшШн

мых сложных аспектов программирования и причина того,

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

ШИнтуитивно понятно, что сложность программы во многом определяется количеством усилий, требуемых для ее понимания. Том Маккейб (Тот МсСаЬе) опубликовал важную статью, утверждающую, что сложность программы определяется ее управляющей логикой (1976). Другие исследователи обнаружили дополнительные факторы, кроме предложенного Маккейбом циклома-тического показателя сложности (например, количество переменных, используемых в программе), но они согласны, что управляющая логика - одна из главных составляющих сложности, если не самая главная.

Насколько важна сложность?

Исследователи в области вычислительной техники уже на ««..„л .

протяжении двух десятилетий осознают важность пробле- сти йодраэдел «Ошный Тех-мы сложности. Много лет назад Дейкстра предупреждал об нический Штртт ПО: упрае-опасности сложности: «Компетентный программист полно- пение сложностью» раздела 5.2. стью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью» (Dijkstra, 1972). Из этого не следует, что вам нужно увеличить объем вашего черепа, чтобы иметь дело с невероятной сложностью. Это предполагает, что вы можете никогда не связываться с чрезмерной сложностью и всегда должны предпринимать шаги для ее уменьшения.

Сложность управляющей логики имеет большое значение, потому что она коррелирует с низкой надежностью и частыми ошибками (МсСаЬе, 1976, Shen et al., 1985). Вильям Т. Уорд (William Т. Ward) сообщал о значительном выигрыше в надежности ПО, полученном в Hewlett-Packard в результате применения показателя сложности Маккейба (1989b). Этот показатель использовался для идентификации проблемных участков в одной программе длиной 77 ООО строк. Коэффициент ошибок после выпуска этой программы составил 0,31 ошибку на 1000 строк кода. Коэффициент ошибок в программе длиной 125 ООО строк не превышал 0,02 ошибки на 1000 строк кода. Ворд отметил, что из-за своей меньшей сложности обе программы имели значительно меньше дефектов, чем другие программы в Hewlett-Packard. Моя компания Construx Software в 2000 г получила похожие результаты при использовании средств измерения сложности для поиска проблемных методов.



Общие принципы уменьшения сложности

Вы можете бороться со сложностью двумя способами. Во-первых, вы можете улучшить свои способности к умственному жонглированию, выполняя специальные упражнения. Но программирование само по себе - уже хорошее упражнение, а люди, похоже, сталкиваются с трудностями при жонглировании большим количеством, чем от пяти до девяти воображаемых сущностей (Miller, 1956). Так что потенциал улучшения невелик. Во-вторых, вы можете уменьшить сложность ваших программ и количество усилий, прилагаемых для их понимания.

Как измерить сложность

Опи- 3 интуитивное ощущение того, что де-

шныйздееь под)(одосйоеанна метод более или менее сложным. Исследователи пыта-важной статье 1от ются формализовать свои чувства и приводят несколько

«А Complexity Мшут> (1976). способов измерения сложности. Возможно, самый важный

способ предложил Том Маккейб, Сложность в нем измеряется с помощью подсчета количества «точек принятия решения» в методе (табл. 19-2):

Табл. 19-2. Способы подсчета точек принятия решения в методе

1. Начните считать с 1 на некотором участке кода.

2. Добавляйте 1 для каждого из следующих ключевых слов или их эквивалентов: while repeat for and or.

3. Добавляйте 1 для каждого варианта в операторе case. Приведем пример:

if ( ( (status = Success) and done ) or

( not done and ( numLines >= maxLines ) ) ) then ...

В этом фрагменте вы начинаете считать с 1, получаете 2 для ifi- для and, 4 - для or и 5 - для and. Таким образом, этот фрагмент содержит всего пять точек принятия решения.

Что делать с этим измерением сложности

Посчитав количество точек принятия решения, вы можете использовать это число для анализа сложности вашего метода:

0-5 Этот метод, возможно, в порядке.

6-10 Начинайте думать о способах упрощения метода.

10+ Вынесите часть кода в отдельный метод и вызывайте его.

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



\4аксимум в 10 точек принятия решения не является абсолютным ограничением. Лспользуйте количество этих точек как сигнал, предупреждающий о том, что метод, возможно, стоит перепроектировать. Не считайте его неколебимым правилом. Оператор case со многими вариантами может иметь более 10 элементов, но в зависимости от назначения case может быть глупо разбивать его на части.

Другие виды сложности

Лзмерение сложности, предложенное Маккейбом, - не ппшш.*а,пг\*пгш единственный значимый показатель, но он наиболее широко обсуждение показателей

:>бсуждался в компьютерной литературе и особенно поле- сложности т. ь ««Softwafe Еп-хн при рассмотрении управляющей логики. Другие пока- gineering Metrics Ш Models* з.атели включают количество используемых данных, число (Conte. Dunsmore аш! 81ш.1986). ровней вложенности в управляющих конструкциях, число

трок кода, число строк между успешными обращениями к переменной («диапазон»), число строк, в которых используется переменная («время жизни») и объем звода и вывода. Некоторые исследователи разработали составные показатели слож-iocTH, основанные на сочетании перечисленных простых вариантов.

Контрольный список: вопросы

по управляющим структурам http: cc2e.com/1985

□ Используют ли выражения идентификаторы true и false, а не 7 и О?

□ Сравниваются ли логические значения с true и false неявно?

□ Сравниваются ли числовые значения со своими тестовыми значениями явно?

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

□ Составлены ли логические выражения позитивно?

□ Сбалансированы ли пары скобок?

□ Используются ли скобки везде, где они необходимы для большей ясности?

□ Заключены ли логические выражения в скобки целиком?

□ Написаны ли условия в соответствии с расположением чисел на числовой прямой?

□ Используются ли в программах на Java выражения вида a.equals(b), а не а == b там, где это необходимо?

□ Очевидно ли применение пустых операторов?

□ Выполнено ли упрощение глубоко вложенных выражений с помощью повторной проверки части условия, преобразования в операторы if-then-else или case, перемещения части кода в отдельные методы, преобразования с использованием более обеъктно-ориентированной модели или они были улучшены как-то иначе?

□ Если метод содержит более 10 точек принятия решения, есть ли хорошая причина, чтобы не перепроектировать его?



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