Роббинс Д. - Отладка приложений для Microsoft .NET и Microsoft Windows - 2004

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	11

чи, можно дистанцироваться от предметной области. Нет — разработчик отвеча ет за решение задачи, а не просто предоставляет возможность решения!

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

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

Невежество и плохое обучение разработчика

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

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

Лучший способ научиться технологии — создать что либо с ее помощью. Очень давно, когда NuMega послала меня изучать Microsoft Visual Basic, чтобы мы могли писать программы для разработчиков на Visual Basic, я представил план, чему я собираюсь учиться, и это потрясло моего босса. Идея заключалась в создании приложения, оскорблявшем вас; оно называлось «Обидчик». Версия 1 представ ляла собой форму с единственной кнопкой, щелчок которой выводил случайное оскорбление из числа закодированных в тексте программы. Вторая версия чита ла оскорбления из базы данных и позволяла вам добавлять оскорбления, исполь зуя форму. Третья версия была подключена к корпоративному серверу Microsoft Exchange и позволяла посылать оскорбления работникам компании. Моему руко водителю понравилось то, что я собираюсь делать, чтобы изучить технологию. Все ваши руководители заботятся о том, чтобы всегда была возможность доложить боссу о вашей работе в тот или иной день. Если вы предоставите своему руководителю такую информацию, вы попадете в любимчики. Когда я впервые столкнулся с .NET, я просто снова использовал идею Обидчика, который стал называться Обидчик.NET!

12 ЧАСТЬ I Сущность отладки

О том, какие навыки и знания критичны для разработчиков, я расскажу в раз деле «Необходимые условия отладки».

Стандартный вопрос отладки

Нужно ли пересматривать код?

Безусловно! К сожалению, многие компании подходят к этому совершенно неверно. Одна компания, на которую я работал, требовала формальные пересмотры кода точно так же, как это описано в одном из этих фантасти ческих учебников для программистов, который был у меня в колледже. Все было расписано по ролям: был Архивариус для записи комментариев, Сек ретарь для ведения протокола, Привратник, открывающий дверь, Руково дитель, надувающий щеки, и т. д. На самом деле было 40 человек в комнате, но никто из них не читал код. Это была пустая трата времени.

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

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

Недостаточная приверженность к качеству

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

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

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	13

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

Другой отличный пример — первое издание этой книги. На компакт диске, прилагаемом к книге, было около 2,5 Мб исходных текстов программ (это не компилированные программы — только исходные тексты!). Это очень много, и я рад, что это во много раз больше, чем прилагается к большинству других книг. Многие люди не могут себе даже представить, что я потратил больше половины времени, ушедшего на эту книгу, на тестирование этих программ. Народ балдеет, находя ошибки в кодах Bugslayer2 , и чего я меньше всего хочу — это получать письма типа «Ага! Ошибочка в Bugslayer!». Без ошибок на том компакт диске не обошлось, но их было только пять. Моим обязательством перед читателями было дать им только лучшее из того, на что я способен. Моя цель в этом издании — не более пяти ошибок в более чем 6 Мб исходных текстов этого издания.

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

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

2Название рубрики в журнале «MSDN Magazine». В русском переводе, выпускаемом из дательством «Русская Редакция», рубрика называется «Отладка и оптимизация». —

Прим. перев.

14 ЧАСТЬ I Сущность отладки

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

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

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

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

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

Пришло время подумать о процессе отладки. Многие начинают думать об отлад ке, только споткнувшись на фазе кодирования, но вы должны думать о ней с са мого начала, с фазы выработки требований. Чем больше времени вы уделите про цессу планирования, тем меньше времени (и денег) вы потратите на отладку впос ледствии.

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

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	15

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

В отличной книге Стива МакКонелла (Steve McConnell) «Code Complete» (Micro soft Press, 1993, стр. 25–26) есть упоминание о стоимости исправления ошибки, которая по мере разработки растет экспоненциально, как и стоимость отладки (во многом по тому же сценарию, как и при добавлении или удалении функций).

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

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

Необходимые условия отладки

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

Необходимые навыки

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

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

ваш проект;

ваш язык программирования;

используемая технология и инструментарий;

операционная система/среда;

центральный процессор.

Знай свой проект

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

16 ЧАСТЬ I Сущность отладки

К сожалению, все проекты разные, и единственный путь изучить проект — прочитать проектную документацию, если она есть, и пройтись по коду с отлад чиком. Современные системы разработки имеют браузеры классов, позволяющие увидеть основы устройства программы. Но вам может понадобиться настоящее средство просмотра, такое как Source Insight от Source Dynamics. Кроме того, вы можете задействовать средства моделирования, такие как Microsoft Visual Studio.NET Enterprise Architect, интегрированную с Microsoft Visio, чтобы увидеть взаимосвя зи или диаграммы UML (Unified Modeling Language), описывающие программу. Даже минимальные комментарии в тексте программы лучше, чем ничего, если это пре дотвратит дизассемблирование.

Знай язык реализации

Знать язык (языки) программирования вашего проекта труднее, чем может пока заться. Я говорю не только об умении программировать на этом языке, но и о знании того, как исполняется программа, написанная на нем. Скажем, програм мисты C++ иногда забывают, что локальные переменные, являющиеся классами или перегруженными операторами, могут создавать временные объекты в стеке. В свою очередь оператор присваивания может выглядеть совершенно невинным и при этом требовать большого объема кода для своего исполнения. Многие ошиб ки, особенно связанные с производительностью, — результат неправильного при менения средств языка программирования. Поэтому полезно изучать индивиду альные особенности используемых языков.

Знай технологию и инструментарий

Владение технологиями — первый большой шаг в борьбе с трудными ошибками. Например, если вы понимаете, что делает COM, чтобы создать COM объект и воз вратить его интерфейс, вы существенно сократите время на поиск причины за вершения с ошибкой запроса интерфейса. Это же относится к фильтрам ISAPI. Если у вас проблемы с правильно вызванным фильтром, вам надо знать, где и когда INETINFO.EXE должен был загружать ваш фильтр. Я не говорю, что вы должны знать наизусть файлы и строки исходного текста или книги. Я говорю, что вы должны хотя бы в общем понимать используемые технологии и, что более важно, точно знать, где найти подробное описание того, что вам нужно.

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

Знай свою операционную систему/среду

Знание основ работы ОС/среды позволит просто устранять ошибки, а не ходить вокруг них. Если вы работаете с неуправляемым кодом, вы должны суметь отве тить на вопросы типа: что такое динамически подключаемая библиотека (DLL)? Как работает загрузчик образов? Как работает реестр? Для управляемого кода вы должны знать, как ASP.NET находит используемые компоненты, когда вызывают ся финализаторы, чем отличается домен приложения от сборки и т. д. Многие са

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	17

мые неприятные ошибки появляются из за неправильного использования средств ОС/среды. Мой друг Мэтт Питрек (Matt Pietrek), научивший меня прелестям от ладки, утверждает, что знание ОС/среды и центрального процессора отличает богов отладки от простых смертных.

Знай свой центральный процессор

И последнее, что нужно знать, чтобы стать богом отладки неуправляемого кода, — это центральный процессор. Вы должны хоть что то знать о центральном про цессоре для разрешения наиболее неприятных ошибок. Было бы хорошо, если бы аварийное завершение всегда наступало там, где доступен исходный текст, но обычно при аварийном завершении отладчик показывает окно с дизассемблиро ванным текстом. Я всегда удивляюсь, как много программистов не знает (более того, не хочет знать) язык ассемблера. Он не настолько сложен, три четыре часа, потраченные на его изучение сэкономят вам бесчисленные часы, затрачиваемые на отладку. Еще раз: я не говорю, что вы должны уметь писать собственные про граммы на ассемблере, я даже не думаю, что сам умею это делать. Главное, чтобы вы могли прочитать их. Все, что вам нужно знать о языке ассемблера, имеется в главе 7.

Выработка мастерства

Имея дело с технологиями, вы должны непрерывно учиться и идти вперед. Хотя я

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

Кроме чтения книг и журналов по отладке, вам также нужно писать утилиты, причем любые. Лучший способ научиться — это работать, а в нашем случае — про граммировать и отлаживать. Это не только отточит ваши главные навыки, такие как программирование и отладка, но, если рассматривать эти утилиты как насто ящие проекты (т. е. завершать их к сроку и с высоким качеством), то вы разовьете

идополнительные навыки, такие как планирование проектов и оценка графика исполнения.

Кстати, завершенные утилиты — прекрасный материал, который можно пока зать на собеседовании при приеме на работу. Хотя очень немногие программис ты берут свои программы на собеседования, работодатели рассматривают таких кандидатов в первую очередь. То, что вы располагаете рядом работ, выполненных в свободное время дома, — свидетельство того, что вы можете завершать свои ра боты самостоятельно и что вы увлечены программированием, а это позволит вам практически сразу войти в состав 20% лучших программистов.

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

Для изучения технологии, ОС и виртуальной машины (процессора) можно порекомендовать и методику восстановления алгоритма (reverse engineering). Это

18 ЧАСТЬ I Сущность отладки

ускорит ваше изучение языка ассемблера и функций отладчика. Прочитав главы 6 и 7, вы будете достаточно знать о промежуточном языке (Microsoft Intermediate Language, MSIL) и языке ассемблера IA32. Я не советовал бы вам начинать с пол ного восстановления текста загрузчика ОС — лучше начать с задач поскромнее. Так, весьма поучительно познакомиться с реализацией CoInitializeEx для неуправ ляемого кода и класса System.Diagnostics.TraceListener — для управляемого.

Чтение книг и журналов, написание утилит, знакомство с текстами других программистов и восстановление алгоритмов — отличные способы повысить мастерство отладки. Однако самые лучшие ресурсы — это ваши друзья и коллеги. Не бойтесь спрашивать их, как они сделали что либо или как что то работает; если их не поджимают сроки, они должны быть рады помочь вам. Я люблю, когда люди задают мне вопросы, так как сам узнаю больше, чем те, кто задает мне вопросы! Я постоянно читаю программистские группы новостей, особенно то, что пишут парни из Microsoft, кого называют MVP (Most Valuable Professionals, наиболее ценные профессионалы).

Процесс отладки

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

Как вы увидите, чтобы реализовать этот процесс отладки, не нужно быть семи пядей во лбу. Самое трудное — начинать этот процесс каждый раз, приступая к отладке. Вот девять шагов, связанных с рекомендуемым мной подходом к отладке (рис. 1 1).

Шаг 1. Воспроизведи ошибку.

Шаг 2. Опиши ошибку.

Шаг 3. Всегда предполагай, что ошибка твоя.

Шаг 4. Разделяй и властвуй.

Шаг 5. Мысли творчески.

Шаг 6. Усиль инструментарий.

Шаг 7. Начни интенсивную отладку.

Шаг 8. Проверь, что ошибка исправлена.

Шаг 9. Научись и поделись.

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

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	19

Сформулируй новую гипотезу

Воспроизведи ошибку

Опиши ошибку

Всегда предполагай, что ошибка твоя

Разделяй и властвуй

Мысли творчески

Усиль инструментарий

Начни интенсивную отладку

Проверь, что ошибка исправлена

Исправленная ошибка

Научись и поделись

Рис. 1 1. Процесс отладки

Исправь

ошибку

Шаг 1. Воспроизведи ошибку

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

Теперь вы, возможно, думаете: «Ну, вот! Конечно же, главное воспроизвести ошибку. Если бы я всегда смог это сделать, мне бы не нужна была ваша книга!» Все зависит от вашего определения слова «воспроизводимость». Мое определение — воспроизведение ошибки на одной машине один раз в течение 24 часов. Этого достаточно для моей компании, чтобы начать работу над ошибкой. Почему? Все

20 ЧАСТЬ I Сущность отладки

просто. Если вам удается повторить ошибку на одной машине, то на 30 машинах вам удастся повторить ее 30 раз. Люди сильно заблуждаются, если пытаются по вторить ошибку на всех доступных машинах. Если у вас есть 30 человек, чтобы долбить по клавишам, — хорошо. Однако наибольшего эффекта можно добиться, автоматизировав UI, чтобы вывести ошибку на чистую воду. Вы можете восполь зоваться программой Tester из главы 17 или коммерческими средствами регрес сионного тестирования.

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

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

Шаг 2. Опиши ошибку

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

Шаг 3. Всегда предполагай, что ошибка твоя

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