Чтение онлайн

Английское слово bug (ошибка) используется для описания "объекта, вызывающего ужас" уже начиная с XIV в. Контр-адмирал д-р Грэйс Хоппер (создатель языка COBOL) оказался первым, кто наблюдал компьютерного «жучка», буквально – моли, попавшей в одно из электромеханических реле, из которых состояли первые вычислительные системы. Когда техника попросили объяснить, почему машина ведет себя не так, как надо, он сообщил, что в системе "завелся жучок", и в соответствии со своими должностными обязанностями приклеил его клейкой лентой вместе с крылышками и всем остальным в рабочий журнал.

К сожалению, мы до сих пор встречаемся с «жучками» в системе, хотя и не из рода перепончатокрылых. Но значение этого слова, принятое в XIV в. – привидение – возможно более применимо сейчас, нежели тогда. Изъяны в программном обеспечении проявляют себя по-разному – от превратно истолкованных требований до ошибок в написании исходных текстов. К сожалению, возможности современных компьютерных систем все еще ограничены исполнением только того, что мы им прикажем, а не обязательно того, что мы хотим, чтобы они сделали.

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

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

Воспользуйтесь тем фактом, что отладка представляет собой не что иное, как решение задачи, и атакуйте ее именно с этой позиции.

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

На самом деле, не важно, кто виноват в ошибке – вы или кто-то другой. Это все равно остается вашей проблемой.

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

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

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

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

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

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

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

Однажды один из авторов книги (Энди Хант) работал над большим графическим приложением. Дело уже шло к выпуску готовой версии, когда тестировщики сообщили о том, что приложение «падало» всякий раз, когда они проводили черту при помощи конкретной кисти. Программист начал оспаривать это утверждение, говоря о том, что все в порядке: он сам пытался выполнять аналогичную прорисовку, и все работало превосходно. Обмен любезностями продолжался в течение нескольких дней, когда напряженность вдруг резко возросла.

В конце концов все собрались в одной комнате. Тестировщик выбрал нужный инструмент (кисть) и провел черту, из ВЕРХНЕГО ПРАВОГО угла к НИЖНЕМУ ЛЕВОМУ. Приложение «упало»! Программист тихонько охнул, а затем виновато проблеял, что при тестировании он проводил черту только из НИЖНЕГО ЛЕВОГО угла к ВЕРХНЕМУ ПРАВОМУ, и при этом ошибка никак не выявлялась.

В этой истории есть два момента, заслуживающих внимания:

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