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

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

if ( X < у ) { swap = х; X - у; у = swap;

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

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

Во-вторых, психологическая установка влияет на выбор частей программы, изучаемых при обнаружении ошибки. Исследования показали, что программисты, отлаживающие код максимально эффективно, во время отладки мысленно отделяют нерелевантные фрагменты программы (Basili, Selby, and Hutchens, 1986). Это позволяет им сужать область поиска и находить дефекты быстрее. Однако при этом можно по ошибке «отложить в сторону» часть программы, содержащую дефект. В результате вы будете искать дефект в правильном фрагменте кода, игнорируя фрагмент, который на самом деле содержит дефект. Вы пойдете по неверному пути и должны будете вернуться к перекрестку. Некоторые советы из раздела 232 помогут преодолеть эту «слепоту при отладке».

«Психологическая дистанция»

Психологическую дистанцию можно определить как лег-

Першфетйаншижа Советы по

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

шение к уткам, человек может с легкостью перепутать слова «Queck» и «Quack», потому что они кажутся похожими. Психологическая дистанция между ними мала. Гораздо труднее перепутать «Тиаск» и «Quack», хотя они тоже различаются только одной буквой. Слово «Тиаск» похоже на «Quack» меньше, чем «Queck», потому что первая буква слова сильнее бросается в глаза, чем буква в середине.

Вот примеры психологических дистанций между именами переменных (табл. 23-1):



Табл. 23-1. Примеры психологических дистанций между именами переменных

Первая переменная

Вторая переменная

Психологическая дистанция

stoppt

stcppt

Почти незаметна

shiftrn

shiftrm

Почти отсутствует

dcount

bcount

Небольшая

claims 1

claims2

Небольшая

product

Большая

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

23.5. Инструменты отладки - очевидные и не очень

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

раздел 22.5, а об инструментах

Утилиты сравнения исходного кода ""° -

Утилиты сравнения исходного кода (такие как Diff) полезны при исправлении ошибок. Если после внесения нескольких изменений некоторые из них нужно отменить, но вы плохо помните, что именно вы изменяли, утилита сравнения исходного кода освежит вашу память, указав на различия кода. Если вы обнаружили в новой версии кода дефект, которого не было в предыдущей версии, просто сравните соответствующие файлы.

Предупреждающие сообщения компилятора

Одним из самых простых и эффективных инструментов отладки является сам компилятор.

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

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

Рассматривайте предупреждения как ошибки Некоторые компиляторы позволяют рассматривать предупреждения как ошибки. Одно из достоинств этой



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

Стандартизуйте параметры компиляции в масштабе всего проекта

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

Утилиты расширенной проверки синтаксиса и логики

Существуют инструменты, проверяющие код тщательнее, чем компилятор. Так, программисты на С используют утилиту lint, которая старательно ищет неинициализированные переменные (возникающие, например, при написании = = вместо =) и похожие тонкие проблемы.

Инструменты профилирования выполнения программы

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

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

Среды тестирования и леса

Першсрвгтиан ттиг О mm было сказано в разделе 23.2 в отношении поиска

тшщтшшшпшь дефектов, выделение проблемного фрагмента кода и его дяя шщщшш отдельных тестирование в изоляции от других фрагментов часто ока-ШСС08» раздеда 22.5. зывается самым эффективным способом изгнания бесов из

дефектной программы.



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