Редкая профессия

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

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

сам язык

— процесс стандартизации зачастую преподносил совершенно неожиданные сюрпризы, и многого нельзя было предугадать заранее.

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

Так или иначе, мы приобрели ценнейший опыт, полностью пройдя все этапы жизненного цикла программного продукта (в том числе и его сопровождение) и набив на этом пути много шишек. Теперь, надеюсь, мы не наступим еще раз на те же самые грабли.

А вы?

Стиль программирования: на вкус и цвет товарища нет

По условиям контракта языком реализации был стандартный Си. Бельгийцы прислали свой компилятор ANSI C, но основным рабочим инструментом для нас служил gcc из системы GNU, так как он был лучше совместим с нашим любимым отладчиком gdb по формату объектных файлов. Много позже, и это ощущалось нами как внушительный успех, мы начали транслировать компилятор самим собой.

Как и полагается каждой солидной фирме, у наших партнеров имелись собственные внутренние правила и стандарты программирования. В числе необходимых для работы материалов они привезли нам документ под названием "C Coding Standards".

Трудно высказывать объективное мнение по такому тонкому вопросу, как стиль программирования. Здесь, как нигде больше, в полной мере проявляются вкусы и привычки программиста, которые очень трудно преодолеть, если они вступают в противоречие с требованиями, которым приходится следовать в работе. Зачастую расходятся мнения и участников проекта.

Я оказался в меньшей степени отравлен магнетическим воздействием системы UNIX и традициями программирования на Си, или, если угодно, находился под влиянием иной системы традиций ("правильно" построенные языки типа Алгола-68, Паскаля и Ады, большие компьютеры с "настоящими" операционными системами и т.д.), и с большим трудом привыкал к диктуемому "птичьим" языком Си стилю программирования, идущему, как мне кажется, непосредственно от личных пристрастий и привычек создателей языка. Фирменный стандарт, которому предлагалось следовать, честно воспроизводил эти "исторические" особенности, возводя их в ранг если не абсолютной истины, то безусловной нормы.

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