Микропроцессорные средства и системы 1987 №3 1986 г.

Большаков И. А. - программную документацию — высококачественно!


УДК 681.3.06
И. А. Большаков

программную
документацию —
высококачественно!

А Вы ноктюрн сыграть могли бы
На флейте водосточных труб?

В. Маяковский

1. Введение.

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

операционные системы и прочие базовые системные
средства для системных программистов;

алгоритмические языки и программные средства об-
работки текста для более широкого круга прикладных
программистов;

пакеты прикладных программ и любые иные гото-
вые программные изделия для еще более широкого
круга конечных пользователей;

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

Чуть упреждая события, упомянем и потребность в
описаниях программных средств широкого (общена-
родного) потребления, которая сразу возникает с
проникновением в сферу быта персональных ЭВМ,

Хотя форма научно-технической и чисто технической
документации давно регулируется у нас многочислен-
ными правилами и стандартами, удивительно мало
говорилось в литературе о способах наполнения этой
документации целенаправленным, легко читающимся,
литературно состоятельным текстом. Очищение словес-
ного материала с помощью объявленной К. Чуковским
войны против «канцелярита» — это лишь небольшой уча-
сток фронта совершенствования того жанра литерату-
ры, который быстро становится массовым. И в его
сложившемся виде этот жанр устроить нас никак не
может.

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

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

2. Чего не хватает нашей документации?

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

структуризации текста, глубокого знания описываемых

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

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

Рассмотрим недостающие качества документации по-
дробнее.

3. Литературное мастерство.

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

программист может установить эти атрибуты яв-
но при помощи DECLARE — утверждения, компиля-
тор может определить все или некоторые атрибуты
из контекста, или атрибуты могут быть предполо-
жены по умолчанию.

По-русски это, вроде бы, должно выглядеть так:

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

А вот перл оттуда же, нарушающий нормы идиома-
тического сочетания и опущения взаимосвязанных рус-
ских слов:

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

ПЛ/1 налагает лишь незначительные ограничения
на использование имеющихся в его составе форм
представления данных и на смешение различных
представлений внутри единого выражения.

Теперь обратимся к довольно туманной фразе, заим-
ствованной из документации по СМ ЭВМ:

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

Можно гарантировать, что человек, впервые столкнув-
шийся с СМ ЭВМ, не поймет, что идет речь о сле-
дующем:

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

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

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

Вариант 1.

В течение 15—20 последних лет производимые с
помощью АЦПУ машинные документы были таки-

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

Вариант 2.

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

Вариант 1, несомненно, понятен, морфологически и
синтаксически правилен, стилистически однороден. Но,
на наш взгляд, в больших дозах такой стиль вызыва-
ет глубокий сон. Именно на основе таких «опусов»
новнчок из внетехнической среды создает представление
о научно-технической сфере как о чем-то невыносимо
нудном.

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

Использованные в варианте 2 стилистические приемы
нехитры:

автор как бы становится на точку зрения читателя,
объединив себя с ним («мы читаем и понимаем»);

вместо не всем знакомой аббревиатуры АЦПУ и
канцелярских выражений (машинные докумен-
ты, в существенной мере, то обстоя-
тельство, что) использованы синонимические пе-
рифразы;

для облегчения восприятия введена наглядная ана-
логия вида

шгч

Одно регистровая печать ^ черно-белое изображение
двух регистровая печать цветное изображение

вместо не вполне литературных большие/ма-
лые буквы использованы их вполне литературные
синонимы прописные/строчные буквы;

бесстрастное особое удовлетворение за-
менено более экспрессивным приятно яораже-
н ы;

везд£, где можно, произведена сохраняющая смысл
компрессия (по количеству слов — почти на 30%!);

особо сложные синтаксические конструкции (что..,
...ч т о) исключены.

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

Для литературной формы важен также тщательный
отбор и рациональное варьирование лексики, нашим
примером почти не затронутые.

Специальную лексику следует максимально увязывать
с терминологией* принятой в прочей литературе по

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

здесь в крайности.

Одна из них — языковой пуризм. Например, слово
экран иногда используется вместо дисплей, а ведь
экран — это часть дисплея, да и слово экран тоже
не русское. Чуть более ранний яример пуризма — от-
каз от заимствования слова с т р и н г. В итоге англ.
string, line и row, совершенно разные по смыслу, при-
ходится переводить одинаково, как строка (line —
иногда как строчка).

Другая крайность — некритические заимствования.
Например, такт (цикл работы) часов реального време-
ни называют тиком по англ. tick.

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

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

4. Структуризация и внешнее оформление.

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

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

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

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

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

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

ном изложения, предпосылаемым каждому крупному
разделу. Этот план должен отличаться от простого ог-
лавления указанием принципов (мотивов) расчленения
материала.

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

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

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

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

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

" Режимы работы

Диалоговый режим при готовом тексте
Диалоговый режим при вводе нового текста
Пакетный режим
Представляется удачным, а вариант
Режимы

Готовый текст
Новый текст
Пакетная работа
демонстрирует ту простоту, которая хуже воровства.

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

— модульность,

— структурность,
самодокументальность

безупречно, а вариант

— модульность программ,

— программы структурны,

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

12. Разделы низшего уровня лучше брать небольши-
ми (до 3—4 страниц) и варьировать по размеру не
более чем в 3—4 раза. По нашему мнению, структур-
ная красота заключена здесь в соразмерности частей.
Очень малые разделы (3—5 строк) все же допускают-
ся, чтобы привести лишь отсылку или оттенить недо-
статочную пока изученность, но логическую важность
вопроса. Избежать очень крупных разделов можно,
либо слегка перераспределяя материал между смеж-
ными разделами, либо расщепив разделы на подраз-
делы. Если ни то, ни другое не подходит, можно на-
метить где-то в середине крупного раздела логическую
паузу и ввести здесь повторяющийся заголовок вида
^название разбиваемого раздела> (ПРОДОЛЖЕНИЕ)

13. Как требует система проектной документации
(ЕСПД), документы следует делить на разделы и
подразделы, пользуясь при этом иерархической нумера-
цией вида 1, 1.1, 1.1.1, 1.1.2,..., 1.2, 1.2.1,... Как пра-
вило, подразделы Q.nT где Q — произвольный струк-
турный номер, а п=1, 2,..., покрывают весь раздел Q,
не оставляя ни строки текста, не охваченного подраз-
делами п. Пункты перечислений, не претендующие на
дальнейшее дробление включающего раздела, если
они занимают лишь по одному абзацу и не предпола-
гают ссылок на них по номеру, даются с предшест-
вующим тире.

14. Следует тщательно продумать и строго соблю-
дать способы выделения заголовков разных уровней
иерархии. В однорегистровом (только прописными бук-
вами) машинном документе этот вопрос особо сло-
жен — приходится прибегать к разным способам под-
черкивания или создания орнаментальных рамок.
Для машинописных текстов требования сформулирова-
ны в рамках ЕСПД, но они не всегда хорошо отграни-
чивают части текста. Наилучшие условия в большой
полиграфии. Здесь есть возможность выбрать гарниту-
ру и кегель заголовков, а в идеале — иногда исполь-
зовать многоцветную печать.

15. Примеры, рисунки, таблицы, формулы и даже
страницы следует нумеровать независимо по разделам
в виде ш. п, где ш — номер раздела высшего уровня
иерархии, п — номер внутри раздела. Для иллюстра-
тивного материала это согласуется с ЕСПД, для фор-
мул — не противоречит, но для страниц наши нормы
Проявляют упорный консерватизм. Между тем, если
допускать еще и вставные номера страниц типа m.nx,
где х^а, б, в,..., то это позволяет заменять уста-
ревшие страницы на новые (в том числе — более мно-
гочисленные) без передвижки номеров страниц, сохра-
няемых в прежнем виде. (Если такую документацию
хранить в скоросшивателе, то частичная замена ли-
стов оказывается делом нескольких минут.)

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

5» Знание описываемого предмета.

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

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

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

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

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

Ядром системы с позиций ее создателя является
именно словарь — он может быть сложно структуриро-
ванным, распределенным по иерархической памяти,
снабженным программными средствами морфологическо-
го анализа, сжатого кодирования слов и т. п. Но если
система функционирует так, что ни на одном шаге ра-
боты с ней эти свойства внешне никак не проявляются,
если не считать самого факта запоминания незнако-
мых слов по требованию пользователя, то ему доста-
точно сообщить в описании только принцип действия
системы — наличие словаря. Во всем прочем пусть си-
стема останется для пользователя «черным ящиком» с
четко определенными реакциями на каждую из под-
робно описываемых команд: ПРИНЯТЬ слово, как оно
есть, ЗАПОМНИТЬ его на будущее, ЗАМЕНИТЬ на
иное слово в данном месте, ПОДМЕНИТЬ на иное сло-
во везде далее и т. п.

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

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

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

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

в. Педагогическое мастерство.

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

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

2. Должны эксплицитно обозначаться связи между
объектами в смежных предложениях и внутри сложных
предложений. Вот пример текста, где эти связи (назы-
ваемые лингвистами анафорическими и темо-рематиче-
скими) специально подчеркнуты:

...Была предложена система для проверки текстов.
Эти тексты должны относиться к научно-технической
сфере. Последняя включает произвольные документы
научно-технического характера.

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

3. Необычайно важно дать обильный иллюстративный
материал — примеры, рисунки, диаграммы, таблицы.
Они должны быть графически выделены из прочего
текста. Где нужно, к ним должен приложить руку
художник-оформитель, обладающий чувством меры и
юмора. Рядом с заголовками бывают полезны микро-
таблицы (пиктограммы, эмблемы) чисто мнемонического
назначения, характеризующие адресатов раздела, усло-
вия применимости описываемого раздела, факультатив-
ность и т. п. Если, например, описываются команды,
применимость которых зависит от режима работы, то
допустимость конкретной команды в 1-м и 3-м из трех
возможных режимов легко схватывается по диаграмме
вида

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

7. Вместо заключения.

Прочтя статью, читатель явно усомнится, сможет ли
удовлетворить всем приведенным (и иным не затрону-
тым) требованиям программист, честно и квалифициро-
ванно занимающийся своим прямым делом — програм-
мированием. Эти сомнения будут обоснованными. Ви-
димо, назрела потребность в новой профессии — профес-
сии технического писателя. Но пока такой профессии не
существует, программистам придется самим заботиться
о коммуникациях с пользователями, не слишком пола-
гаясь на научных и технических редакторов. Только
хорошая документация позволит быстро решить проб-
лему второго ликбеза, о которой говорят академики
А. П. Александров и А. П. Ершов,— усвоения основ вы-
числительной техники и программирования многомилли-
онной массой наших людей.

Телефон для справок — 155-45-15 (Москва).

Статья поступила 13 июня 1986 г.




СОДЕРЖАНИЕ:


  Оставте Ваш отзыв:

  НИК/ИМЯ
  ПОЧТА (шифруется)
  КОД



Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Who are the buzzards? - кто сделал BUZZ?!
Реклама - реклама и объявления.
Editorial

В этот день...   25 мая