Самая устаревшая инфраструктура, которую только можно купить за деньги

перевод
tangro 14 сентября 2015 в 10:57 58,8k
Оригинал: Juho Snellman
На днях исполняется 10 лет с тех пор, как я получил самую странную свою работу.

Шел 2005-ый год. Мой интерес к разработке системы управления контентом на Java для компании, недавно купившей наш стартап, неуклонно улетучивался, в то время как моей настоящей страстью была разработка компиляторов и инструментов языковой инфраструктуры (в основном для SBCL). Как-то раз я заметил открытую вакансию как-раз по этому направлению, что вообще-то было достаточно редким явлением. Я быстро прошел интервью — настолько быстро, что даже не задал нужных вопросов и проигнорировал несколько тревожных звоночков.

Меня ожидало захватывающее путешествие в мир ретрокомпьютинга.

Начало странностей


Итак, это был бывший отдел разработки внутренних инструментов очень большой компании, назовём её Х. По некоторым причинам Х отделила данный отдел и продала его среднего размера консалтинговой компании, назовём её Y. Итак, я собирался работать на Y. Они искали людей, разбирающихся в компиляторах, чтобы они взяли на себя поддержку их собственного компилятора языка С (не только компилятора, но еще и линкера, ассемблера и т.д.). Я неверно их понял, поскольку думал, что этот набор они унаследовали от Х. Но это было не так. Компилятор пришел из ещё одной большой компании, назовём её Z, которая прекратила его поддержку. Тогда Х купила исходные коды у Z за очень большие деньги, и отдала Y чтобы та, наконец, что-то с этим всем поделала. На самом деле это был даже не один набор инструментов, а целых два. Ух, даёшь ещё больше компиляторов!

Я начал работать в сентябре, но какие-то графики поломались и ещё целый месяц или два у нас не было работы. У меня было достаточно времени для акклиматизации. И это было хорошо, потому что с момента, когда я ступил в это здание у меня появилось ощущение, что я странным образом переместился в параллельную вселенную, где сейчас начало 80-ых годов. Ну, знаете, тот случай, когда вам нужно найти некоторую старую документацию и в конце-концов вы её находите внутри древней самописной системы контроля версий, написанной поверх RCS.

В первый же рабочий день я обнаружил, что компания Х использует, вероятно, самый большой кластер VAX в мире для сборки своего продукта. Да, дюжины VAX под VMS, работающих как компилирующая ферма, создающая x86-код. Зачем вообще этой компании понадобилось иметь собственный компилятор С? Ну, у них существовал их собстенный внутренний невероятный язык программирования, который вы можете представить, если подумаете об императивном Erlang с синтаксисом Pascal. Программы на этом языке компилировались в код на С, для сборки которого и нужен был собственный компилятор С. Я не знаю сколько кода было написано на этом их невероятном внутреннем языке, но по моим оценкам — где-то миллионов 10 строк кода минимум.

Зачем же в этом процессе был нужен собственный компилятор С? Компиляция С-кода давала бинарники, которые затем могли запускаться только на (конечно же!) их собственной внутренней невероятной операционной системе, которая была написана в конце 80-ых. Эта операционная система использовала сегментные регистры 386-го процессора для эмуляции многопоточности и пересылки сообщений. Для поддержки всего этого им был нужен компилятор со значительно более «умной» работой с сегментными регистрами, чем это бывает в обычных компиляторах. Вы можете спросить насколько вообще разумно полагаться на сегментные регистры в 2005-ом году, когда работа с ними становится всё медленнее и медленнее с каждым новым поколением процессоров, а в x86-64 их поддержка и вовсе прекращается. А вы не волнуйтесь насчёт этого! В компании существовал параллельный проект по переносу всего этого кода на Solaris.

После нескольких месяцев сидения сложа руки и изучения всей этой загадочной инфраструктуры в наш отдел разработки компиляторов пришла посылка. Мы ожидали исходники. Но постойте, почему указано, что для переноски требуется 2 человека? Они что их — распечатали?!

Ах, если бы всё было так просто! Это был аж целый сервер, который мы должны были использовать для сборки компилятора, когда получим его исходный код. Это был компьютер с процессором 80286, работающий на операционной системе Intel Xenix 286 3.5. Единственным способом обмениваться с этим поразительным воплощением мощи вычислительных технологий был последовательный порт, работающий на скорости 9600 bps. К счастью, предыдущие владельцы этого сервера были достаточно добры, чтобы установить на его огромный 40-мегабайтный жесткий диск Kermit, так что мне хотя бы не нужно было возиться с дискетами. Боже, каким же поразительным куском древней истории были эта машина и её операционная система!

Вы можете спросить, было ли мудрым решение использовать машину 15-20 летней давности в качестве единственного способа сборки приложения — она ведь неизбежно рано или поздно сломается. Я даже поднял эту проблему и предложить сделать образ жесткого диска и попробовать запустить его в виртуальной машине. Эту идею отклонили, поскольку машина была старой и хрупкой, мы не могли рисковать, разбирая её и делая образ диска — его в случае чего было бы очень сложно заменить. Когда предыдущие владельцы искали это железо по антикварным магазинам, они нашли всего два до сих пор работающих экземпляра на всю страну.

Сейчас самое время сказать, что я, вообще-то, стрелянный воробей. Меня вырастили волки на сервере SunOS 4, на котором я позже администрировал учётки нескольких сотен пользователей. Моя персональная почта в 2005-ом году работала через UUCP. Мои прошлые выходные (сейчас, в 2015-ом) прошли за попыткой сборки частично отсутствующих исходников интерпретатора Lisp, написанных ещё до моего рождения. В общем, вы понимаете, что я питаю уважение к старым компьютерам и программам.

Но даже по моим стандартам уровень компьютерной археологии в проекте разработки этого компилятора был запредельным. И, как оказалось позже, я ещё не достиг дна кроличьей норы.

Спустя ещё несколько недель наконец приехали исходники. Они были написаны на PL/M. (Подождите, это вообще язык программирования? Да нет, вы шутите, правда?). А последняя дата модификации исходников была в 80-каком-то году. Инструкция по сборке проекта была напечатана на печатной машинке. Не на принтере. Некоторые компоненты не собирались и требовали правки make-файлов. Жесткого диска не хватало для одновременной сборки всех компонентов, так что весь процесс сборки выглядел так:
  1. Загрузить исходник компонента на сервер через последовательный порт (вы помните, 9600 bps)
  2. Распаковать архив
  3. Собрать
  4. Скачать результат
  5. Удалить
  6. Повторить всё вышеуказанное для пяти остальных компонентов


Один только процесс загрузки кода каждого компонента занимал час. И всё же после длительного бодания мне удалось собрать всё это так, что получившиеся бинарники до бита совпали с теми, что были собраны 20 лет назад и использовались всё это время.

Было ужасно сложно вообще понять зачем мы делаем то, что делаем. Не было никакой документации на этот код, кроме пары листиков с инструкцией по сборке — нам приходилось использовать реверс-инжиниринг буквально на каждом шагу. При передаче кода не было никаких тренингов, семинаров. Да и вообще трудно представить, что спустя 20 лет в компании Z всё ещё работал кто-то, имевший отношение к разработке этого кода в 80-ых. Никто в нашей команде не знал PL/M. От изменения строки кода до сборки бинарника и его запуска уходил минимум 1 час. Отладчика не было вообще. Хотите добавить вывод одного отладочного printf (ну или как там оно в PL/M называлось) — добавляйте и ждите 1 час, пока код соберётся. Эта разработка была просто чистой болью.

Спустя месяц я выразил руководству свои опасения и мне было сказано не волноваться:
-А, так мы вообще и не планируем вносить изменения в этот компилятор, с его помощью собирается относительно мало кода. Вот другой, который мы вскоре получим, более современен и мы сконцентрируемся на нём.
-Что? Я только что месяц кусал себе локти в попытках выучить PL/M и Xenix/286, работая через Kermit-соединение со скоростью 9600 bps, а вы сейчас говорите мне, что это нам не пригодиться?
-Да. Мы просто хотели убедиться, что получили всё, за что заплатили.


Я даже не знал, стоит мне больше сожалеть об убитом зря времени, или радоваться тому, что больше не придётся возиться в этом болоте.

Грустная часть


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

Мы получили исходники второго компилятора. Он тоже не выглядел бодрым молодцем. Собирался он под Visual Studio 6. Ни документации, ни тестов. Отсутствие тестов нам объяснили претензиями на их код со стороны третьей фирмы. Отсутствие документации нам не объяснили никак.

Этот компилятор было легко собрать. Но что мы могли с ним сделать? Я перечитал его код, попытался понять, что делается в каждом файле, сделал несколько экспериментов и написал кое-какие заметки. Затем мы собрали большое совещание с ведущими инженерами всех отделов компании Х, где использовался данный компилятор. Целью было выяснить, что нам необходимо улучшить. Совещание было невероятно демотивирующим. Половина участников придерживались мнения, что лучше ничего не трогать, чтобы не дай бог ничего не сломать. Некоторые были смелее, но и они не могли вспомнить какой-либо важной функциональности, которой им бы нехватало. Затем кто-то пожалел меня и сказал, что текущий компилятор не очень хорошо планирует загрузку сегментных регистров и это бьёт по производительности. Может быть мы могли бы это улучшить?

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

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

Итак, я реализовал дополнительный этап оптимизации для сегментных регистров, и даже получил одобренное ревью кода от авторов компилятора, когда они приезжали к нам из компании Z на тренинг. Оно вроде бы работало, но, как я уже говорил выше, у нас не было набора тестов, а создать такой для компилятора — немалая работа (Отлично! Мы можем предложить это как целый новый проект!).

Мы не могли проверить наши улучшения на настоящем коде, поскольку для этого требовалась та самая «невероятная собственная операционная система» компании Х. Единственным способом получить некоторые замеры производительности и доказательства корректности работы было планирование работы в лаборатории компании Х. Проходили недели и недели в попытках добиться выделения нам одновременно времени в лаборатории и людей из компании Х, которые были нужны для тестов. Это, конечно, понятно — им было по большому счёту всё-равно, выйдет новая версия нашего компилятора или нет, у них были их основные рабочие задачи, не касающиеся этого. Но для нас-то было важно показать, что сделанные нами изменения полезны и корректны. Мы действительно повысили производительность, но без конкретных цифр этого нельзя было доказать.

В этот момент меня, наконец, осенило пониманием того, что никакой реальной работы всё это время у меня не было. Все эти особенные компиляторы станут ненужны, как только компания Х мигрирует с их невероятной собственной ОС, что когда-нибудь да случится. О, конечно, они всё ещё должны будут «поддерживаться» на случай, если вдруг в какой-нибудь программе 20-летней давности обнаружится баг и будет нужен фикс. Но в общем вкладываться в разработку нового функционала при ограниченности оставшегося времени жизни всей этой системы было катастрофически нерентабельно. Компания абсолютно точно потратила на покупку и поддержку этого проекта семизначную сумму (в долларах), но сделала ли она что-то полезное с этим кодом? Нет.

Всё это предполагалось поддерживать вечно, в то время как через 5 лет всё будет заменено на совершенно новые системы. Но ничего не будет выброшено, нет. Всё будет накапливаться и накапливаться, требуя поддержки вечно. И вы будете держать в общем-то неплохих инженеров, способных разрабатывать компиляторы, чтобы делать эту безумную работу, вместо того, чтобы работать на переднем крае науки в высокотехнологичных компаниях.

И как это всё вообще может закончиться? Я представил себя на собеседовании где-то лет через пять, в 2010-ом, пытаясь объяснить потенциальному работодателю, как мои знания Xenix, PL/M и VMS могут быть полезны в разработке его продукта. В жизни инженера может настать период, когда его перестанет тянуть к новым технологиям, но позволить случиться этому с тобой в 20 лет — не самое подходящее время :)

Финал


Я уволился даже без предварительного поиска нового места работы — просто надеялся, что что-нибудь да подвернётся. В подтверждение моей интуиции, после моего заявления об увольнении но ещё до фактического ухода компания ITA Software написала в листе рассылки SBCL, что хотела бы нанять кого-то для работы над улучшением SBCL, что вообще-то выглядело работой моей мечты в то время. Очень удачно всё сложилось.

Вот и всё. В комментариях вы можете рассказать о своём опыте разработки нового ПО на чём-то вроде IBM 1401 прямо сейчас, в 2015-ом году, ну или что-то в таком же духе ;-)
Проголосовать:
+121
Сохранить: