Софтпанорама, No.2, 1990                Составитель Н.Н. Безруков
*****************************************************************

                                        Л. Г. Б У Н И Ч

                                       Москва  591-93-09



     К У Л Ь Т У Р А   П Р О Г Р А М М И Р О В А Н И Я
     _________________________________________________

            С О Ц И А Л Ь Н Ы Е   А С П Е К Т Ы
            ___________________________________


           Доклад на научно-техническом семинаре
         "Методы и средства программной инженерии"


             Москва, МДНТП, 10-11 февраля 1987 г.




                        В В Е Д Е Н И Е
                        _______________

   Будем понимать под культурой программирования совокупность  правил,
которые непосредственно способствуют  повышению качества программ  или
производительности  труда  программистов.   Я  намеренно  поставил  на
первое  место  качество  программ,  а  не  производительность   труда,
поскольку  страдаем  мы  не  от  недостатка  программ,  а скорее от их
плохого качества.  Основная цель моего выступления - анализ  некоторых
факторов,  которые  помогают  или  мешают  созданию высококачественных
программ.

   О том, как оценивать  качество программ, есть самые  разные мнения.
Я ограничусь  чисто потребительским,  экспертным критерием:  программа
считается  хорошей,  если  ее  высоко оценивает конечный пользователь.
Этот критерий ставит во главу угла такие характеристики программы, как
функциональное богатство, надежность, технологичность работы, удобство
управления и т.п.

   Большинство руководств по технологии программирования ориентированы
на то, чтобы привить  программистам навыки, которые можно  по аналогии
назвать  внутренней   культурой:    умение  сформулировать   алгоритм,
спроектировать модульную программу, закодировать ее в рамках некоторой
дисциплины, отладить  и документировать.  Нельзя, однако,  упускать из
виду, что  программа представляет  собой не  столько конечный продукт,
сколько  инструмент  для  решения  поставленных  задач,  и  в процессе
решения  будет  участвовать  множество  людей:   операторы  подготовки
данных,  инженеры,  операторы   ЭВМ,  заказчики,  сами   программисты,
администрация и другие.  Фактически работает не программа, а комплекс:
персонал + программа.

   Представьте себе программу, безукоризненно выполненную и удовлетво-
ряющую самым высоким требованиям структурного программирования: четкая
модульность, ни одного GO TO,  самодокументированность и т.п.  В то же
время  любая  ошибка  в  ее  исходных данных вызывает невразумительное
сообщение типа  "ABEND 0C1",  причем база  данных необратимо портится.
Работает эта программа только в ОС MVT 6.1. Типовые процедуры  состоят
из 30-40 шагов задания.  На консоль выдается более  десятка сообщений,
требующих ответа, и упаси бог оператора ответить неверно.  На  просьбы
о доработке авторы отвечают, что им некогда - заняты другой задачей, а
за  ошибки  в  данных  наказывайте  перфораторщиц, пускай работают без
ошибок.

   Полагаю, что мало кто захочет работать с такой программой.

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

   Регуливанию поддаются три системы взаимоотношений:

   (1) разработчиков и их программ;
   (2) программ и предприятий;
   (3) предприятий и разработчиков.

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

   Основная  цель  социальной  культуры  программирования - достижение
достаточно гармоничных отношений человека и компьютера.

   В самом общем виде можно сформулировать два важнейших принципа.

   1.  Поскольку  программа  работает  в  конкретной  человеческой   и
производственной  среде,  она  должна  быть  максимально к ней приспо-
соблена.  Подчеркнем,  что  не  человек  должен  приспосабливаться   к
программе, а программа к человеку.

   2.  Социально-производственная  обстановка  должна  прямо  поощрять
создание программ высокого качества.

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

   Содержательное   исследование   вопроса   предпринял  ленинградский
программист Е.В.Лишак. Его эссе на эту тему, к сожалению,  неопублико-
ванное, называется: "записки парасистемного программиста".

   Я попытаюсь, исходя из собственного опыта, сформулировать некоторые
технологические законы, которые,  конечно, не являются  новыми, многие
хорошие программисты  их более  или менее  осмысленно применяют. Важны
две вещи: чтобы  эти законы попали  в учебники и  чтобы они фактически
исполнялись.



          Принципы социальной культуры программирования
          _____________________________________________


   Ж и в у ч е с т ь.

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

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

   Пример: уплотнение библиотеки ОС  ЕС с помощью утилиты  IEBCOPY или
автоматическое (ДУВЗ). Первый же  сбой диска означает почти  наверняка
порчу библиотеки, причем  пользователь получает бодрое,  но малоутеши-
тельное извещение о том, что оглавление библиотеки не соответствует ее
содержимому.


   Т е р п и м о с т ь.

   Программа,  которая  умеет  работать  только  с  хорошими данными -
плохая программа.  Мы не  можем программным  путем повлиять  на работу
аппаратуры,  но  управлять  работой  пользователя  мы  можем и должны.
Человек  не  в  состоянии  работать  безошибочно,  и  рано  или поздно
программа получит  данные, содержащие  ошибку. В  наших силах  сделать
так, чтобы результатом было не сообщение  "Data exсерtiоn on statement
...", а что-нибудь  вроде: "ошибка в  записи 4, графа  5: не цифра"  и
затем распечатка отвергнутой записи.

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

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

   (плохой)   Dividе chеск ехсерtiоn; ABEND U0240
   (хороший)  Для этого завода  еще не  утверждено штатное расписание;
              число работников равно нулю.

   Великолепный пример терпимости,  достойный всяческого подражания  -
отладчик ПЛ/1 ОС ЕС. Он не только диагностирует ошибки, но и  пытается
самостоятельно   исправить   наиболее   очевидные   из  них, например,
пропуск буквы в достаточно длинном ключевом слове.


   М о б и л ь н о с т ь.

   Казалось бы, эта проблема не  должна нас заботить: мы имеем  единую
систему больших  ЭВМ и  единую систему  малых ЭВМ,  так что  трудности
могут возникнуть лишь при переносе  программы с ЕС на СМ  или обратно.
И тем не менее проблема не только существует, но и обостряется.

   Причин здесь  несколько. Первая  из них  - недостаточное  развитие,
особенно в 70-х  годах, системного матобеспечения  и задержка с  адап-
тацией американских систем. В  результате, например, появилось и  даже
продолжает появляться масса дублирующих  друг друга программ обмена  с
дисплеями, часто  одна другой  хуже. Сейчас  каждая диалоговая система
имеет  собственную  систему  ввода-вывода,  и  проблема   динамической
передачи дисплея почти неразрешима. Многие программы работают только в
рамках определенной диалоговой среды (PRIМUS, ТSО, JЕС и др.).

  К сожалению, этот опыт не принимается во внимание и в наше время.  В
качестве  примера   приведу  наличие   двух  советских   Фортранов-77,
несовместимых друг с  другом.  многие  системы несовместимы со  своими
прототипами:  это,  например,  ПДО  и  ПЛ/1  оптимизирующий,  а   ведь
прототипы  начали  распространяться  намного  раньше,  так  что  к ним
привязано   достаточно   пользователей.      Недостаточное    развитие
возможностей ОС  ЕС также  стимулировало создание  программ, незаконно
использующих  системные  средства;  многие  такие  программы  работают
только в одной операционной среде, например, в МFТ 4.1.

   Другая причина -  неразумная ведомственная регламентация  программ-
ных разработок.  Имеются в  виду прежде  всего попытки стандартизовать
программную или  операционную среду  внутри ведомства.  При этом часто
теряется возможность использовать разработки других ведомств,  которые
приняли у себя другие стандарты, скажем, АDАВАS вместо ИНЕС.

   Особого разговора  заслуживает система  виртуальных машин,  которая
иногда преподносится  как высшая  ступень развития  мультипрограммиро-
вания на ЕС ЭВМ.

   VM/370, прототип этой  системы, получила распространение  на Западе
по трем причинам:

   1.  Фирма  IBM  долгое  время  поддерживала  множество операционных
систем. VM/370 допускает их одновременное выполнение на одной ЭВМ.

   2. Изобилие на западе электронного оборудования, которое OS/370  не
поддерживает.  Работать  с  ним  в  VM/370 очень просто, поскольку она
имитирует машину без операционной системы.

   3. VM/370 позволяла имитировать персональный компьютер на  реальной
машине задолго до того, как такие компьютеры появились.

   Согласитесь, что ни одна из этих причин в СССР не действует. У  нас
только две плохо  совместимые операционные системы  (ОС и ДОС),  и они
редко  работают  вместе.  Нестандартного  оборудования  тоже  мало - в
основном  импортное.  А  персональные  компьютеры уже выпускаются, как
говорится, в железе. Поэтому, на мой взгляд, нет никаких оснований для
широкого распространения у нас этой системы.

   Вред же от нее несомненный и  значительный.  Дело даже не только  в
том, что  она снижает  производительность большинства  ЭВМ в несколько
раз,  осложняет  работу  оператора  и  снижает  динамизм использования
оборудования.  Главная   опасность  в   том,  что   возникает  соблазн
использовать уникальные особенности свм.

   Уже появилось множество программ, работающих только под управлением
монитора  виртуальных  машин,  и,  значит,  на  большинстве ЕС ЭВМ они
работать не  будут. Нельзя  же серьезно  надеяться, что  СВМ ЕС  будет
использоваться на всех  ЭВМ Ряда-2.   Если не осознать  все опасности,
которыми  грозит  распространение  свм,  у  нас вскоре не будет единой
системы ЭВМ.

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


   Д р у ж е с т в е н н о с т ь.

   Принцип дружественности часто  формулируют в связи  с персональными
компьютерами,  однако  соблюдение  его  необходимо  на всех типах ЭВМ.
Программа  тем  лучше,  чем  меньшие  требования  она  предъявляет   к
персоналу ЭВМ и к конечным  пользователям, чем больше труда она  берет
на себя.  Дружественность включает требования тщательно продумать язык
общения  с  пользователем,  диагностику  ошибок,  подсказки, мнемонику
параметров процедур, формат исходных данных и прочее.

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

   Не  слишком  дружественный  пример  матобеспечения  - это, конечно,
операционная система. Вот  уже много лет  операторы ЕС ЭВМ,  пользуясь
специальными таблицами,  задают машине  дату в  диком формате:   год -
номер  дня.  Говорят,  в  последних  версиях  наконец  это  безобразие
устранили. Почему для этого понадобилось десять лет?

   С грустью  приходится читать  в переводной  литературе рекомендации
использовать в программах  мнемонические обозначения переменных.  Увы,
эта роскошь  не про  нас! Хотя,  между прочим,  это неотъемлемая часть
современной  технологии.  И  сделать  это  так просто! Дайте мне текст
лексического анализатора  ПЛ/1, и  через два  часа он  будет принимать
русские буквы как родные. Почему это до сих пор не сделано?



     О т к р ы т а я   а р х и т е к т у р а.

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


     А в т о м а т и з м.

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

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



             Технология пятого поколения ЭВМ
             _______________________________

   Еще одна проблема, требующая  решения - разработка технологии прог-
раммирования для машин пятого и последующих поколений.  Главное их ар-
хитектурное отличие  от прежних  поколений -  наличие баз  знаний, что
позволит этим ЭВМ самим строить себе программы, руководствуясь  описа-
нием задачи на языке, близком к естественному. Это означает, что маши-
на приобретает  некоторую   самостоятельность, причем  вряд   ли можно
сомневаться, что со  временем уровень самостоятельности  будет повыша-
ться.

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

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

   Амеба по наследству получает комплекс программ поведения,  которыми
и руководствуется.  Дальнейшее развитие  живых существ  было связано с
возникновением второго,  верхнего уровня  управления -  уровня синтеза
программ. В ходе эволюции от  амебы до человека число и  роль наследу-
емых программ поведения неуклонно уменьшается, потому что эти програм-
мы больше нет нужды наследовать  - они создаются на верхнем  уровне по
мере надобности. Основной инструмент при синтезе программ поведения  -
модель внешнего  мира, которая  частично передается  по наследству,  а
частично заполняется существом в ходе обучения.

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

   Вероятно, вы уже заметили, что аналогия достаточно полная. Как  раз
сейчас начинают возникать  ЭВМ, способные к  моделированию окружающего
мира с помощью базы знаний. Все нынешние ЭВМ не умнее амебы, так как у
них  только  один  уровень  управления:  уровень  программ  поведения.
Будущие ЭВМ будут с самого начала иметь два уровня.

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

   Пока нет оснований ожидать, что развитие мыслительных  способностей
машин пойдет по особому пути. Поэтому, готовясь к работе с ЭВМ  пятого
поколения, мы должны  подготовиться и к  тому, что придется  полностью
расстаться со старыми  технологическими принципами, пригодными  только
для управления амебами.  Например, сейчас цель технологии - разработка
безошибочных  программ  в  том  смысле,  что  программа  должна   быть
адекватна постановке  задачи. Но  если программа  и постановка  задачи
просто совпадают, эта цель лишается всякого смысла. Какую ошибку может
содержать следующая  программа: решить  уравнение <...>  при начальных
условиях <...> ?  Мне  представляется, что технология для будущих  ЭВМ
распадется на две ветви: оптимизация творческого  процесса с  примене-
нием компьютеров  и достижение соответствия  базы знаний  и предметной
области.

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