Кодеры за работой

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

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

Сейбел:

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

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

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

Козелл:

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

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

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

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

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

И вот я думал: какими базовыми константами пользовался Уилл, собирая все это вместе? Когда два тайм-аута были одинаковыми по длине, было ли это совпадением или то был один и тот же тайм-аут? Кто знает? Сколько нужно внести изменений в код, чтобы изменить одну константу? Если в процессе работы замечаешь, что ждешь чего-то недостаточно долго и операция завершается по тайм-ауту, когда не должна, то понимаешь, что не можешь просто взять и изменить один тайм-аут в программе, потому что там все взаимосвязано.

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

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

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

Уилл был чем-то вроде мощного генератора идей. Помнится, я как-то пожаловался Фрэнку Харту, что его все время ставят в новые проекты. Дело было в том, что BBN производила много революционных продуктов, а Уилл как раз был мастером делать то, что еще никто не делал.

Он был не настолько хорош, чтобы выдавать на 100% идеальный готовый код. Но его код был на 75-80% вполне приличным и в большинстве случаев работал. Когда он ушел в другой проект — TIP, если не ошибаюсь, — мы с Дэйвом продолжали работать над системой IMP, и именно тогда я переписал алгоритм маршрутизации, поскольку не понимал, откуда взялись заложенные в нем константы. Это по-прежнему оставался алгоритм Уилла, но переписанный в моем стиле. И теперь я понимал, как и почему он работает, потому что сам заставил его работать.