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

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

526 ЧАСТЬ V Усовершенствование кода

Три самых

Три самых

быстрых

медленных

программиста

программиста

Среднее время отладки (в минутах) 5,0

14,1

Среднее число необнаруженных дефектов 0,7

Среднее число новых дефектов, 3,0

внесенных в код при исправлении

имеющихся дефектов

Источник: «Some Psychological Evidence on How People Debug Computer

Programs* (Gould, 1975)

..... Три самых лучших в отладке программиста смогли найти дефекты при-

Jl мерно в 3 раза быстрее и внесли в код примерно в 2,5 раза меньше дефектов, чем три худших. Самый лучший программист обнаружил все дефекты и не внес во время их исправления новых. Самый худший не нашел 4 из 12 дефектов, а при исправлении 8 обнаруженных дефектов внес в код 11 новых.

Но ставить точку рано. После первого раунда отладки в коде самых быстрых программистов все еще остались 3,7 дефекта, а в коде самых медленных - 9,4 дефекта. Ни одна из групп не довела отладку до конца. У меня возник вопрос, что случится, если экстраполировать данные этого исследования на дополнительные циклы отладки. Мои результаты не являются статистически надежными, но они все же интересны. Применив те же показатели обнаружения и некорректного исправления дефектов к дополнительным циклам, я выяснил, что для снижения показателя необнаруженных дефектов до уровня 0,5 дефекта самой быстрой группе понадобились бы в общей сложности 3 цикла отладки, а самой медленной - 14. Если далее учесть, что время выполнения одного цикла отладки этими группами различается почти в 3 раза, мы получим, что самой медленной группе для полной отладки своих программ потребовалось бы в 13 раз больше времени, чем самой быстрой. Аналогичные крупные различия в эффективности отладки показали и другие исследования (Gilb, 1977; Curtis, 1981).

Эти данные не только сообщают нам кое-что об отладке, но меад качбСШ1# Ш и ешмо- подтверждают Главный Закон Контроля Качества ПО: по-тю его рарабошш. рщт вышение качества программы снижает затраты на ее разра-20.5, ботку. Лучшие программисты обнаружили больше дефектов

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

Дефекты как возможности обучения

о чем говорит наличие дефекта? Ну, если исходить из того, что наличие дефектов в программе нежелательно, это говорит о том, что вы не полностью понимаете программу Это тревожит. Все-таки, если вы написали программу, она должна делать то, что вам нужно. Если вы не до конца понимаете свои указания компилятору, еще чуть-чуть, и вы просто начнете пробовать все, что придет в голову, пока что-то не сработает, т. е. начнете программировать методом проб и ошибок. А раз так, дефекты неизбежны. Вам не нужно учиться исправлять дефекты - вам нужно знать, как их избегать.



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

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

Изучить собственные ошибки Все дефекты вашей про- jifmm тт граммы лежат на вашей совести. Не каждый день у вас по- тодйки, помогающие узнать, ка-является такая прекрасная возможность лучше узнать соб- киб ошШи чть всего допус-ственные недостатки, и грех ее не использовать. Обнаружив каетелично аы, рассматриваются ошибку, спросите себя, как и почему вы допустили ее. Как s шге «А DiscWne for Software вы могли найти ее быстрее? Как ее можно было предотвра- (Humphrey, Ш5).

тить? Содержит ли код другие подобные ошибки? Можно ли исправить их до того, как они приведут к проблемам?

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

Изучить используемые способы решения проблем Чувствуете ли вы уверенность, обдумывая свой подход к отладке? Работает ли он? Быстро ли вы находите дефекты? Может, ваш подход к отладке неэффективен? Чувствуете ли вы тоску и огорчение? Не отлаживаете ли вы программу, опираясь на случайные предположения? Нужно ли как-то улучшить процесс отладки? Если учесть объем времени, уходящего на отладку во многих проектах, анализ вашего способа отладки определенно не будет пустой тратой времени. Трата некоторого времени на анализ и изменение процесса отладки может оказаться самым эффективным способом сокращения общего времени разработки программы.

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

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

Неэффективный подход

к сожалению, в вузах почти никогда не рассматриваются принципы отладки. Возможно, вы прослушали пару специальных лекций, но скорее всего на этом все и кончилось. Я никак не могу пожаловаться на качество полученного образования, но и в моем случае рассмотрение отладки ограничилось советом «для нахождения дефектов включайте в код команды печати». Это неадекватный уровень. Если



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

Руководство Дьявола по отладке

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

трртны0 исправпения. Рх принципов из следующего списка.

Айрис Ввссй (Iris Vessey) Поиск дефектов, основанный на гадании Для нахождения дефекта разбросайте по программе случайным образом команды печати и изучите выходные данные. Если при помощи команд печати найти дефект не получается, попробуйте изменить тот или иной фрагмент - может, что и сработает. Не сохраняйте первоначальный вариант программы и не регистрируйте внесенные изменения. Если вы точно не знаете, что делает программа, программирование становится более увлекательным. Запаситесь колой и леденцами, потому что вам придется провести перед монитором всю ночь.

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

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

X - Compute( у ) if ( У = 17 )

X = $25.15 - если у = 17, метод ComputeO не работает; мы это исправляем

Зачем анализировать метод ComputeQ в поисках причин непонятной проблемы со значением 17, если можно просто написать частный случай в очевидном месте?

Суеверная отладка

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

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



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