Кодеры за работой. Размышления о ремесле программиста - Сейбел Питер

Сейбел: Кстати о сбоях. Какова худшая ошибка, с которой вы имели дело?

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

Когда я был зеленым программистом и работал на IBM 1130, решение, как исправить ошибку, однажды явилось мне во сне. Или сразу после пробуждения. Я бился над ней пару дней, ничего не получалось. И вот посреди ночи — озарение. Оказалось, я кое-что пропустил в спецификации интерфейса.

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

Так или иначе, 12 бит с карты записывались в старшие 12 бит 16-битного слова, а младшие разряды использовались для хитрого трюка: можно было запустить функцию чтения перфокарты асинхронно, и тогда буфер заполнялся тоже асинхронно, и при этом выполнялась функция преобразования. И этот младший разряд определял, была ли считана следующая колонка перфокарты. Если была, то выполнялось преобразование. Таким образом, почти сразу после считывания всей перфокарты преобразование завершалось — за счет того, что эти процессы перекрывали друг друга, получался выигрыш во времени. Я же скармливал в функцию сырые двоичные данные, которые не подчинялись этим ограничениям. Я просто не обратил внимания на примечание. Я думал, что это обычная функция преобразования, а оказалось, что в интерфейсе этой функции есть особенность: она задействовала младшие разряды, о которых обычно думать не приходится. Она обрабатывала буфер и говорила мне: «Данные еще не поступили из устройства для чтения перфокарт». В принципе, я знал, что такое возможно, но тогда это мне в голову не пришло. А потом во сне меня озарило. Вот такой странный случай.

А вот другая занятная история. Я отвечал за Maclisp, a Maclisp поддерживал большие числа — целые числа произвольной точности. Они у нас были уже несколько лет, считалось, что они хорошо отлажены. Они широко использовались в Macsyma, пользователи Macsyma все время с ними работали. И вот приходит сообщение от Билла Госпера: «Частное двух этих целых чисел неверно». Он заметил это, поскольку частное примерно равнялось Пи.

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

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

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

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

Сейбел: Как обычно — ошибка не ходит одна.

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

Сейбел: Кроме ночных озарений, каков ваш излюбленный метод отладки? Что вы предпочитаете — символьные отладчики, вывод на печать, утверждения, формальные доказательства или все сразу?

Стил: Честно говоря, я ленив и начинаю с вывода на печать, хотя при сложных ошибках это самый неэффективный метод. Но зато с простыми работает хорошо, так что попробовать стоит. С другой стороны, на мое отношение к программированию сильно повлияла работа над проектом, написанном на Haskell. Так как это чисто функциональный язык, там нельзя было использовать вывод на печать.

И я полностью перешел на модульное тестирование. Пришлось придумывать модульные тесты для каждой из функций. Крайне полезный опыт.

Это повлияло на облик Fortress — я постарался ввести туда свойства, поощряющие модульное тестирование. И записать их не в отдельные файлы, а вместе с текстом программы. Мы заимствовали кое-что из контрактного программирования языка Eiffel — предусловия и постусловия для процедур. Есть места, где размещаются тестовые данные и процедуры модульных тестов, и тестовая программа запускает эти процедуры по первому вашему требованию.

Сейбел: Раз уж вы упомянули контрактное программирование: как вы используете утверждения в собственном коде?

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

Сейбел: А как насчет пошаговой отладки? Если все прочее не помогает, вы прибегаете к ней?

Стил: Зависит от длины программы. И, конечно, помогают инструменты, которые позволяют пропускать целые заведомо безошибочные куски. В Common Lisp есть отличная функция STEP. Я много раз пошагово отлаживал код на Common Lisp. Это очень здорово — возможность пропустить функции, в которых уверен. И еще возможность расставить ловушки и сказать себе: «Сюда мне смотреть не нужно, до тех пор пока этот цикл не повторится семнадцать раз». На PDP-10 были для этого аппаратные средства, это было здорово, особенно в MIT. Тогда они любили модернизировать свои машины, добавляя в них что-нибудь. Можно долго рассказывать про выполнение одного и того же кода разными способами.

Сейбел: Вы применяете к своему коду формальные доказательства?

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

Сейбел: Питер ван дер Линден в своей книге «Expert С Programming» (Программирование на Си для экспертов) отвел доказательствам целую главу в пренебрежительном духе. Вот вам доказательство того-то, но смотрите — оно с ошибками! Ха-ха-ха!

Стил: Да, и доказательства могут быть с ошибками.

Сейбел: Но, по крайней мере, встретить ошибки в них меньше шансов, чем в проверяемом коде?

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

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