Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/04h2122.shtml

12.2. Следующие “серебряные пули”

       В предыдущем разделе я рассказал о первом примере творчества в истории программирования — о разработке бизнес-приложения и специализированного компьютера LEO в английской компании J.Lyons в 1951 году. Я назвал это поразительным явлением в истории программирования, заслуживающим юбилейных торжеств.
       Деятельность J.Lyons была лишь началом длинной цепочки творческих вех в истории компьютеров и программ. Хочется вспомнить и другие события этой цепочки.
       Стоит ли рыться в хронологической пыли, выясняя, как программирование дошло до его нынешнего состояния? В конце концов, программирование интересно тем, что мы умеем сегодня, а не (относительно) слабыми достижениями прошлого.
       Но послушайте. В нашей области многое успело забыться, и мы то и дело слышим: “Я и не подозревал!” Одни, обсуждая компьютерную историю, допускают ошибки. А другие потом ссылаются на ошибочные заявления, тем самым усугубляя ошибку.
       Есть и другой фактор, помимо ошибочности утверждений. Недавно я писал статью, посвященную вечным для меня идеям, таким как структурированные методологии и CASE-средства, и мой молодой коллега указал мне на то, что многие из сегодняшних читателей могут не понять, о чем идет речь, и, что еще хуже, всякое упоминание о них делает мою статью устаревшей. Пришлось согласиться с ним. События 1970-1980-х, вроде структурных методов и CASE-средств, мало интересуют сегодняшних программистов, которые тогда только родились.
       Но в то же время мне хотелось возразить. Это часть нашей истории, о которой не следует забывать. Не только из-за полученных нами важных уроков, хотя и их трудно переоценить. Дело в том, что многое из того, что мы сегодня думаем, что знаем, можно прямо (или косвенно) проследить до этих исторических вех. Они составляют богатую историю и материал, на основе которого мы и дальше будем развивать программирование.
       Поэтому давайте совершим короткую историческую экскурсию по творческим вехам программирования:
       Прежде всего, во времена J.Lyons компьютеры поставлялись пустыми, и писать для них программы нужно было на машинном языке. А машинный язык был творением инженеров, чертовски полезным (способным на любые компьютерные трюки), но явно недружественным для пользователя. (Представьте, что все операции и адреса данных записываются числами, а сами эти числа даже не десятичные, а двоичные, восьмеричные, ше-стнадцатеричные или еще в какой-нибудь системе из применявшихся в тогдашних компьютерах.)
       К счастью, та эпоха довольно быстро закончилась. Сначала появился ассемблер, позволяющий кодировать операции и адреса не числами, а символами. С точки зрения исторического значения, это событие не было очень яркой вехой, поскольку не сильно развило возможности программирования. Но с точки зрения творчества, появление ассемблера было шагом к компьютерной обработке символов, а не чисел. А на этом основано большинство других вех в программировании.
       Еще одна из фундаментальных идей в программировании появилась примерно одновременно с ассемблером. Программы стали строить с помощью модулей — отдельных программных блоков для решения конкретных задач, которые можно было вызывать из основной программы. Эта идея, возникшая в середине 1950-х, и сегодня остается одним из главных достижений в истории программирования. Конечно, ее развивали последующие поколения программистов-практиков, и лет через десять ею занялись теоретики, но мысль о том, что программы можно строить из (многократно используемых) отдельных частей, многие до сих пор находят восхитительной (полагая, что сами до нее додумались!).
       Довольно скоро после появления ассемблера и модульного программирования произошли два важнейших события в истории программирования: появились языки программирования высокого уровня и операционные системы. То и другое случилось в середине или конце 1950-х, и, честно говоря, не могу припомнить, что появилось раньше в тех программирующих организациях, где я работал. Пожалуй, за всю историю программирования это были самые заметные перевороты, совершенные инструментами. Инструмент под названием “компилятор” преобразовывал язык высокого уровня в машинный язык. Первым таким языком был Fortran, который (в несколько измененном виде) применяется по сей день. Вслед за ним появился COBOL, также применяемый в настоящее время. Эти языки были ориентированы на конкретные предметные области: Fortran говорил на языке ученых и инженеров, a COBOL — на языке бизнес-аналитиков.
       Операционные системы, как мы уже знаем, служат тем средством, благодаря которому программисты, создающие приложения, могут забыть об утомительной организации взаимодействия с аппаратурой, сконцентрировав свое внимание на той прикладной задаче, которую нужно решить. В общих чертах, операционные системы представляли собой унифицированный набор программных модулей для поддержки сервисных функций аппаратуры конкретного компьютера. В те времена мы так радовались появлению операционной системы, не предполагая, что в какой-то момент (то есть, сегодня) операционные системы станут предметом споров и даже политических разногласий!
       1950-е сменились 1960-ми, и эти творческие прорывы упрочили свои позиции в программировании. Возникали новые языки высокого уровня. Появлялись новые и лучшие операционные системы. Скорость этих изменений была поразительной, но они были скорее эволюционными, чем революционными. Эта эволюция включала создание новых языков программирования, независимых от предметной области (например, Fortran и COBOL объединились в PL/1), и даже создание аппаратного обеспечения, также охватывающего разные предметные области (самые первые компьютеры были ориентированы либо на научные расчеты, либо на бизнес). Разумеется, новые операционные системы поддерживали все более разнообразную аппаратуру.
       С концом 1960-х связано рождение академических компьютерных дисциплин. Сначала появились компьютерные науки (Computer Science), а вслед за ними — информационные системы (Information Systems). Программный инжиниринг (Software Engineering) как отдельная дисциплина появился лет на десять лет позже. Видимо, большинство читателей будет удивлено таким поздним возникновением этих дисциплин в процессе эволюции программирования. (Заметим, что со времени событий в J.Lyons прошло 15 лет.) Множество программ было написано к тому моменту, как за увитыми плющем стенами задумались над тем, как это делать правильно!
       Примерно в те же годы разрабатывались некоторые из наиболее основательных прикладных систем. Были попытки (в основном, неудачные) создания сложных интегрированных автоматизированных систем управления (АСУ — Management Information Systems, MIS). Примерно тогда же коммерческие производители, такие как SAP и PeopleSoft, начали разрабатывать аналогичные системы, десятилетие спустя достигнув благодаря им громкого и сказочного успеха. Успешно вводились в эксплуатацию системы заказа авиабилетов. Операционная система для IBM 360 была тогда одним из крупнейших приложений и хорошо справлялась со своими функциями. Были разработаны гигантские и невероятно сложные системы для космоса и метеорологии. В далекие 1950-1960-е мы думали, что строим сложные и внушительные приложения. Никто и представить не мог, что ждало нас впереди!
       По мере роста объема и сложности приложений в центре внимания оказываются системы, инструменты и идеи, позволяющие бороться с этой сложностью. Сначала в 1970-х появилось структурное программирование. Оно представляло собой ряд методологических рекомендаций по поводу того, как надо и не надо писать “ структурированные” программы. В структурном программировании было два примечательных аспекта. Первый — его восхваление как революции в программировании, в связи с чем оно было принято на вооружение практически всеми программистами почти всех организаций. Второй — отсутствие каких-либо исследований, подтверждающих существование столь превозносимых достоинств. Десятью годами позже изучение литературы, оценивающей эффективность структурного программирования, дало двусмысленные результаты, никоим образом не подкреплявшие первоначальные претензии. Важно заметить, что несмотря на утихшую шумиху, сегодня большинство программистов уверены в полезности структурных методов, и большинство современных программ в некотором смысле “структурированы”.
       Тот случай неоправданного восхваления отнюдь не последний в отрасли. Инструменты и языки были представлены как методы “автоматизации” программирования, благодаря которым эту работу осилит каждый — не обязательно профессиональный программист. В 1980-е заявляли, что средства CASE (автоматизации программирования) и 4GL (языки четвертого поколения) сделают это возможным. Неважно, что многие CASE-средства были куплены, а затем брошены и забыты (такие программы в шутку называли “полочными”). Неважно, что практики и теоретики совершенно разошлись во взглядах на 4GL (практики считали их языками генерации отчетов по базам данных; теоретики — непроцедурными языками, в которых программист описывает, какие действия нужно выполнить, но не их порядок). Неслучайно примерно в это время Фред Брукс написал свою историческую статью “Серебряной пули нет”, в которой высказал мнение, что все революционные прорывы в программировании уже свершились и, по всей вероятности, в будущем нас не ждет ничего столь же выдающегося, как языки и операционные системы 1960-х.
       Что произошло с CASE и 4GL потом? Подозреваю, что мы до сих пор их применяем, но сами термины пользуются таким неуважением, что их редко встретишь. И уж, конечно, широко разрекламированные успехи так никогда и не были достигнуты.
       Структурное программирование не было последним словом в представлениях о революционной роли методологии. Последним криком моды стало объектно-ориентированное программирование (ООП), от которого ждали чудес, как прежде от структурного. Сегодня трудно судить об ООП непредвзято, поскольку пока еще не предложена очередная революционная технология, готовая его сменить. Есть разные данные по поводу широты применения ООП (некоторые утверждают, что он распространен повсеместно, но те исследования, с которыми я ознакомился, указывают, что им пользуется меньше 50% компьютерных организаций). Относительно преимуществ ООП мнения также расходятся. Предполагается, что его методы облегчают работу новичкам, однако исследования показали, что новички лучше справляются с функциональным, чем с объектно-ориентированным подходом. Считается, что ООП должно способствовать повторному использованию кода (помните наш разговор о модульном программировании?), и есть исследования, показавшие, что в некоторых предметных областях добрые 70% кода можно использовать повторно, а не писать заново (хотя другие исследования показали почти такие же результаты для методов, не являющихся объектно-ориентированными). ООП должно также позволить создавать программный код в объектах решения, непосредственно взаимосвязанный с объектами решаемой задачи, но сейчас в нем приняты “сценарии использования” (use cases), а это явно функционально-ориентированный подход к определению системных требований. И снова: по мере снижения ажиотажа вокруг ООП становится очевидно, что это хороший, но не идеальный способ разработки программ.
       Что еще осталось из творческих вех в истории программирования? Вклад последнего времени — гибкое программирование (Agile) и ПО с открытым исходным кодом (Open Source). У каждой из этих технологий найдутся сторонники, считающие их великолепными творческими достижениями в области разработки программ. И другие — те, кто считает Agile-методы пригодными лишь для небольших приложений некоторых типов, a Open Source — эмоциональным всплеском, более интересным своим фанатическим поклонникам, чем миру программирования в целом.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/04h2122.shtml