Сохранение полного дерева программы было необходимо, если бы компилятор"затачивался" на выполнение иных, кроме генерации кода, функций, например, наанализ программ (снятие метрических характеристик, статическое профилирование ит.п.) или в том случае, если бы мы собирались делать машинно-независимуюглобальную оптимизацию на уровне входного текста. Ничего подобного в проекте небыло.

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

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

Пришло время говорить о неприятном — через некоторое время от нас ушел третийучастник. Он весь был ориентирован на получение результата, а не на процессего достижения. Само по себе это исключительно ценное качество, его наличие(подкрепленное высокой квалификацией) гарантирует успешное завершение работы взаданные сроки. Однако в данном случае оно обернулось своей худшей стороной — откровенно небрежным кодированием ("компилятор соптимизирует" — классическийответ на все замечания), принятием важных решений "на ходу", без всякогообсуждения и плохо скрываемым недовольством коллегами, которые непонятно почемукопаются там, где надо скорее программировать. Главное — скорее! За один деньсделать работоспособный синтаксис, за месяц — добиться трансляции программы"Hello world!". Сложность системы не играет никакой роли, все программыустроены одинаково. Модули должны взаимодействовать согласно своим интерфейсам,обсуждать и комментировать которые нет смысла, они и так сами за себя говорят — на то они и интерфейсы.

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

Скрытое напряжение в команде возрастало, и первым не выдержал тот, кто несвязывал с проектом все свои помыслы. В один прекрасный день мы двое обнаружилив общем каталоге с рабочими тестами полторы сотни примеров, которые ломаликомпилятор, причем ломали его вроде бы на тех модулях, которые писали мы.Третий участник исчез. Мы поняли это однозначно: мое терпение кончилось,разберитесь, наконец, с тем, что у вас не работает, догоните меня, а я показаймусь другими делами.

Ошибки были исправлены примерно за неделю (половина из них оказалась "ненашими", а как раз того третьего), однако он так и не вернулся в проектникогда… Мы остались вдвоем.

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

Я хочу, чтобы нас правильно поняли. У нас нет к ушедшему абсолютно никакихпретензий. Нас не обманули, не предали, не нарушили никаких обязательств. Болеетого, я вполне допускаю, что сами мы не без греха, и работа в то время шла неслишком ритмично (надеюсь, что и ему уход не принес много горечи). И если ярассказываю об этом эпизоде, то только потому, что мы сами многое при этомпоняли и многому научились.

Чем меньше коллектив, тем большее, часто определяющее, значение приобретаетпроблема личностной совместимости — характеров, темпераментов, привычек иманер, т. е. вещей, которые прямо не относятся к профессии. Примером, близким кидеалу, можно считать Дениса Ритчи и Кена Томпсона. Вот как последний говорилоб этом в выступлении при вручении ему премии имени Тьюринга: "Нашесотрудничество было образцом совершенства. За десять лет, которые мыпроработали вместе, я могу вспомнить только один случай нескоординированнойработы. Тогда я обнаружил, что мы оба написали одинаковую ассемблернуюпрограмму из 20 строк. Я сравнил наши тексты и был поражен, обнаружив, что онисовпадают посимвольно. Результат нашей работы был намного больше, чем вклад насобоих по отдельности". Но это, как говорится, от Бога, один случай на миллион.Каких-либо рекомендаций давать невозможно, единственное — надо быть очень иочень осторожным при формировании коллектива.

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

Эта точка зрения, точнее, конкретный опыт, быть может, входит в противоречие ссовременными моделями процесса создания ПО, описанными классиками,-- Г.Бучем,Э.Йоданом и другими, однако повторю еще раз, компилятор Си++ — невполне типичная программная система, по крайней мере, с точки зрениясемантической и логической сложности.