Настоящая работа

Сейчас мы с ужасом думаем, что было бы, не будь у нас тестового пакета. Мы самисмогли бы написать сто, от силы двести слабо систематизированных тестов (набольшее не хватило бы времени и терпения), может быть, насобирали быдесяток-другой исходников на Си++, пропихнули бы все это черезкомпилятор и ходили довольные и гордые тем, что наваяли. Потом программа началабы исправно рушиться на каждой мало-мальски серьезной программе, мы в паникелатали бы дыры, вскоре нам и заказчикам это надоело, и проект тихо умер бы,оставив у нас на руках никому не нужные останки того, что когда-то называлоськомпилятором. Судьба многих и многих проектов…

Все было по-другому. Вечером мы запускали тестовый прогон, утром (если нашжалкий SparcClassic или монструозный диск Maxtor на 300 Мбайт за ночь не далсбой) получали протоколы тестирования, разбирали "по принадлежности"непрошедшие тесты, и начиналась настоящая программистская работа?—?поиск иисправление ошибок.

Как интересно проектировать структуры данных и алгоритмы! Какое увлекательноезанятие?—?писать программы! Какое наслаждение смотреть, как они работают и какприятно видеть результаты прогонов! Это все и работой назвать язык неповорачивается?—?сплошные удовольствия. Программисты меня поймут. Настоящая жеработа, которая требует предельных умственных усилий, от которой действительноустаешь, и которая по-настоящему вызывает удовлетворение, заключается именно вотладке. Нужно держать в голове (никакой отладчик в этом не поможет)замысловатую логику изрядного фрагмента очень сложной программы, буквально ввиде движущихся образов представлять себе, как срабатывает та или иная функциядля данного фактического параметра, и постоянно помнить состояние и глубинустека вызовов для кода, который кто-то тебя (или коллегу) дернул сделатьрекурсивным. Кстати говоря, весь компилятор мы отладили без всяких фокусов,используя древние как мир отладочные печати (плюс десяток специально написанныхфункций, которые опять же печатали таблицы и деревья в наглядном виде) ипримитивный по интерфейсу, но чрезвычайно удобный и мощный отладчик gdb.

Первые тестовые прогоны были кошмарны: на половине тестов компилятор выдавалвереницы жутких диагностических сообщений, которые, казалось, никогда не должныпоявляться, другие аварийно заканчивались знаменитой диагностикой "coredumped", те тесты, которым все-таки удалось прорваться сквозь компилятор, приисполнении выдавали неверные результаты, и лишь единицы завершались скромнойфразой "test passed". Казалось, не в силах человеческих разобраться в этойкаше. Однако, капля камень точит.

Поначалу-то как раз было легче?—?в первую очередь находились и исправлялисьочевидные ляпы. Как правило, одно исправление приводило к проталкиваниюдесятка, а то и больше ранее неудачных тестов. Были, конечно, и "наведенные"ошибки, которые в один прекрасный день магическим образом бесследно исчезали,оставляя после себя смутное беспокойство (а вдруг, как исчезли, так и вновьпоявятся?). Но чем дальше двигалась отладка, тем дороже давался каждый тест.Ошибки становились все тоньше, специфичнее и тяжелее в поиске, а чтобыисправить найденную ошибку, иногда приходилось перетрясти десяток функций вразных модулях. Исправление одной ошибки не раз приводило к появлению целойсерии "экранированных" ею ошибок, которые не могли проявиться до ликвидациипервой ошибки. Компилятор, казалось, сопротивлялся лечению, словно строптивыйребенок.

А тут еще в самый разгар работы, когда ошибки щелкаются одна за другой,компилятор на глазах выздоравливает, словно от тяжелой болезни,-- приходит новаяверсия стандарта. Значит, надо опять смотреть, что изменилось. Ладно есливводится новая языковая возможность, это может быть несложно в реализации идаже приятно: когда ни у Borland, ни у gcc еще не были реализованы описательmutable или булевский тип, у нас уже все работало. Хуже, если уточняютсядетали семантики хорошо известных конструкций, что, как правило, влечет засобой переделку базовых алгоритмов. Так, общий алгоритм сравнения типов,алгоритм обработки совместно используемых функций (одноименных функций,различающихся числом и типами параметров) и в особенности, алгоритмы,реализующие правила вызова деструкторов и обработки исключений переделывалисьпосле почти каждой новой версии предварительного стандарта. Понятно, что каждаятакая переделка работающей программы вызывает поток новых ошибок, и мыоткатываемся на месяц назад…

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

А интересно, как тестирует свои компиляторы Watcom?