Мы с Олейниковым и умным видом на фоне ЕС-1022.
Судя по тому, что вместо пишущей машинки КОНСУЛ на рабочем месте оператора
уже стоит дисплей - не ранее 1981 года.
Тема АИОС "Дельта" - музыкальная. Вот, сегодня стоило всплыть в памяти слову "Дельта" - и тут же:
Зачем, зачем, сограждане
Зачем я кролик белый?
а также:
А ну, не зевать,
Откопать, закопать!
и, разумеется,
В плане всё отмечено
тоненьким пунктиром
И, конечно:
Эй, ухнем!
Эй, охнем!
Пусть рухнем -
Зато просохнем!
О системе "Дельта" следует рассказывать поверсионно.
"Дельта" начиналась в ноябре 1977 года в общежитии КрасГУ, в комнате Б.В. Олейникова, в ту пору аспиранта. Начиналась она под чудные звуки дискоспектакля "Алиса в стране чудес", только что вышедшего и уже где-то Б.В. раздобытого. По правде говоря, я больше старался расслышать слова дискоспектакля, чем речи Олейникова. И правильно делал - "Алиса" описывала наше будущее куда точнее, чем Олейников. (Кстати, "Алиса, или мужчины в её жизни" в первом, полном варианте, называлось "Алиса и ОС ЕС". В общем-то, это вполне точное описание быта "дельтовцев". Есть и другие произведения о "Дельте", но о них позже.)
На первый взгляд, всё было просто. Когда-то Олейников, будучи ещё математиком соцлаборатории, разработал для ЭВМ "Минск" систему обработки социологических анкет МОНИКА (МакроОбработка Наименованных И Кодированных Анкет). Система позволяла вводить и хранить анкеты, формировать то, что в Excel сейчас называется сводными таблицами, и считать коэффициенты корреляции. В Excel это делается двумя щелчками мышки, а когда-то это было объёмной вычислительной задачей. Будучи лаборантом соцлаборатории, я насчитался этих сводных таблиц и коэффициентов корреляции по самое не могу - и на арифмометре "Феликс", и на "типа ЭВМ" - "Проминь-2".
Моя курсовая работа на четвёртом курсе заключалась в том, чтобы перевести МОНИКу с "Минска" на IBM/360. Я перевёл, написав довольно большую программу на языке ассемблера. Однако отладить её было не на чем - в городе еще не было ни одной IBM-совместимой машины. М-4030 в КФ ВЦ СО АН СССР еще только монтировалась, а первые ЕС-1022 и вовсе только ожидались. Единственным человеком в КрасГУ, который был в состоянии понять, что я понаписал, был Сергей Сергеевич Кислицын. Он понял и одобрил, курсовую мне зачли.
В 1977 году появился заказчик на такого рода систему: "Красноярск-26", а ещё точнее - НПО ПМ. Им надо было обрабатывать данные тестирования надёжности спутников - и в основе лежали те самые сводные таблицы. Но ничего этого мы не знали - даже слова НПО ПМ, и о том, что там делают спутники, не слышали. Ну, то есть, если бы какие шпионы принялись пытать нас калёным железом, мы бы ничего шпионам сказать не смогли. Вот такая секретная была разработка, что мы сами не знали, что делали. На дворе, напомню, стоял 1977 год. В общем, был заключен хоздоговор, срок был положен три месяца (чего там, казалось бы, делать) - и работа пошла. Правда, назвали систему не МОНИКА, а "Дельта" - приняли систему обозначения заказчика, у них там все системы обозначались греческими буквами.
Конечно, моя курсовая для этого категорически не годилась. И функционал "Дельты" был побольше МОНИКи, и мои познания в языке ассемблера увеличились на порядок. Конечно, надо было писать систему с нуля - пригодились разве что некоторые идеи курсовой работы.
Почему именно язык ассемблера? Ну, ясно, что не ФОРТРАН с АЛГОЛом, но почему не PL/1, к примеру? PL/1 или появился чуть позже, или мы его ещё не знали. Да если бы и знали - всё равно писали бы "на ассемблере". Мы были помешаны на эффективности, и не от хорошей жизни. Суперкомпьютер того времени - ЕС-1022 (я не ставлю кавычки, для 1977 года в СССР это, действительно, был суперкомпьютер) имел 128 килобайт оперативной памяти (я не оговорился - именно КИЛОбайт), производительность процессора была 80000 операций в секунду. Остальные машины были ещё хуже. Мастерство программистов того времени заключалось как раз в том, чтобы решить задачу, используя минимум оперативной памяти и времени процессора. А мы собирались строить высокоэффективную систему обработки информации. Так что - ассемблер и только ассемблер.
Мы дооптимизировались до того, что в первой версии Дельты данные упаковывали не с точностью до байта, а с точностью до полубайта - и всё потому, что в некоторых полях заведомо не могло быть значений больше 16. Ни о какой инкапсуляции данных мы не слышали (да тогда и слова-то такого не было), и каждая программа вытаскивала данные самостоятельно - так вот, на этом коде распаковки мы потеряли оперативной памяти куда больше, чем приобрели на упаковке данных.
Ну да ладно, это был не единственный и не самый главный косяк Дельты 1.0. О косяках позже, а сейчас немного пафоса. Как раз в 1977 году появились переводные работы по базам данных. Сейчас, когда СУБД стали естественным инструментом простых юзеров, сам порой диву даёшься - а как же мы жили до СУБД? А вот так и жили, тягали туда-сюда плоские последовательные файлы, а то, что потом назвали запросами, программировали каждый раз "от нуля".
Так вот, мы побежали впереди паровоза. Дельта должна была стать одной из первых советских СУБД. И, кстати, стала в конце концов! Хотя она и была известна в весьма узких кругах, но в этих кругах она пользовалась большим уважением. Но не Дельта 1.0, а гораздо более поздние версии.
Но 1.0... Когда смотришь с сегодняшних позиций на, так сказать, менеджмент разработки, даже не смех берёт, а оторопь. Его не то чтобы не было - он не соответствовал природе разработки. Разработка Дельты считалась научной деятельностью и управлялась как научная деятельность - еженедельными семинарами, на которых Олейников излагал идеи, которые мы должны были реализовывать. Всю остальную неделю разработчики были представлены сами себе и то, что они делали, было современным вариантом басни про лебедя, рака и щуку.
Мы с Олейниковым и умным видом на фоне ЕС-1022.
Судя по тому, что вместо пишущей машинки КОНСУЛ на рабочем месте оператора
уже стоит дисплей - не ранее 1981 года.
По факту управление "day to day" очень скоро перешло ко мне - вопросы возникали гораздо чаще, чем раз в неделю, и кому-то надо было принимать решения. Решения принимал я, как самый опытный (хотя и самый юный). Два участника проекта - Наташа Куминова и Света Трапезникова, были моими подчинёнными в группе программного обеспечения ещё не существующего ВЦ КрасГУ ("Дельту" мы делали на полставки по хозтеме). Четвёртым участником был Саня Пинкин. Я управлял как умел.
Была ещё одна проблема: все программисты, кроме меня, не имели опыта разработки "ненаучных" задач (да, кстати, и язык ассемблера не знали). Разница же между программированием "научных и "асушных" задач - гигантская. Это вообще разные виды деятельности.
"Научные" программы являются лишь приложением к научной работе. Они нужны для проведения расчётов, построения модели. И это разовые программы, хотя могут целиком или частично использоваться повторно. Но главное - получить некие цифры, подтверждающие либо опровергающие некую гипотезу. Структура данных предельно проста: это числа или массивы чисел. Структура программы тоже предельно проста: это всего лишь запрограммированные формулы, с минимальным количеством циклов и развилок. Многие функции уже запрограммированы и находятся в библиотеках подпрограмм. Основные проблемы возникают из-за несовпадения точности измерения реальных данных и точности представления числе в компьютере (отсюда возникла целая ветвь науки под названием вычислительная математика).
Программирование информационных систем - совсем другое. Тут сложные структуры данных и сложные же (особенно при отсутствии библиотек подпрограмм - а они в 1977 году для этого типа задач отсутствовали начисто) алгоритмы обработки. А главное - они, как правило, объёмны и одному человеку не под силу. Вот тут-то и начинается самое интересное. Программа - это единое целое, и программист должен понимать её, иначе он никогда её не отладит. Как только размер программы переходит некий предел, она перестаёт быть понимаемой. Но и разбиение её на части необязательно обеспечивает понимание - особенно если эти части программируют разные люди.
Ах да, скажете вы, а как же объектно-ориентированное программирование, модули, кластеры, инкапсуляция. Так, скажу я, ООП придумают лет через десять после этого! Даже понятие модуля ещё не изобретено. Есть слово "подпрограмма" - но это пока лишь программа, выполняющая часто используемые стандартные функции, которые лень программировать повторно. Скажу вам по секрету, что на тот момент мы еще даже не умели пользоваться библиотеками объектных модулей: каждая программа каждый раз вводилась целиком с перфоркарт ( а это колода в одну-две тысячи карт), целиком транслировалась и компилировалась.
Ну, и на десерт: мы разбили "Дельту" на четыре блока (не будем называть их модулями - они этого не заслуживают) ... думаете почему? Потому, что нас было четверо!
Два блока выделились естественно: одномерные таблицы (Наташа) и двумерные (Света). Естественно - потому что это были "оконечные" программы, они брали данные из БД и сводили их в таблицы.
Сане Пинкину досталась управляющая программа (монитор). Функции её были ещё не очень ясны - ясно было, что она должна была как-то управлять процессом.
Ну, а я взял на себя самый "цимес" - ввод, проверку, хранение и выдачу данных. И, если вы решите, что данные мы таким образом инкапсулировали, то вы сильно ошибаетесь. Остальные программы были вынуждены знать об устройстве практически всё.
Впрочем, вру. Ввод и проверку данных сперва поручили Сане Пинкину. Однако он в срок с задачей не справился, а у меня вся работа встала из-за того, данные ещё не вводились. Так что я у него эту задачу отобрал и быстро сделал хотя бы ввод, без проверки.
У понимающих людей уже волосы становятся дыбом от такого подхода, но добавлю ещё одну деталь (только сядьте сперва, если стоите): у первой версии системы Дельта отсутствовала проектная документация. Начисто.
Ну, то есть, было конечно, описание проекта как приложение к договору. Но, во-первых, мы его не видели, поскольку договор вместе с приложением был секретным, а допуск имел только Олейников. Во-вторых, там описывались только внешние характеристики системы - то, что называется эскизным проектом. Внутреннее же устройство разрабатывалось на еженедельных семинарах - но не оформлялось документом. Каждый, как умел, вёл конспекты, которые не всегда отражали окончательное решение. А бывали, кто-то отсутствовал на семинарах - и не узнавал об этих решениях никогда.
Впрочем, насчёт "никогда" я загнул. Конечно же, когда каждый отладил свои программы поодиночке и мы начали совместную отладку, все эти косяки повылезали. Повылезали - это мягко сказано. Программы катастрофически не понимали друг друга. Они по-разному интерпретировали данные, они по-разному понимали алгоритмы их обработки. Только в следующей версии мы выделили модули доступа к данным - и резко упростили логику программ, а заодно сильно уменьшили их размеры. Но это будет потом, а пока мы в мыле переотлаживали уже, кажется, отлаженные программы - кроме одной: монитора. Её Саня в срок не отладил. По правде говоря, он её по большей части и не написал. Как можно было так умудриться - только по студенческой привычке откладывать всё на последний день. Но мы-то пахали как угорелые! Мы не пошли в отпуск, мы ночи проводили в ВЦ (своего у нас ещё не было, а ГлавкКрасноярскстрой сдавал нам свою ЕС-ку в аренду только ночью). И мы (а точнее - я) наказали Саню по коммунистически: отстранили его от работы. На работу ходи, деньги получай - это твои проблемы. Но работу мы тебе не доверяем.
Монитор я написал очень быстро. Функции его уже были понятны, рука набита - и то, что Саня мучил полгода, я сделал за несколько дней. Кое-что не стал делать вообще - и к лучшему. В общем, получилось что-то вроде обработчика несложного языка управления заданиями, как в ДОС ЕС.
То, что планировали сделать к лету, мы не сделали и к концу года. Не была система готова и к 1 февраля. Что-то работоспособное получилось только в марте.
Могло быть и хуже - если бы модули были связаны друг с другом сильнее. Но два из четырёх модулей были оконечными, да, и, по правде говоря, на самом деле это должен был быть один модуль. Две третьих кода у Наташи и Светы делали, по сути, одно и то же - ведь одномерная таблица есть частный случай двумерной.
Итак, мы получили бесценный опыт того, как не надо разрабатывать программы - и я потом приводил его как идеальный пример, на лекциях по технологии программирования: Спецкурс "Культура программирования". Лекция первая Почему спецкурс называется именно так
Первый вариант "Дельты" был настолько неудовлетворителен, что мы решили переписать её "от нуля", по крайней мере я. Света с Наташей на столь радикальный шаг не пошли (как женщинам и положено), хотя существенно улучшили свои программы во второй версии - в основном за счёт того, что код работы с БД "ушёл" в универсальные модули, которые я написал, и которыми пользовались все без исключения программы. Так мы инкапсулировали нашу базу (хотя слово такое было ещё нам неизвестно) - и наперёд решили множество проблем: теперь обрабатывающие программы занимались только обработкой, ничего не зная о том, как устроена база данных.
Во второй версии была и проектная документация. Структуру документов мы разработали сами - ведь ГОСТ ЕСПД ещё, кажется, не было - или же они только что появилсь, и мы о них не знали. Переводные книги, описывающие внешние и внутренние спецификации, не только не были переведены, но, кажется, ещё и не написаны. Пока не появилась книга Ганта о программной инженерии, мы и слов-то таких (спецификации) не знали.
Сильно пригодилось мне знакомство с техпроектами АСУ в Томске - хотя не всё годилось для наших реалий. Подозреваю, что наши заказчики в НПО ПМ были куда продвинутее по этой части, однако поделиться с нами этими знаниями не могли, потому что вся документация у них была, разумеется, секретной. Как я потом выяснил, в "военке" управление проектами всё-таки было поставлено для того времени очень даже неплохо - да, кстати, и ГОСТ ЕСПД разрабатывался в первую очередь для военных и в значительной степени военными же.
Думаю, что, если бы мы были по образованию не математиками, а инженерами, мы бы наломали куда меньше дров - просто потому, что человек, которого пять лет учили инженерному подходу, будет пользоваться именно этим подходом, а значит, начнет работу с эскизного проекта, напишет техзадание, определённым образом организует процесс, - чтобы он ни проектировал: узел машины или программную систему. Именно в этом заключается суть образования - в подходе, в культуре, а не только в конкретных познаниях. Так же как математик "на автомате", прежде чем решать задачу, исследует её на корректность, непротиворечивость и т.п. Так же как профессиональный историк автоматически не выходит "за красные флажки", работая с документом. Последний пример раскрою подробнее. Мы работали над проектом "Возвращённые имена" - единой базой данных о всех репрессированных в СССР. Просматривая тестовую базу данных, я обнаружил запись о человеке из Красноярского края. Название района было переврано, и я тут же полез его исправлять. Рядом сидели два доктора исторических наук, они буквально схватили меня за руки и оторвали от клавиатуры. Для них это было всё равно, как я бы сунулся в храм в шортах и сланцах. Оказывается, в таких случаях максимум, что я могу - прокомментировать и дать свой вариант написания. И это то, чему историка не просто учат - это в нём воспитывают. Ему в голову не придёт править документ, сколько бы сомнений он не вызывал. В общем, каждая профессия закладывает в человека свой способ решения задач.
А мы шли своим путём, и надо было очень сильно поломать понимание своей работы, чтобы поставить документацию перед программированием, а не наоборот. Однако, замечу, что разработанный нами стандарт документации содержательно оказался не очень далёк от будущих ГОСТ ЕСПД, разве что оформление было более вольным.
Собственно говоря, мы сделали вот что: описание системы из финального отчёта (сделанное постфактум) заложили в основание следующей системы. То есть, если раньше мы сначала делали систему, а потом её описывали, то теперь мы её сначала подробно описывали, а только потом принимались делать. С сегодняшней точки зрения, это единственный и естественный путь, однако нам пришлось идти к этому через кровавый пот первой версии - а виной тому был пресловутый научный подход, когда "писанина" делается при оформлении результатов работы, а не лежит в её основе.
Вот этот документ был доступен теперь всем участникам процесса (лежал на видном месте), все поправки в задании документировались тоже и тоже были доступны. Написал эту фразу и подумал: ведь нынешние программисты поймут её так: файл с документацией лежит в папке проекта на видном месте, и все разработчики видят этот файл по сети. Как бы не так! Проектная документация печаталась на обыкновенной пишущей машинке, а на видном месте лежала бумажная папка. Латинские буквы вставлялись от руки. Почему? Да потому, что тогдашние ЭВМ не шибко-то были предназначены для обработки текстов. Они были предназначены для работы с программами, с пакетными заданиями, какими-то данными, представляющими из себя отдельные СТРОКИ (строка соответствовала перфокарте). То есть, вводить и особенно править ТЕКСТЫ (не программы, а именно текстовые документы) там было очень затруднительно. Представьте себе - вам нужно вставить слово - но тогда строка не влезает на перфокарту. А значит, надо перебить все перфокарты до конца абзаца. Если к этому добавить то, что доступ к перфораторам был затруднён (у нас стояло три перфоратора на пятьсот пользователей, и один-два перфоратора, как правило, не работали)...
Ещё одна забавная деталь: у тогдашних ЭВМ отсутствовали строчные буквы. То есть, в кодировке-то они были, но в перфораторах и АЦПУ они не были предусмотрены (АЦПУ, например, работало так: там было 128 цепей, на каждой - металлически отлитые литеры - только прописные. Строка печаталась так: каждая из цепей подвигалась к нужной литере, после чего 128 молоточков ударяли, и строка отпечатывалась на бумаге через широкую, формата А3, ленту, пропитанную краской. Отдельная песня - как эта лента изнашивалась, рвалась, заминала бумагу...)
В общем, до тех пор, пока не появились дисплеи - даже плохонькие и малодоступные, проще было напечатать (и даже перепечатать) документацию на пишущей машинке - при наличии рядом довольно мощной по тем временам ЭВМ. Но, начиная с версии 3.0, документация стала храниться в библиотеке проекта, и любой разработчик мог распечатать себе самую свежую версию. Если бы дисплеи стояли на каждом рабочем месте, то можно было бы документацию не печатать, но до такой жизни было ещё очень далеко - я, например, готовил и корректировал документацию ночью или в выходные - в остальное время к дисплеям было не пробиться.
Второй революционной технологией было структурное программирование. Как раз в это время появились статьи и книги на эту тему: Дейкстра, Вирт. Я поразился - насколько коряво и неправильно мы писали систему: громадными кирпичами по полторы-две тысячи строк. Из нашего "научного" прошлого осталось понимание подпрограммы как некого кода, выполняющего часто используемые функции. Но можно (и нужно!) было делить программу на модули согласно функционалу и иерархии, а не по частоте использования.
Я уже не говорю о логике программ - отказе от GO TO и переходе к структурным конструкциям DO WHILE, REPEAT UNTIL, IF THEN ELSE. Математическое доказательство того, что любой любой алгоритм может быть описать всего этими тремя конструкциями было бомбой! И до того было видно, что конструкции эти удобны и просты - но они оказались ещё и универсальными! Стало быть, надо бесповоротно на них перейти.
По правде говоря, можно писать структурно и с GO TO, если его грамотно и ограниченно использовать, а можно писать неструктурно и без GO TO - ведь структурное программирование, помимо отказа от GO TO, предполагает ещё и методологию разработки "сверху вниз", инкапсуляцию данных и многое другое.
Но, всё-таки, писать структурно на языке ассемблере было неудобно. И я разработал макроязык АС (ассемблер структурированный), т.е. макрокоманды ассемблера, моделирующие структурные конструкции. Это было сильное решение - язык ассемблера фактически превращался в язык высокого уровня, сохраняя при этом экономность кода.
Вот тут можно почитать мою статью об АС: Макроязык АС - средство создания информационных систем
А тут - описание языка: Макроязык АС. Руководство пользователя
Язык АС отрабатывался в процессе написания ДЕЛЬТА 2.0. Новые модули я писал уже на нём, в старых - только новые куски.
Мне удалось убедить Свету и Наташу перейти на АС. Но они писали на АС только новые куски - трогать старый код они не рискнули. Но для всех вновь прибывающих программистов АС уже был стандартом.
В 1979 году мы, наконец, сдали вполне работоспособную версию, которая поступила в эксплуатацию, и заказчик был ею вполне доволен.
Однако мне предстояло ещё раз переписать всю свою часть ДЕЛЬТЫ.
Настоящий художник никогда не удовлетворён своим творением. И в очередной версии я переписал все свои модули, да и модули перекроил по-другому, хотя система работала нормально и заказчик о переделке не просил. Но меня категорически не устраивало внутреннее устройство ДЕЛЬТЫ.
Подойдя к построению системы "сверху вниз", я обнаружил, что функции многих модулей были определены неправильно. Основополагающая книга Майерса "Надёжность программного обеспечения", которая вводила понятие прочности модуля, ещё только печаталась в издательстве "Мир", но уже какие-то представления о том, что такое хороший модуль, а какой плохой - были. И я плохие модули безжалостно переделывал, а хорошие - просто переписывал на АСе.
Громадные плохо понимаемые "кирпичи" программ распадались на небольшие прозрачные модули (а, кстати, только за счёт применения АС "видимый" объём программы уменьшался в три-четыре раза. Кроме того, когда я "упаковал" знание о структуре данных в отдельные модули (я это делал интуитивно - слово "инкапсуляция" мы ещё не знали), - мало того, что объём программы уменьшился, так ещё и уменьшилось количество ошибок: теперь я мог менять структуру данных как хотел - остальные программы не надо было переделывать. Забегая вперёд, скажу: уже в следующей версии, в системе ТАБЛ, данные были так инкапсулированы, что остальные программисты даже не заметили, что основная управляющая таблица, перестав входить в оперативную память, переместилась на жёсткий диск. Ну, сейчас вы вправе сказать: "ну и что?", а для восьмидесятого года это была революция.
Саня Пинкин оставался на проекте ещё некоторое время, делал оконечные модули, поучаствовал в разработке системы TABL в качестве редактора, но потом уволился. Наверное, это было следствием моего жёсткого и даже жестокого решения, но когда речь шла о деле, я не жалел никого - ни друзей, ни родных. Отношение к делу для меня стоит где-то в том же ряду, что совесть и порядочность. Через много лет, уже в бизнесе, не раз и не два выгонял я с работы людей в целом неплохих, но видевших в работе лишь тяжкую необходимость, а не возможность самореализации. Саня был первой жертвой на этом пути. Сейчас я понимаю, что он был по жизни спринтером, а не стайером. Он легко загорался, хорошо фантазировал, быстро и изящно решал небольшие задачи. Он увлекался всякой всячиной: то разрабатывал теорию выигрыша в "Спортлото", то практиковал модную йогу, то что-нибудь ещё. Но надолго его не хватало. И на длинной дистанции его "подводила дыхалка". С энтузиазмом начатая работа переставала его интересовать, а потом и вовсе становилась ненавистной. А уж способов не делать ненавистную работу человек может изобрести сколько угодно. Может быть, правильнее было его использовать в качестве "инструментальщика", работа которого, действительно сводится к написанию коротких эффективных вспомогательных программ - но на тот момент такой должности на "Дельте" не было.
Я же любил и люблю задачи стайерские, многолетние, с большим объёмом перерабатываемой информации. Такой была "Дельта", такой была I-System, а потом - сайты stolby.ru и memorial.krsk.ru - уже больше десяти лет работы, тысяч опубликованных материалов. В спринтерских забегах у меня результаты невысоки: так, на конкурсах программистов я пару раз входил в десятку лучших, но призовых мест не занимал никогда.
Начиная с версии 2.1, пошли версии 2.2, 2.3. В основном разрасталась "обрабатывающая" часть - писались программы из области матстатистики. И команда разрасталась: пришёл из "Главкрасноярскстроля" Саня Качаев, Лида Рогозина, писавшая что-то матстатистическое на хозтеме ещё до нашего появления, Надя Андреева. Две моих бывших студентки, Тоня Баус и Галя Толмачёва, занялись доведением "Дельты" до окончательно реляционного вида, реализовав SQL-запросы. В 1984 году в команду влились Оля Воронина, Гена Ульянов, в 1985 - Галя Семенова и Лида Беккер.
Команда начала восьмидесятых. Далеко не вся.
Управлять такой командой даже при наличии проектной документации было очень сложно. Я уже, по сути, и не программировал - у меня все силы уходили на коммуникации. И, как всегда, вовремя попалась книга Брукса "Мифический человеко-месяц". По-русски она называлась как-то иначе - представьте себе в СССР книгу с таким названием! В книге фантастически точно излагались наши проблемы и предлагалось апробированное решение - хирургическая бригада. Суть её в том, что программу, по сути, пишет один человек, а остальные ему ассистируют.
Выделяется, например, отдельный тестировщик. Он ничего не пишет кроме тестовых заданий. Его задача - обнаружить все ошибки. Причём он начинает работать ещё с проектной документации: он ищет в ней нестыковки, лакуны. И это очень ценно - чем раньше обнаружена ошибка, тем проще её поправить.
Выделяется "второй пилот" - человек, который знает систему так же хорошо, как "хирург" и при случае может его заменить. Очень ценна его роль как "тени хирурга". Если тестировщик подвергает испытаниям коды и проектную документацию, то "второй пилот" критикует решения "хирурга" прямо в процессе их формирования. Собственно говоря, они их вместе и вырабатывают: "хирург" выдаёт решение, "второй пилот" разбивает его в пух и прах. Если "второй пилот" не нашёл к чему прикопаться, решение принимается. Если нашёл - "хирург" либо отбрасывает решение, либо доводит его до безукоризненного состояния.
Остальные роли менее значимы. "Редактор" - человек, отвечающий за документацию. Он снимает с "хирурга" техническую работу по внутренней документации и полностью пишет внешнюю. "Негры" - младшие программисты, которые снимают с "хирурга" оргтехнические проблемы - между прочим, при работе в пакетном режиме это требует достаточно много времени: набивать перфокарты, забирать распечатки, ликвидировать мелкие проблемы типа замятой перфокарты. Они же исправляют мелкие ошибки, описки, пишут мелкие оконечные модули.
Я жаждал опробовать эту технологию, но в условиях социализма это было не так просто. Как увязать фиксированные ставки с.н.с. и м.н.с с конкретной оплатой по факту - например, тестировщик в западной модели получал деньги за каждую найденную ошибку. "Хирург" в западной модели получал в разы больше "негров". Эти проблемы мы в конечном счёте решили - для меня как "хирурга" важна была не оплата, а эксперимент. Тестировщику мы поставили условие: он получает премию только в том случае, если заказчик не найдёт в сданной системе неизвестные нам ошибки (так оно, кстати, и получилось - тестировщик получил свою честно заработанную премию).
Для чистоты эксперимента нужна была чистая, с нуля, "ненадёванная" задача. "Дельта", многократно писанная-переписанная, для этого не годилась. "Оконечные" статистические задачи были тем более неинтересны - это были в чистом виде научные задачи, там нужно было всего лишь аккуратно запрограммировать формулы.
И случай представился. Не было бы счастья, да несчастье помогло. Заказчику нужны были отчёты специальной формы из нашей СУБД. Написать их было бы нетрудно, если бы не одно но: формы были секретными, не только по содержанию, но и по форме. А мы допуска по-прежнему не имели. Да даже если бы и имели, эти формы не могли распечатываться в нашем ВЦ - мало ли какой шпион вытащит их из АЦПУ!
Ситуация была абсолютно сказочная: пойди туда, не знаю куда, принеси то, не знаю что. Нам надо было научиться печатать отчёты, не только содержимое которых, но и форму нам знать не полагалось.
И мы сделали это! Мы придумали то, что потом назовут генераторами отчётов. Но, замечу сразу, наш генератор ни в какое сравнение не идёт даже с современными генераторами отчётов. Они представляют собой вертикальные таблицы, формируемые в результате запросов. А наш генератор позволял построить таблицу произвольной сложности и размера. Единственное ограничение: таблицы не могли пересекаться, но могли вкладываться друг в друга на произвольную глубину.
Саня Качаев тряхнул алгебраической стариной, построил алгебру таблиц и доказал, что путём последовательных вложений мы можем построить любую произвольно сложную таблицу. Он разработал также язык описания таблиц, описал его, как полагается, в нотациях Бэкуса. Вот тут пригодилось математическое образование - инженеру вряд ли всё это пришло бы в голову. (См. Генерирование произвольных табличных форм в системе ДЕЛЬТА )
Совершив этот подвиг, мы незамедлительно принялись за следующий - убедили руководство работать методом хирургической бригады. Руководство согласилось: мы не требовали изменения схем оплаты, и до сих пор мои новации шли на пользу делу. Я, разумеется, стал "хирургом", Саня Качаев - "вторым пилотом", Надя Андреева - тестировщиком, Тоня и Галя - "неграми", а Саня Пинкин - редактором (но до конца задачу не выполнил, как раз в это время уволившись - и документацию, как уже повелось, писал я, но на этот раз у меня было намного больше свободного времени).
Понятно, что использовались в разработке все наработанные схемы: структурное программирование, инкапсуляция данных. Мы не допускали применения модулей прочности ниже функциональной, коммуникационной и информационной, а сцепление модулей допускали только по данным (книга Майерса к тому времени уже была не только прочитана, но и зачитана до дыр). Документация не только сопровождала разработку на всех этапах, но на всех же этапах и тестировалась независимым тестировщиком - ещё до того, как по этой документации писался какой-либо код.
Результат был ошеломительным: мы сдали программу на месяц раньше срока. Заказчик за время эксплуатации обнаружил всего одну ошибку - но мы о ней уже не только знали, но успели исправить - и в тот же момент передали ему ленту с исправленной версией.
Представляю, чтобы было, если бы ошибок было больше и какими эвфемизмами изъяснялся бы заказчик, пытаясь сообщить нам, что именно не идёт - ведь распечатки он нам показать не мог, и не мог даже сообщить, на какой таблице вылезла ошибка - ведь форма была засекречена!
Конечно, не всё шло гладко: Надя долго брыкалась и не хотела становиться тестировщиком - одно дело быть творцом-программистом, и совсем другое - проверять чужой труд. Тоню с Галей тоже не не устраивала роль девочек на побегушках. Однако потом они признались, что лучшей учёбы, чем работать "изнутри" с хорошей, правильно написанной программой - нет. Когда на следующий год они разрабатывали программы самостоятельно, то применяли наработанные приёмы на практике - и, кстати, из них получились очень даже хорошие программисты.
Саня Качаев сразу оказался на месте: мало того, что он подвергал испытанию на прочность мои идеи (а его хлебом не корми, дай покритиковать), но в следующей версии системы TABL удачно подменил меня, когда я строил квартиру "самостроем" и полгода практически не появлялся на работе. Кстати, когда мы сдали первую версию на месяц раньше, то нас с Саней, помимо "денежной" премии, наградили командировкой в любой город СССР на неделю в декабре. Мы выбрали Ленинград и провели время очень неплохо - собственно, об этом рассказ "Гуд бай и в небо". Там я почти ничего не наврал - разве что происходило это не в 1984 году, а в 1982-м, швейную машину я купил не в Ленинграде, а в Киеве, а портфель с мясом Саня Качаев довёз-таки до Красноярска (но закапывал несколько раз, это святая правда!).
В общем, опыт был исключительно удачным. Кажется, это был не только первый, но и единственный опыт применения метода "хирургической бригады" в СССР (см. О "Хирургической бригаде"). Во всяком случае, когда в впоследствии попал в тусовку людей, отвечающих за технологию программирования в СЭВ, эти люди (преимущественно из "ящиков") признались, что даже не предполагали, что такое возможно в нашей стране.
В следующей версии системы TABL (1983 год) мы пошли ещё дальше. Собственно говоря, идея эта существовала с самого начала, но мы еже понимали важность поверсионной разработки и оставили её реализацию на следующий год. Первая версия TABL решала задачу построения произвольных табличных форм - и решала её успешно. Однако данные в клетках имели простейшую структуру - по сути, это были либо одиночные данные, либо одномерные или двумерные таблицы. Однако мы замахнулись на большее: раз пошла такая пьянка, почему бы не устроить функциональные взаимосвязи между данными из БД и подтаблицами, и - внимание - подтаблиц между собой.
Вам это ничего не напоминает? Если да, то это именно оно. По сути дела, мы в 1983 году реализовали электронную таблицу. Вся беда была в том, что работала она в пакетном режиме: в СССР тогда не было никаких персональных компьютеров (первые ДВК ещё только начали выпускаться), а первый дисплейный комплекс на нашей ЕС-ке появился в том же 1983 году, когда TABL 2.0 уже была практически завершена. Да и эти дисплеи были скорее заменителем перфораторов: на них можно было в диалоговом режиме готовить и запускать пакетные задания, но до полноценного диалога на этих построчных "дисплеях" в 24 строки по 80 символов было ещё очень далеко.
Когда лет через пять мне показали электронную таблицу на"Ямахе" - как новое слово в персональных вычислениях, я долго хлопал себя по бёдрам: да это же наш TABL,только без базы данных и диалоговый! Как знать если бы СССР отставал от Запада не на десять лет по вычислительной технике, родоначальниками электронных таблиц стали бы простые сибирские ребята, которым сказали пойти туда, не зная куда, и принести то, не знаю что. Всё, чего нам не хватило - это соответствующей техники и, как следствие, сформировавшегося диалогового мышления. А мы, конечно, мыслили тогда пакетно, перфокартами...
Впрочем, идеи и озарения - это одно, а продвижение - это совсем другое. Что толку, что "Дельта" была одной из первых СУБД в СССР (и, кажется, единственной "самописаной", а не "передраной" с западных аналогов). Стандартом на ЕС стали совсем другие СУБД. Что толку, что мы создали совершенный и универсальный генератор отчётов? Дальше наших заказчиков (а мы продали "Дельту" с TABL не только Красноярску-26, но и нескольким ещё таким же "ящикам" - из них помню почему-то только омский "Полёт") да докладов на краевых конференциях этот генератор не пошёл. Даже если бы мы в тех условиях и создали электронную таблицу, она бы ушла так же - по нескольким "ящикам". Тем более, что рынка программного обеспечения в стране не было. Вспомните: планирование на пятилетку, фонды, и т.п. В таких условиях только военные могли себе позволить приобрести нужное ПО достаточно быстро.
Проблема, однако, не только в закрытости и отсталости техники. Дело, может быть, в психологии. Мне всегда было интересно решить задачу, но после решения она мне становилась неинтересна. Масштаб совершённого нами в TABL я вообще осознал много лет спустя.
Так было не единожды. У нас ещё в 2000 году был шанс стать родоначальниками web 2.0: то, что через пять лет назвали тэгами, мы использовали в полном масштабе в сайте "Красноярские Столбы". Это был вполне осознанный шаг, и я написал об этом статью: Гипертекст умер. Да здравствует гипертекст! Были там и ещё идеи: "библиотеки смыслов" (что-то подобное делает сейчас Яндекс (толкование слова через Яндекс-словари), было формирование статей по теме из цитат со ссылками на исходные материалы ( в первоначальном виде планировалось то, что потом назвали википедией - но я отринул эту идею, поскольку не верил и не верю в коллективный виртуальный разум, и оставил формирование статей в одних руках - своих). Ну вот, мы это сделали, и сделали первыми, а продвинуть дальше, упаковать в продаваемый продукт, сделать ему рекламу - на это нас уже не хватило... Ну, точнее, мне это было уже неинтересно (задача решена!), а больше двигать это было некому - мой компаньон увлёкся в это время САПР и все его помыслы были там.
Меньше всего хотелось бы, чтобы три последних абзаца воспринимались как плач несправедливо обиженного первопроходца. До лавров мне дела мало. Да и, кстати, знаете ли вы фамилию разработчика первой электронной таблицы? И я не помню (хотя знал). Даже имя изобретателя интернета мало кому известно (и я его вспоминаю с трудом что-то там Ли... Бер... Берджес? Берлис?)
Идеи носятся в воздухе. Весь вопрос в том, сумеешь ли их уловить и реализовать. Оглядываясь назад, вижу, что наши идеи и проекты были очень даже на уровне - не только отечественном. Иногда мы забегали вперед мирового паровоза. Ну, значит, как профессионалы мы состоялись. Хотя... вот, скажем, Apple была первопроходцем, а стандарт - всё-таки Windows. Вот кому должно быть обидно - Джобсу!
Вот об этой версии мне рассказать практически нечего. TABL был моей последней вершиной как разработчика, дальше в "Дельте" была просто рутина, просто работа. Всё шло по накатанному пути, мы научились работать и работали. Проектная документация уже не печаталась на машинке - она вводилась в системе ДУВЗ, распечатывалась на АЦПУ. Кардинальных переделок уже не было - система просто разрасталась. И это уже было просто скучно, что видно даже по этому произведению: ЮБИЛЕЙНАЯ РЕЧЬ (по случаю 6-летия системы ДЕЛЬТА). Я уже практически не программировал - только писал документацию и управлял коллективом разработчиков. И это мне сильно не нравилось - по натуре я всё-таки одиночка и заточен на творческую работу.
К тому времени я сильно ушёл в теорию технологии программирования (о чём подробнее - в следующей главе). К тому времени в СССР появились мини-ЭВМ и "персоналки" (если таковым можно назвать ДВК-2) и технология персональных вычислений. К тому времени я стал работать с командой из ИК АН УССР настолько плотно, что подумывал о переезде в Киев насовсем. "Дельта" перестала меня интересовать как объект применения этих технологий.
К тому же искания смысла жизни (о чём будет отдельная печальная глава) лишили меня уверенности, что в программировании вообще есть смысл. Были и другие причины круто поменять жизнь, в том числе и личные. Всё это вместе, как я потом узнал, называется КСВ: кризис среднего возраста. И, когда я осенью 1986 года случайно в овощном магазине встретился с директором только что открывшегося КФ ВНИИ ПС Карповым, то на его шутливый вопрос: "когда к нам перейдёшь" - ответил без шуток и колебаний: "завтра". Карпов обалдел. И все обалдели назавтра, когда я написал заявление. Ну, завтра не получилось - надо было сдать дела, на что ушла пара месяцев. Но в конце декабря я уже работал на новом месте и занимался совсем другими вещами.
Продолжение: Программирование как деятельность
© Алексей Бабий 1998-2009