Авторский принцип в программировании

     Технология программирования в области науко-ориентированных приложений с необходимостью должна быть (и есть) интерактивной и итерационной. В современной же теории программирования из абстрактных соображений и с привлечением опыта коллективного создания приложений массового потребления, предложно несколько типовых схем программирования: сверху-вниз (восходящая реализация) и снизу-вверх (нисходящая реализация) с конструктивным, архитектурным и классическим подходами в зависимости от направления обхода мифического дерева несозданной программы. При этом провозглашается, что спецификация структуры этого дерева может быть исчерпывающе определена еще на этапе проектирования и в завершенном виде. Далее предполагается, что и семантика, и формальная структура большинства составляющих модулей также может быть исчерпывающе определена на последующих этапах. После этого становится возможным формальная проверка правильности их семантики и структуры, с последующей автоматической реализацией по принципу формальной генерации машинного кода, требующего минимальной отладки. Своеобразным апофеозом этих теоретических построений стало создание пресловутых CASE-технологий проектирования с неимоверным по сложности методическим и инструментальным программным обеспечением, единственной реальной заслугой которых является обеспечение занятости максимально большего процента населения и пожизненного процветания лидеров этой части населения.
     Программирование. В рассматриваемой же проблемной области упомянутые теоретические построения, к сожалению, неприменимы, прежде всего, из-за принципиального отсутствия возможности содержания массы исполнителей. Процесс создания программной системы и ее отладки начинается с двух противоположенных уровней: верхнего уровня диалоговой архитектуры и нижнего уровня основных базовых примитивов. Далее этот процесс идет на встречных направлениях в проработке структуры и модулей промежуточных уровней до тех пор, пока эти движения не смыкаются. Периодически в этом встречном процессе возникают новые решения, которые приводят к коррекции уже созданных компонентов верхнего, нижнего и промежуточных уровней. Когда программное дерево уже отчетливо выкристаллизовалось, начинается исследование его структуры с выделением функционально близких процедурных ветвей, с их обобщением в форме библиотек самостоятельных инструментальных средств, операционно-диалогово доступных пользователю подобно элементам детского конструктора. Дерево преобразуется в граф - более компактный и взаимосвязанный
     Отладка. Затем начинается процесс общей отладки в направлении отдельных вертикальных ветвей программы, объединяющей в себе неразрывно как комплексную отладку ветви, так и отладку отдельных модулей. При этом следует помнить, что, безусловно, можно заставить интегрированную программу правильно реагировать на осмысленные действия пользователя и на типичные ошибочные действия, но никакая отладка не даст стопроцентную гарантию правильной реакции на все необъятное множество неосмысленных действий пользователя.
Знаменитый мастер компьютерной литературы В.Э.Фигурнов привел в этом плане блестящую аналогию с написанием самой простейшей инструкции о том, как проехать к вашему дому, что только на первый взгляд кажется очень простым делом. Если же подходить к делу тотально и пунктуально, то окажется, что в этой инструкции следует упомянуть необозримое множество возможных вариантов: а как решать задачу, если метро не ходит и в таксе не содят, или клиент слишком пьян или же его по дороге догола раздели грабители, или случилось ДТП, а около дома прокапали канаву или возник круговой оползень, или лифт сломался, а лестница рухнула, или весь город в снежных заносах, а бензоколонки пусты и т.п. и т.д. В правильной инструкции должно быть отражено всё, но что же делать, если такую инструкцию забыли дома или ненароком выбросили, или же читатель не знаком в большинством использованных в ней терминов или не читает по-русски.
    Особенности. Отладка интегрированной программной системы осложняется еще и тем, что число возможных комбинаций использования широчайшего множества ее возможностей в совокупности с разнообразием обрабатываемых данных тотально необозримо. Общепринятая для продукции массового спроса рассылка потребителям-тестировщикам предварительных версий (альфа, бета и т.п.) здесь бессмысленна в связи с крайне ограниченным кругом квалифицированных пользователей, да и они полностью загружены своей собственной профессиональной деятельностью. Поэтому на этапе предэксплуатационной отладки возможно протестировать лишь небольшую часть комбинаторики возможных действий пользователя. Как показывает опыт, эффекты неучтенной комбинаторики с убывающей интенсивностью продолжают проявляться еще несколько лет после начала массовой эксплуатации системы, поскольку большинство пользователей работает с достаточно ограниченным подмножеством инструментария и многие средства долгое время остаются никем не востребованными. Поэтому в данной области крайне важно сохранение преемственности накопленного опыта, поскольку основные вычислительные алгоритмы, составляющие основной объем программных систем, могут оставаться неизменными на протяжении десятилетий, как и лежащие в их основе математические и аналитические методы.
     Отладка в Windows. В современных же операционных средах типа Windows отладка осложняется еще и многими посторонними (демоническими) причинами: существованием множества версий и множества конфигураций ОС, зависимостью ее работы от конкретной комплектации оборудования и от числа и типа загруженных приложений, отсутствием контроля за работой ОС со стороны приложения, недокументированностью многих функций и режимов и пр. Тем самым эти среды представляют собой своеобразные черные ящики, а их появление и развитие выше названо началом эры непознаваемого силиконового разума.
     Повторяемость и регулярность. Рассмотренная технология программирования и отладки устойчиво независима от используемой операционной среды и инструментальных средств, повторяема и регулярна, а, следовательно, и имеет право быть объектом научного исследования. Действительно, при переносе программы из одной среды в другую она воспроизводится в своих основных составляющих, чему свидетельством имеющийся опыт: так система CONAN первоначально была реализована на микро-ЭВМ PDP/11 в языке ассемблер, затем перенесена в среду DOS на уникальном по возможностям интерпретаторе BBCBASIC со встроенным ассемблером, а перенос в среду Windows состоялся на компилирующем языке Object Pascal в оболочке Delphi. То же самое проявилось и в истории статистического пакета STADIA, начавшего свое существование в ассемблере супер-ЭВМ БЭСМ-6, затем и последовательно продолжилось в ОС CPM (для ПК с процессорами Z80 и 6502) и DOS, с переходом в Windows. Этой же технологии следовали в версиях для DOS интегрированный частотный анализатор и контроллер процессов CONAN-t и система психологического тестирования PSYTMAN, а также продукты из многих других областей наукоемкого приложения: система программирования моделей принятия решений человеком ЯРД, модель принятия решений летчиком на этапе приземления, модель принятия решений диспетчером управления воздушным движением, система организации поведенческих экспериментов ЭКСПО (все - для ОС Диспак), система обеспечения когнитивных исследований TVEX с графическим редактором GRASP (ОС RT/11), графический редактор-мультипликатор PEPSY для исследований зрительного восприятия (ОС СР/М).

     Как отмечено выше, в области наукоемких приложений оказывается неприемлемой (распространенная в индустрии ширпотреба) практика привлечения больших творческо-исполнительских коллективов по следующим основных причинам: практически полное отсутствие начального финансирования проекта, крайняя узость круга потенциальных потребителей, определяющая малую рентабельность на этапе реализации готовой продукции, необходимость многолетнего изучения предметной области и компьютеризируемой деятельности. По этим причинам здесь оказывается применим и эффективен старый принцип авторской разработки, когда замысел, детализацию и реализацию проекта осуществляет один человек.
    Исторический обзор. Этот принцип, как известно, был широко распространен в эпоху больших ЭВМ. На этот счет (даже ограничиваясь только минимальным личным опытом) можно привести десятки примеров создания мощных операционных и инструментальных систем силами одного автора: А.И.Волков (автокод и компилятор Мадлен), В.Ф.Тюрин (ОС Диспак — как результат коренной переработки и расширения диспетчера Д-68, созданного Л.Н.Королевым и А.Н.Томилиным), В.М.Михелев (СП Астра), В.П.Пильщиков (СП Пленнер), А.П.Кулаичев (СП ЯРД), П.Наур (транслятор Алгола), Н.Вирт (транслятор Паскаля) и множество других. Многие примеры подобного рода можно было наблюдать и в начале эры персональных компьютеров: Richard Russell (интерпретатор BBCBASIC со встроенным компилятором ассемблера i286), П.Нортон (первые версии NC), Е.М.Веселов (Лексикон для DOS), А.С.Паршин (частотный анализатор FlexLab), И.А.Потапов (частотный анализатор ПОС), А.В.Пироженко (ЭЭГ-анализатор Нейрокартограф). Попробуем разобраться, почему же эта традиция стала угасать в последующем.
    Причины и следствия. Официальная парадигма на этот счет гласит: в современную эпоху сложность и объемность программного обеспечения достигла такого уровня, что его создание находится за рамками возможностей одного человека. Однако многие персональные примеры принципиально противоречит этому популярному мифу. Действительно, способен ли один средненький и презренный человечек удержать в памяти и совершенствовать на протяжении десятилетий целых три программных системы, находящиеся на уровне лучших мировых стандартов. Оказывается — может! И как это часто бывает с официальными мифами, основная причина наблюдаемой индустриализации предельно проста: программное обеспечение в эпоху ПК стало продуктом массового потребления, приносящим колоссальные прибыли.Поэтому в этом процессе быстро выросли и стали доминирующими крупные корпорации с развитой рекламно-рыночной инфраструктурой, творцы же ПО были вытеснены на последние роли и превратились в обычный расходный материал, а многие талантливые одиночки были просто задавлены мощью массовой рекламной пропаганды.
     Для надежного же искоренения контр-поползновений был и придуман вышеуказанный миф. Социально престижным стало карьерное продвижение по руководящим лестницам корпораций, а не каждодневные открытия в программировании и эргономике, поскольку спрос на продукцию определяется совсем не этими открытиями, а мощью, повсеместностью и массовой доходчивостью рекламы. Жесткие условия конкурентного выживания стали определяться только быстротой появления новых версий продукции. Архитектоника программных систем перестала быть предметом научных интересов, что вызвало отток оттуда способных теоретиков, а в условиях бурного развития и быстрой смены поколений вычислительных систем научная мысль перестала успевать за жизнью и замкнулась в архаичных теоретизированиях, пока не создалась ситуация, когда начинающий хакер знает о современном компьютерном мире  неизмеримо больше, чем академик (однако обобщить и доступно изложить свой опыт хакер, к сожалению, не может — нет у него для этого необходимой школы — то есть дисциплины мышления).
     Отличия. Возвращаясь от ретроспективного обзора на почву наукоемких приложений, следует еще раз подчеркнуть принципиальное отличие этой области по следующим четырем позициям:
   а) большие коллективы разработчиков содержать не на что;
   б) продукция заметной прибыли не приносит;
   в) пользователи мало подвержены действию массовой рекламы;
   г) основные реализуемые методы и методики устойчивы на протяжении десятилетий;
   д) вычислительные средства предельно сложны, поэтому для своей реализации они требуют не хакерского, а научного мышления.
     Выводы и доказательства. Тем самым принцип авторской разработки в данной области является не только возможным, но и необходимым, и он показал свою эффективность на серии наших продуктов, занимающих видное место среди своих аналогов на протяжении более десятка лет. Более того, этот принцип показал не только свою сопоставимость, но и заметное преимущество перед методом коллективной разработки. Для подтверждения достаточно взять следующие простые и сопоставимые примеры перевода продукта из среды DOS в среду Windows: для статистического пакета STADIA основной объем работ составил 0.7 человеко-года, для комплексной электрофизиологической лаборатории CONANm — 0.9 человеко-года; для частотного анализатора-контроллера CONANt — 0.3 человеко-года. Среди альтернатив мы не обладали средствами проведения детальных исследований, поэтому можем привести только один известный нам факт: над переводом в Windows популярного и достаточно простого редактора Лексикон в течение 1.5—2 лет работала бригада из 8—12 программистов (оставим для последующих исследователей сопоставление упомянутых продуктов по алгоритмической и вычислительной сложности). При этом следует учитывать, что версии наших произведений в среде DOS создавались с нулевого уровня, включая ассемблерную реализацию диалога и графического вывода, управления памятью, драйверов внешних устройств и целочисленной арифметики вычислительных процедур.
С другой стороны, и объем конечного авторского продукта получается в 5—20 раз меньше по сравнению с индустриальными аналогами, особенно зарубежного производства.
     Таким образом, авторская разработка по сравнению с индустриальной может выигрывать по производительности в 30 и более раз, что достигается за счет:
   1) исключения межличностных коммуникаций, связанных с необходимостью порождения и изучения неисчислимой технологической документации: документы управления разработкой  ПС (process documentation: планы, оценки, расписания; отчеты об использовании ресурсов; стандарты; рабочие документы; заметки и переписка); пользовательская документация ПС (user documentation: общее функциональное описание; руководство по инсталяции; инструкция по применению; справочник по применению; руководство по управлению); документация по сопровождению ПС (system documentation: внешнее описание; описание архитектуры; внешние спецификации каждой программы и каждого модуля; тексты модулей и программ; документы установления достоверности ПС; руководство по сопровождению) и пр;
   2) исключения работ:
       а) по разбиению проекта на независимые составляющие;
       б) по распределению их между исполнителями;
       в) по координации деятельности исполнителей и контролю за их работой;
        г) по комплексной отладке взаимодействия составляющих и пр.
     Следует подчеркнуть, что неимоверный объем сопроводительной документации имеет своей иллюзорной целью обеспечить механическую взаимозаменяемость исполнителей. В противовес этому, существует много примеров того, что полное овладение одним человеком всеми деталями мощного программного комплекса (включая ОС DOS и Windows) требует считанного числа месяцев (1—6) посредством простого чтением десассемблированного кода программы. Но не намного меньше времени требуется и для овладения даже одним модулем программного комплекса новым исполнителем посредством передачи ему всей упомянутой информации. Именно таким изучением текстов программ (а не посещением курсов и не чтением технологической документации) и мы в своей практике овладевали мастерством системной аналитики.