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

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

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

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

Была еще одна проблема из разряда неприятных, но не смертельных. Порча памяти из-за неправильного указателя. Сама по себе порча была незначительной, но спустя несколько тысяч машинных циклов программа вылетала, потому что одна из структур данных оказывалась поврежденной. Та поврежденная структура данных использовалась постоянно, поэтому мы не могли просто добавить в код команду «Остановить программу, когда она изменится». Я немного поразмыслил и наконец придумал двух- или трехступенчатую систему заплаток. Как только память портилась, первая заплатка активировала вторую, которая работала с другой частью кода. Это, в свою очередь, активизировало запись третьей заплатки в еще один участок. Наконец, когда эта третья заплатка замечала, что происходит что-то не то, она останавливала систему. Я придумал, как откладывать проверку до нужного момента с помощью такой динамической системы заплаток. К счастью, это сработало, и мы смогли быстро устранить неполадку.

Сейбел: Что наталкивает на подобные удачные идеи?

Козелл: Если я досконально разобрался в системе, будь то ПО для IMP или система разделения времени для PDP-1, несмотря на то, что она мультипрограммная, многослойная и основана на работе с прерываниями, все равно вся ее динамика находится у меня в голове. Я знаю, что и в каком порядке должно происходить и что не должно происходить. Это позволяет всегда представить примерную модель происходящего.

Надо сказать, что многие из возникавших тогда проблем относились к двум разным моделям компьютеров, и их анализ требовал недюжинной фантазии. Например, что-то происходит не так на первой машине, а последствия проявляются на второй. Я не могу остановить работу, первая машина уже обработала на 6000 пакетов больше, чем вторая, и вдруг вторая говорит, что один из пакетов поврежден. Что тогда делать? Всем нам троим приходилось садиться и прослеживать весь процесс в ретроспективе, чтобы найти ошибку и «вылечить» систему.

Сейбел: Был ли в систему встроен отладочный код?

Козелл: Нет.

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

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

Но тогда мы даже не думали об этом. Мы просто старались написать эту чрезвычайно сложную систему реального времени так, чтобы она работала быстро. Это само по себе было трудной задачей. Мы не закладывали никаких проверок на непротиворечивость; к чему тратить на это время? Так что все исправления вносились потом бессистемно. Загляни в такой-то раздел памяти, просмотри код, чтобы разобраться с тем, или другим, или третьим, потом вернись и начни сначала.

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