16 июн. 2013 г.

Проза и романтика программирования из прошлого

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


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

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

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

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

Азбука на спине

Лучше не спорить о приоритетах и отказаться от нумерации. К тому же не все и не всегда ладно с основой — просто грамотностью. Среди числящихся грамотными, имеющих документ о полученном образовании не так мало, увы, тех, кто не в состоянии понять прочитанное, кто делает грубейшие ошибки при письме. «В делах правописания (Признаться мы должны) Мы не были и ранее Особенно сильны»,— писал в 1919 г. С. Маршак под псевдонимом д-р Фрикен (примерно на сотню лет раньше с реальным доктором Фрикеном был знаком в Кишиневе Пушкин). Прошло семь десятилетий, а мы все еще не особенно сильны в правописании. Беда эта — всемирная.

Телевидение Франции недавно осуществило «общенациональный диктант»: несколько миллионов человек написали под «теледиктовку» короткий текст. Вероятно, ошибок не избежал никто, даже сотня с лишним финалистов—представителей культурной элиты страны. Один из них — «бессмертный» (т. е. член Французской академии) писатель Жан Дютур — похвалялся, что никогда не ошибается в правописании. В итоге в написанном им тексте оказалось целых 10 ошибок! Это, правда, далеко не рекорд. Ведь французы впервые писали публичный диктант еще в 1868 г. (текст его сочинил Проспер Мериме). Однажды Александр Дюма-сын допустил в диктанте аж 24 ошибки...

Если перенестись из Франции на Дальний Восток, обнаружим, что (по словам отечественного автора) «в последнее время японская молодежь стесняется нетвердого знания иероглифики, которое они боятся обнаружить, например, в письме к учителю». В чем же дело, отчего грамотность повсюду катится вниз? Один из ответов предлагает А. М. Панченко. Он приводит данные о высокой грамотности жителей Москвы в середине XVII столетия: умели расписаться не менее трех четвертей дворян, монахов и купцов, около половины посадских мужиков; Печатный двор выпустил 300 тыс. букварей по копейке за штуку. «В Петровскую эпоху,— добавляет Панченко,— когда европеизация достигла апогея, грамотность массы русского населения, напротив, понизилась: силы нации были отвлечены на флот, регулярную армию, постройку новой столицы и т. д.».

Правда, «отвлечение сил нации» — едва ли универсальное объяснение. Так, Декрет о ликвидации безграмотности был подписан Лениным 26 декабря 1919 г., в разгар гражданской войны. И сил на ликбез хватило. Конники-красноармейцы, например, учили азбуку, не вылезая из седла: классную доску им заменяла... спина едущего впереди бойца. Дело в том, что перед походом комиссары прикрепляли к спинам кавалеристов листы бумаги с крупно написанными буквами, а если не было бумаги, то старались раздобыть мел и вывести буквы прямо на одежде. Изданием новых букварей уже в 1920 г. занялась Всероссийская чрезвычайная комиссия по ликвидации безграмотности, организованная также декретом Совнаркома.

Без этих чрезвычайных мер мы бы даже не заикались сегодня о компьютерной грамотности. Ведь, помимо всего прочего, с компьютером мы не разговариваем, а «переписываемся». И писать нужно без ошибок, а то машина еще и не поймет. К тому же все шире распространяющиеся персональные ЭВМ — если они нужны для дела, а не для игры — едва ли не в первую очередь облегчают работу с бумагами, документами. Так что вторая грамотность (чем бы она ни обернулась) надстраивается над первой. Но интересно, что есть и отчетливое обратное влияние. Об этом стоит поговорить.

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

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

Компьютер в классе — это не только мощный стимул к овладению грамотой, но и своеобразный тренажер. Разработано немало машинных программ, облегчающих обучение чтению и письму. Сравнение показывает, что у детей, имевших доступ к персональным компьютерам с такого рода программами, соответствующие навыки развиты заметно сильнее, чем у их сверстников, овладевающих грамотой без ЭВМ. Жаль только, что компьютеры с такими программами не в нашей стране. Сейчас педагоги заговорили о «естественном» (т. е. не связанном еще с обучением) процессе овладения детьми элементами грамотности, о тенденции к «врастанию» в чтение и письмо. Педагоги основываются на фактах: малыши все чаще узнают распространенные надписи, а наиболее важные для себя каким-то образом понимают. У них исподволь формируется мотивационная сторона «врастания» в мир письменных текстов, ибо дети самостоятельно вырабатывают представления о том, для чего нужно читать и писать, умеют судить об открывающихся перед грамотным человеком возможностях.

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

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

Эдисоновский талант

Ряды «золотых воротничков» уже начали пополнять новобранцы, которым еще в детстве удалось познакомиться (и подружиться) с компьютером. Эффективной организацией компьютерного всеобуча для школьников всерьез озабочены и в развитых, и в развивающихся странах. Лидируют США, Франция, Япония. С недавних пор соответствующий курс фигурирует в учебной программе и в нашей стране. Хотя самих ЭВМ пока еще катастрофически не хватает, но первые шаги уже сделаны. Среди наиболее активных и страстных инициаторов обучения детей информатике — академик А. П. Ершов. С Андреем Петровичем мы еще не раз встретимся на этих страницах.

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

Аллюр проходил по рытвинам и ухабам, попадались и замаскированные ловушки, причем в таком количестве, что временами казалось, будто совсем опускаются руки. Однако даже в самые тяжелые минуты программисты продолжали работать как одержимые, так что им удалось избежать превращения в загнанных лошадей. Были, конечно, и радости, и успехи: они не принесли программистам золотые горы, но помогли обрести высокую репутацию и... «золотые воротнички». И то и другое (а может, и первое) они заслужили. Еще бы немного внимания... Ведь пока что мало кто дает себе труд вникнуть в специфику их деятельности, взглянуть на нее изнутри. Едва ли многое изменит в этом плане далее поголовный компьютерный всеобуч.

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

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

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

С точки зрения вычислительной машины язык математики (реальный, а не потенциальный) — нестрогий, расплывчатый, неконкретный. Как ни живуче представление о несравненной точности математики, программы для ЭВМ куда строже и детальней. Об этом говорит член-корреспондент АН СССР С. С. Лавров: «Это может показаться странным, но у программистов действуют гораздо более строгие стандарты ясности и точности описания, чем у математиков. Это понятно, так как математики могут рассчитывать на достаточно высокий уровень знаний, сообразительность и интуицию читателя, программисты же имеют дело с машиной (или программой), лишенной этих качеств».

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

Как говорил А. П. Ершов, программист относится к ЭВМ как «хороший жокей к своей лошади». Общаясь с машиной, программист отчетливо сознает ее достоинства и старается наилучшим образом их использовать. Он приспособился к недостаткам машины, и они его не раздражают. Добиться рациональной и экономичной работы ЭВМ — выполнение такой задачи (а программист неизменно ставит ее перед собой) приносит удовлетворение, похожее на то, которое испытывает творчески работающий инженер от изящного и ранее неизвестного технического решения.

Составление алгоритма и перевод его на понятный машине язык, распределение памяти и ресурсов ЭВМ, отладка программы — весь этот сплав делает работу программиста уникальной.

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

«...Можно написать грандиозные программы»

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

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

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

Никак не выразить словами тот идеал красоты (Прекрасной Программы), который сложился в программировании...

Как растолковать несведущему человеку умопомрачительный блеск математического доказательства, захватывающую дух неожиданность конструкторского решения, поразительную безукоризненность естественнонаучного эксперимента? Чтобы оценить их, надо прежде всего быть профессионалом. Зато профессионалы — при всех индивидуальных различиях во вкусах — сходятся в понимании того, что есть красота, а что уродство, еще и нюансы различают. Да и профаны, овладей они специальным языком и приобрети опыт работы, наверняка согласились бы с ними и охотно называли бы опыт «изящным», вывод «красивым», а теорию «безумной».
Программирование не составляет исключения: оно «обладает богатой, глубокой и своеобразной эстетикой, которая лежит в основе внутреннего отношения программиста к своей профессии, являясь источником интеллектуальной силы, ярких переживаний и глубокого удовлетворения». К такому выводу приходит А. П. Ершов и не случайно одна из знаменитых его статей носит название «О человеческом и эстетическом факторах в
программировании».

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

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

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

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

Если в программировании тасманийцы не снискали пока мировой славы, то в мореплавании они не новички. Океан для них — это и место работы, и средство связи с миром, и желанный отдых, и источник природных напастей. Так что стоит прислушаться к их словам. Тем более что тасманийцы наверняка знакомы с самыми современными проблемами парусного спорта: регата Сидней — Хобарт (630 миль) популярна среди яхтсменов. Местные спортсмены, по словам обозревателя, известны своими решительными действиями в штормовую погоду. Неплохая характеристика, не правда ли?

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

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

Вещь для прогрммиста

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

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

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

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

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

И вот появилась вычислительная машина... Голова к голове проходит с ней программист сквозь все алгоритмические хитросплетения, задает ей вопросы и получает ответы, наконец триумф: «Программа пошла!»

Как после этого не проникнуться теплым чувством к детищу электроники, не одухотворить его? «Эта серия книг с нежностью посвящается машине IBM 650, некогда установленной в Кейсовском технологическом институте, в обществе которой я провел много приятных вечеров» — таким посвящением открывается многотомник Д. Кнута.

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

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

Как бороться с липовой экономией

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

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

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

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

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

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

Что тут возразить? Может, кое-кто сник бы, но программисты за словом в карман не полезли. «Это липовая экономия,— утверждают они,— выгадывать машинное время за счет человеческого».

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

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

Первая в мире вычислительная система с разделением времени — «Проект МАК» (МАК — аббревиатура сразу нескольких английских выражений: «человек и компьютер», «познание с помощью компьютера» и «компьютер множественного доступа») — появилась в Массачусетсском технологическом институте (МТИ) в самом начале 60-х годов. По этому проекту ЭВМ обрабатывает одновременно до 30 программ.

Точнее, не совсем одновременно, просто ЭВМ квантует единицу времени (скажем, секунду), и обработка каждой из 30 программ длится ровно один квант. В следующую единицу времени — то же самое. В простейшем случае каждую тридцатую долю секунды прерывается выполнение одной программы, и центральный процессор — «рабочий орган» вычислительной машины — переходит к очередной программе. Быстрота, с которой работает ЭВМ, помогает ей с толком использовать даже такие ничтожно малые для человека кванты времени. Когда какая-то программа завершена, ответ без промедления выдается тому, кто его ожидает.

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

Неоценимую помощь программистам оказал американец Гарольд Сакман — один из первых профессиональных психологов, занявшихся системами «человек-ЭВМ». Он сравнил деятельность программистов в двух конкурирующих режимах пакетном и разделения временя. Оказалось, что по некоторым показателям следует отдать предпочтение разделению времени. Этим выводом Г. Сакман сильно подорвал прочные, казалось, позиции сторонников пакетного режима работы ЭВМ.

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

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

«Мифический человеко-месяц»

Творческий характер труда всегда казался программистам не менее ценным завоеванием, чем возможность сотрудничать с ЭВМ.

Программист, как художник или изобретатель, почти полностью независим в своей работе. Кто подскажет ему, какой путь избрать?

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

Неоднократно проверено: двое, трое, четверо программистов, объединившись, закончат программу лишь ненамного быстрее, чем если бы работал только один из них. Далеко не всегда программа допускает разбиение на относительно обособленные части, над которыми можно работать параллельно. В программировании человеко-месяц, по Ф. Бруксу,— величина фиктивная и обманчивая.

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

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

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

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

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

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

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

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

Хорошо документированное, тщательно отлаженное семейство взаимодействующих между собой и допускающих расширения программ—это комплексный программный продукт. Как ни дорого и ни утомительно создавать его, но приходится идти на это. Иначе не удалось бы внедрить компьютеризацию в наиболее ответственные, ключевые отрасли: высокоточное производство, системы управления и снабжения, банковское дело. Применять компьютеры выгодно, ибо растет производительность труда. Однако увеличиваются и затраты на разработку комплексного программного продукта. Не приходится поэтому удивляться, что уже к 1982 г. по подсчетам вице-президента ведущей компьютерной фирмы ИБМ JI. Бранскомба «около 100 млрд. долларов было израсходовано на программирование (за последние 30 лет), что приблизительно соответствует общей стоимости всех установленных в мире ЭВМ». Сумма чрезвычайно внушительная да к тому же умеренная, ибо опубликованы и другие цифры, в несколько раз ее превышающие.

Вещь для машины

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

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

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

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

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

Все признают, что конвейер — зло, хотя зачастую неизбежное. Он равно обессмысливает и физический и умственный труд. «Конвейерный метод в программировании,— пишет А. П. Ершов,— может либо убить интеллектуальную компоненту в труде программиста, либо вызвать неврозы из-за противоречия между монотонностью и трудностью работы. Представьте себе человека обязанного 8 часов в день, 5 дней в неделю, 50 недель в году решать одни кроссворды, и вы поймете, что такое программист, специализирующийся, например, на написании редактирующих программ».

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

«Одним из качеств хорошего программиста можно считать его способность удерживаться от соблазна использовать ухищренные приемы программирования»,— прямо пишет американец Эдвард Подан. Он выражает победившую точку зрения.

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

Что же все-таки отличает хорошего программиста от, скажем, хорошего хлебопека или шофера? Среди ответов почетное место занимали тавтологии типа «хороший программист пишет хорошие программы». Но пожалуй, чаще всего высказывалось убеждение, что хорош тот программист, с которым руководству спокойно.

Уточняя, один программист из Монреаля заявил? «Для руководителя важно, чтобы я работал в достаточно определенные часы, хорошо взаимодействовал с другими программистами и пользователями ЭВМ, а самое главное — не доставлял хлопот».

А больше всего хлопот с переполненным творческими замыслами, своевольным и даже несколько эксцентричным классным программистом. Лет 20 назад он был в почете, ибо в трудную минуту мог вывести из провала целый отдел. Теперь же ему предпочитают юнца обученного определенной технологии. А ведь классному программисту еще далеко до пенсии...
Если раньше шли в программисты, то теперь наметился обратный поток —из программистов в непрограммисты. «Программирование — нежеланная, нелюбимая профессия» — статья с таким эмоциональным заглавием, смахивающим на крик души, появилась в научной (!) периодике.

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

«Работать с другими людьми»

Надо сказать, что значение этих различий здорово преувеличено (в частности, с «легкой руки» Г. Сакмана). Это произвело впечатление на многих, но не на Дж. Вейнберга — опытного программиста, преподавателя, автора первой в мире книги по психологии программирования. Значительную часть книги занимают эмпирические обобщения, но Вейнберг проводил и весьма любопытные эксперименты.

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

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

Простой экспериментальный факт. Но выводы из него нетривиальны. Они вытягиваются, как из рукава фокусника. Прежде всего деятельность программиста целенаправленна, и Вейнберг показал, что программист умеет выполнять поставленные цели. Это умение крайне ценно, но предварительным условием должна быть грамотная и квалифицированная постановка целей.

Только вот вопрос: кто задает цель?

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

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

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

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

Проблемы такого рода давно уже решены в промышленности, в проектных и конструкторских организациях. Но для программистов это непривычно, необычно. Сказывается-таки первоначальный индивидуализм их труда. Однако теперь программисты учатся методам коллективной работы. Что ж, если они и впрямь переводчики (с человеческого на машинный и обратно), то это было неизбежно. Дабы не оскудевал поток в программисты, идет упорный поиск разумных альтернатив конвейеру и другим малоудачным нововведениям. Все, почти все сейчас зависит от самих программистов. И не случайно, наверное, среди ответов на задаваемый Э. Йоданом вопрос все чаще встречается: «Хороший программист умеет работать с другими людьми».

Принцип неопределенности

Коли так, программистам впору в очередной раз начать сокрушаться. Если, конечно, они ни на йоту не отошли от принятых некогда высших ценностей своей профессии: творческого, практически бесконтрольного характера труда и тесного диалога с компьютером. Однако творчество пришлось вписывать в прокрустово ложе сетевого графика, конвейера и методологии программмирования (ориентированной на квалифицированного но среднего исполнителя). Что же касается такого же данного диалога с ЭВМ, то сначала его заменили пакетной обработкой, т. е. чем-то вроде обмена монологами. На смену пришел полилог в режиме разделения времени. А когда ЭВМ наконец-то чрезвычайно размножились (их «поголовье», возможно, превосходит число квалифицированных программистов), «золотым воротничкам» предлагают... переключиться на диалоги с людьми. Кто же останется у дисплея?

Разумеется, нелепо было бы отлучать программистов от компьютера. Однако волнения их не лишены оснований, поскольку вновь меняются цели применения вы числительной техники. Если первоначально цель состояла в максимальной загрузке всех ресурсов ЭВМ, а начиная с середины 60-х годов — в интенсификации человеческого ресурса (времени, знаний и способностей программистов), то в 80-х годах на повестку дня выдвинулось всемерное использование интеллектуального потенциала непрограммистов. Такова наиболее современная постановка вопроса о человеческом факторе а сфере информатики.

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

Применение ЭВМ не означает полной формализации такого рода деятельности — компьютеры играют в ней вспомогательную роль.

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

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

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

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

Американец Д. Мартин провел аналогию с введенным В. Гейзенбергом принципом неопределенности В квантовой механике этот принцип гласит, что процесс наблюдения за материальной частицей воздействует на нее и препятствует точному определению ее параметров—импульса и координат. В применении к информатике принцип неопределенности может означать, что процесс компьютеризации деятельности воздействует на имеющиеся у человека представления об этой деятельности и путях ее автоматизации. Или иначе: в ходе разработки программного комплекса требования к нему вполне определенны; процесс же внедрения начинает размывать эту определенность, придает импульс к модификации и задает координаты изменений; словом, от былой определенности не остается и следа.

Программирование без программистов

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

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

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

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

Что же касается программистов, то они останутся почтовыми лошадьми просвещения. Наряду с множеством прикладных программ им надлежит совершенствовать удобные для новичков программные средства. И задача работать с другими людьми с них не снимается: очевидно, консультирование непрофессионалов ляжет на плечи «золотых воротничков». Так что новые лозунги не отменяют старых.

У Д. Мартина есть сторонники, есть и противники. Среди последних уже упоминавшийся Э. Дейкстра. Он недоволен тем, что плохо обученные и никем не контролируемые специалисты получили доступ к компьютерам и устремились к простоте и дешевизне. Поскольку непрограммистов явно больше, то на рынке программных продуктов лишь немногие будут отмечены печатью хорошего стиля. Для продукции непрофессионалов будут характерны все те недостатки, от которых программисты давно избавились. «Признаться, я был совершенно отрясен, увидев... возрождение всех наших прежних ошибок,— ужасается Дейкстра.— Это было пугающее, гнетущее, отвратительное зрелище...»

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

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

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



0 коммент.:

Отправить комментарий

Понравился блог или статья? Поделить с друзьями в социальных сетях!
Twitter Delicious Facebook Digg Stumbleupon Favorites More