Редкая профессия - [13]

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

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

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

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

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

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

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

К нашему удивлению, бельгийцы легко согласились с продлением срока работы. Впрочем, они довольно плотно (хотя до времени и формально) контролировали весь процесс и могли понять, что мы даром времени не теряем и перенос сроков носит объективный характер.

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

К тому времени мы уже вполне убедились, что квалификация позволяет нам на достойном уровне довести проект до завершения без чьей бы то ни было помощи. Наши консультации с заказчиками сводились к вопросам о конкретном устройстве тех компонент их системы программирования, с которыми компилятор должен взаимодействовать. Даже на вопросы о формате промежуточного представления, которое, согласно фирменной документации, было их собственной разработкой, они далеко не всегда могли дать вразумительный ответ (позднее это нашло свое объяснение). Обсуждать детали языка было не с кем, собственных специалистов по Си++ у них не было, они вообще до сих пор программировали на Си самой древней версии Кернигана и Ритчи. Их помощь состояла в периодических посылках очередных версий предварительного стандарта (до тех пор, пока рабочая группа не стала выкладывать их на свой Web-сервер) и материалов очередных заседаний и дискуссий, предшествующих принятию того или иного языкового свойства. Последнее было действительно интересно и ценно, так как эти материалы, насколько мы знаем, нигде не публикуются и рассылаются только членам рабочих групп.