Евгений Зуев - Редкая профессия Страница 8

С тех пор отладка тестов почти полностью легла на наши плечи, и мы вложили в пакет очень много своего труда. Тестовой команды как таковой уже нет — трудно рассчитывать, что студенты будут, практически ничего не получая, в течение долгого времени тянуть эту тяжелую лямку (тем более, что студенты ВМК сейчас могут с легкостью получить, пусть не слишком интересную, но гораздо менее тяжелую и неплохо оплачиваемую работу). Таким образом, мы с достаточным основанием можем говорить о том, что этот тестовый набор в значительной степени наш (мы имеем в виду только авторство — с формальной точки зрения он принадлежит заказавшей его фирме). Сейчас это прекрасный, всесторонне выверенный и протестированный набор из почти семи тысяч небольших, но строго специфицированных и единообразно составленных программ, охватывающий весь язык Си++ в соответствии с последней (декабрьской 1996 г.) версией предварительного стандарта. Не знаю, что делают с ним бельгийцы, продают ли они его и за сколько, но для нас ценность его исключительно велика, мы любим его не меньше, чем компилятор.

В какой-то статье было сказано, что нормальное соотношение разработчиков и тестировщиков на Западе — один к двум. У нас пропорция была даже выше.

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

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

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

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

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

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

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

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

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

Быстро сказка сказывается, да не скоро дело делается

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

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

Наш проект, который мы через несколько месяцев представили бельгийцам, был разработан гораздо серьезнее, однако сам предмет оказался настолько сложен, что степень проработки проблем оказалась недостаточной. Время от времени приходилось возвращаться к проекту и вносить в него изменения и добавления. С одной стороны, это замедляло работу по реализации и не всем нравилось (выше я уже писал об этом). С другой — время разработки проекта даже очень сложной системы не должно быть чрезмерно большим: многого просто невозможно предвидеть — парадокс в том, что только начав реализацию, можно получить обоснованные проектные решения. К тому же программистам психологически очень тяжело недели и месяцы проводить в обсуждениях, рисовать схемы и писать тексты (между прочим, на английском языке!-- в контракте специально был оговорен proper English), не составив ни строчки кода (здесь мы хорошо понимаем третьего участника). Но даже если бы подобных задержек не было, мы физически не успели бы запрограммировать компилятор, оставаясь в пределах заявленного срока — объем программного текста, который предстояло написать, во много раз превышал то, что уже было написано. О некоторых трудностях реализации, которые ждут нас впереди, было даже страшно задумываться.