Эта программа работает? Почему вы уверены в этом? Вы сможете дать точное определение слова “работает”? Откуда взялись числа

и . Помните о “магических” константах (см. раздел 5.5.1). Указывать числа и как литеральные константы в тексте программы — плохой стиль, но может быть, и эти числа неверны? Существуют ли места, где температура опускается ниже —1000°F (–573°C)? Существуют ли места, где температура поднимается выше 1000°F (538°C)?

ПОПРОБУЙТЕ

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

(минимальная температура) и (максимальная температура). Эти значения определят пределы применимости вашей программы.

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

. Очевидно, что ответ неверен. Почему? Потому что ни одна фигура не может иметь отрицательную площадь. Итак, вы исправляете ошибку и получаете ответ . Этот результат правильный? Ответить на этот вопрос труднее, потому что мы обычно не помним формулу для вычисления площади шестиугольников. Итак, чтобы не опозориться перед пользователями и не поставить им программу, выдающую глупые результаты, необходимо проверить, что ответ правильный. В данном случае это просто. Шестиугольник похож на квадрат. Набросав на бумаге рисунок, легко убедиться, что площадь шестиугольника близка к площади квадрата 3x3. Площадь этого квадрата равна 9. Итак, ответ 21.65685 не может быть правильным! Переделаем программу и получим ответ 10.3923. Это уже похоже на правду!

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

1. Является ли данный ответ разумным для данной задачи?

Можно даже задать более общий (и более трудный) вопрос.

2. Как распознать разумный результат?

Обратите внимание на то, что мы не спрашиваем: “Каков точный ответ?” или “Каков правильный ответ?” Этот ответ нам даст сама программа. Нам лишь хочется, чтобы ответ не был глупым. Только в том случае, если ответ является разумным, имеет смысл продолжать работать над программой.

Оценка — это замечательное искусство, сочетающее в себе здравый смысл и очень простую арифметику. Некоторые люди легко выполняют оценку умозрительно, но мы предпочитаем “рисовать каракули на обратной стороне конверта”, поскольку в противном случае легко сделать ошибку. Итак, здесь мы называем оценкой неформальный набор приемов, или прикидку (guesstimation), сочетающую в себе интуитивную догадку и примерную оценку.

ПОПРОБУЙТЕ

Длины сторон нашего правильного шестиугольника равны 2 см. Получили ли мы правильный ответ? Просто выполните прикидочные вычисления. Возьмите лист бумаги и набросайте эскиз. Не считайте это занятием ниже своего достоинства. Многие знаменитые ученые восхищали людей своими способностями получать примерный ответ с помощью карандаша и клочка бумаги (или салфетки). Эта способность — на самом деле простая привычка — поможет сэкономить массу времени и избежать ошибок.

Часто оценка связана с предварительным анализом данных, необходимых для вычисления, но не имеющихся в наличии. Представьте, что вы протестировали программу, оценивающую время путешествия из одного города в другой. Правдоподобно ли, что из Нью-Йорка в Денвер можно доехать на автомобиле за 15 часов 33 минуты? А из Лондона в Ниццу? Почему да и почему нет? На каких данных основана ваша догадка об ответах на эти вопросы? Часто на помощь приходит быстрый поиск в веб. Например, 2000 миль — это вполне правдоподобная оценка расстояния между Нью-Йорком и Денвером. По этой причине было бы трудно (да и не законно) поддерживать среднюю скорость, равную 130 миль/ч, чтобы добраться из Нью-Йорка в Денвер за 15 часов (15*130 ненамного меньше 2000). Можете проверить сами: мы переоценили и расстояние, и среднюю скорость, но наша оценка правдоподобности ответа вполне обоснована.

ПОПРОБУЙТЕ

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

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

Итак, написав определенную программу, вы должны найти и удалить ошибки. Этот процесс обычно называют отладкой (debugging), а ошибки — жучками (bugs). Иногда говорят, что термин жучок возник в те времена, когда аппаратное обеспечение выходило из строя из-за насекомых, случайно заблудившихся среди электронных ламп и реле, заполнявших комнаты. Иногда считают, что этот термин изобрела Грейс Мюррей Хоппер (Grace Murray Hopper), создатель языка программирования COBOL (см. раздел 22.2.2.2). Кто бы ни придумал этот термин пятьдесят лет назад, ошибки в программах неизбежны и повсеместны. Их поиск и устранение называют отладкой (debugging).

Отладка выглядит примерно так.

1. Компилируем программу.

2. Редактируем связи.

3. Выполняем программу.

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