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

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

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

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

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

Козелл: Нет.

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

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

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

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

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

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

Сейбел:Это были буквально ряды лампочек?

Козелл:Да, ряды лампочек. Одна лампочка - один бит.

Сейбел:И тумблеры для ввода адресов?

Козелл:Да. Я считаю, это лучше. На PDP-1 были тумблеры. На той машине, о которой мы говорим сейчас, помнится, были кнопки.

Сейбел:Как вам троим работалось вместе?

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

Для меня он был чем-то вроде виртуального противника в компьютерной игре, причем использующего в качестве оружия Фортран. Дело в том, что и алгоритм маршрутизации, и всю динамическую часть сиетемы управления IMP собирал Уилл. Одно из важных условий работы системы реального времени - каждой операции должна быть сопоставлена предельная продолжительность, тайм-аут. Нельзя дожидаться чего-то бесконечно долго, потому что понятия “бесконечно долго” в таких системах просто не существует.

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