Главная » 2013»Август»26 » Так кто же всё-таки будет разрабатывать под эти ваши мэйнфреймы???
Так кто же всё-таки будет разрабатывать под эти ваши мэйнфреймы???
13:33
Тема "за потрындеть", но чтобы с пользой для дела и чтоб прежде всего самому понять.
Тема флеймогонная.
Понимая, что кто-то из вас гуру в системной и/или прикладной разработке, в том числе и на мейнфрейме, и создавал уникальные непревзойдённые комплексы, в прошлом, я хотел бы напомнить вам основные долговременные тенденции в ИТ, связанные с вопросами разработки прикладных приложений, как человек, смотрящий на всё это сильно со стороны, и потому вынужденный докапываться до сути вещей, в попытках понять их.
Вы конечно же знаете о категоризации языков программирования по поколениям, где основные языки программирования, хоть процедурные, хоть ОО, относятся скорее к третьему поколению. На этих языках надо программировать, обладать навыками технологий программирования, будь это хоть C, хоть Java.
Здесь надо сделать небольшое отступление, вспомнив слово
"эффективность", применительно к понятиям
эффективность разработки
эффективность исполнения
эффективность отладки.
И здесь все эти языки делятся на две группы
с ручным управлением памятью
с автоматическим управлением памятью.
С ручным всё понятно, программист сам управляет распределением памяти, и её освобождением.
С автоматическим тоже - этим занимается некий "искусственный интеллект" в виде какой-нибудь реинкарнации сборщика мусора. Грубо говоря, при ручном распределении памяти страдают эффективность разработки и отладки, но выигрывает исполнение, а при автоматическом строго наоборот, страдает эффективность исполнения, но выигрывает разработка и отладка. Опять же стоит упомянуть о примечательном отклонении, не вписывающимся ни в одну группу - COBOL, который не имеет ни ручного, ни автоматического управления памятью, являясь платформой со статически распределяемой памятью во время компиляции, и совмещающий эффективность разработки, исполнения, и отладки. Уникальное явление, воплощённое инженерным гением IBM, где такая сложная и
тяжеловесная конструкция задания цикла, как
PERFORM BEGIN-PARA THROUGH END-PARA VARYING N FROM 1 BY 2 TO MAX_ARRAY.
и означающая
"выполнить с параграфа BEGIN-PARA по параграф END-PARA, изменяя переменную N начиная с 1 с приращением 2, до достижения значения переменной MAX_ARRAY"
транслируется всего в 8 (!) ассемблерных инструкций, из которых только
одна (!) внутри цикла. Ну не прелесть ли?!!!!
Но индустрия постоянно имеет тенденцию к решению конфликта "цивилизаций" - цивилизации "предметников", аналитиков, бизнеса, знающих бизнес-логику, и цивилизации технарей, рограммистов, умеющих разговаривать с компьютером на некотором языке программирования. В своём развитии индустрия пережила много попыток решить этот конфликт, и сблизить предметников и рограммистов. COBOL, кстати, одна из попыток в этом направлении, в целом, успешная - оказалось, что да, можно легко читать и понимать кобольный код, как и требовалось спецификацией языка. Но не так легко на нём программировать. И функция программирования сохранилась у касты программистов, предметники не стали кодировать, просто им стало легче контролировать программистов. Да во времена кобола и задач таких не ставилось - избавится от программистов.
Такая задача была поставлена позже.
Насколько я понимаю, первым такую задачу поставил известный Эдгар Ф. Кодд при разработке реляционной модели. Но возникший позже SQL оказался очень неуспешной попыткой решения конфликта "цивилизаций" - профессор Кодд, создавая реляционную теорию, декларировал как одно из основных преимуществ, возможность устранить программиста, и дать возможность предметнику работать с данными. Но не срослось, то, что получилось (SQL) настолько расстроило профессора, что он ажно покинул IBM...
И появилась каста программистов на SQL, которые, по факту, что мы видим сейчас, плохо умеют применять свой инструмент, и в дополнение, признав сложность SQL, индустрия пошла в направлении создания всяких инструментов автоматической генерации SQL запросов. То есть, по факту, не только предметники не стали пользоваться SQL, но и программисты уходят от использования SQL прямо на наших глазах. Это отдельная тема,работа с данными, немного мы её касались в комментариях к http://s390soft.ru/publ/19-1-0-76
При желании, эту боль можно бы вылить в отдельную ветку обсуждения, в попытках понять, как мы дошли до такой жизни, и как теперь отсюда выбираться.
Так вот в рамках тенденции по устранению программиста и по выработке инструмента для описания бизнес-логики предметниками, возникло понятие языков четвёртого поколения, 4GL, которое имеет воплощение в разных продуктах. Самый-самый, пожалуй, это Visual Age Generator, (некоторые поклонники Natural от Software AG сейчас начнут волноваться :) ) платформа от IBM, которая позволяет предметникам моделировать предметную область на языке 4GL, без программирования, с последующей автоматической трансляцией при размещении на исполнение, всего намоделированного, в язык третьего поколения.
Наверное, автоматический транслятор проще сделать в язык без ручного управления памятью. Хотя есть исключения - 4GL от Informix, который делал трансляцию в С.
VaGen, как платформа времён клиент-серверной эпохи, делает трансляцию единой созданной модели в два разных места
- в COBOL на сервер, для исполнения серверной компоненты
- в SmallTalk на клиент, ПС, для исполнения клиентского рабочего места
Связаны обе части между собой жёстко, намертво, не разорвать - посредством RPC, Remote Procedure Call. VaGen как платформа оказался очень успешен и имеет очень лояльных клиентов. Кстати, Software AG со своей платформой успешно "пилит" эту делянку до сих пор.
Но тут IBM пришёл "SOA", и в рамках общей тенденции к созданию систем из loosly coupled (слабо связанных) компонент, на смену VaGen пришла платформа EGL, для создания серверных компонент, предоставляющих сервисы, готовые для вызывания из любых других компонент, в том числе и клиентских. А разработка клиентских мест ушла в направление Lotus. В целом это очень популярное направление в ИТ, у IBM на этом поприще много конкурентов. EGL на всяких разных платформах транслируется в Яву, и пригоден для исполнение в среде J2EE (WAS). А на правильных платформах
(Z), EGL может транслироваться в COBOL, с дальнейшим размещением на исполнение или в виде самостоятельной программы (вызываемой JCL в JES), или подгружаемой в среду монитора транзакций. Таким образом, EGL лежит в русле долговременной тенденции индустрии в целом и IBM в частности по устранению разрыва между предметниками и программистами, и, что интересно, с попыткой не потерять эффективность исполнения бизнес-логики и управления качеством её исполнения (это я не про Яву и не про WAS, если что).
Но в целом, даже если это и модель бизнес-логики на языке EGL , она имеет некие специфические черты, необходимые для общения с компьютером.
Это и понятие "присвоения", и понятие "цикла", и так далее. Не все особи человеческого рода могут и хотят это освоить. Но являются предметниками.
А так как большая часть прикладной программы по своей сути является исполнением некоторых бизнес-правил, в общем виде выражаемых как "если... то...", то возникла идея создать инструмент для создания и управления бизнес-правилами, доступный для любого человека, не владеющего даже базовыми понятиями программирования. Эта тема тоже является очень актуальной в индустрии. У IBM это ODM, как наследник iLog.
Позволяет предметникам создавать правила на человеческом языке, и не требует программиста для их исполнения. На выходе мы получаем исполняемый код, выполняющийся на движке правил, и уже из прикладной программы мы можем обратится к правилам используя API. До сих пор существует и возможность трансляции наборов правил в COBOL, для компиляции и линковки с прикладным приложением.
ODM позволяет не только создавать правила на человеческом языке, но и симулировать их исполнение, выполняя тестирование правил, осуществлять трассировку при отладке, пытаясь понять, как оно всё вместе достигло такого замечательного результата...
Даже если не использовать движок исполнения правил, инструмент может быть чрезвычайно полезен как мостик между предметником и программистом - он может заставить нелогически устроенный мозг предметника структурно мыслить, формализовать и вербализовать свои смутные ощущения, как оно всё должно работать, в виде набора правил. Которые уже доступны математическому разуму программиста. А уж если наладить процесс деплоймента всего этого в среду исполнения.... То это позволит программисту переложить часть ответственности за результат работы на предметника.
Таким образом, если мы встречаемся с вопросом вида "кто будет разрабатывать....", то ответ будет примерно в таком русле - аналитик, предметник, он знает, что надо сделать, ему и инструменты в руки. С созданием правил он справится сам. Ну и помощника в виде кого-то, кто имеет математический склад ума и базовые понятия в программировании, для моделирования в EGL. Это тоже вполне может быть предметник, аналитик. Немножко двинувшийся в сторону понятий программирования. Или может быть бывший программист, немножко двинувшийся в сторону аналитики.
Остаётся только посмотреть, какие роли становятся особо критичными для успеха проекта, если мы принижаем роль программиста, или даже вообще от него отказываемся. Само собой, особо критичной была и остаётся роль архитектора-аналитика, даже его роль возрастает. Это человек, который должен на основании всех функциональных и нефункциональных требований создать компонентную модель некоторого уровня абстракции, пригодную для выдачи компонента, как задачи для исполнения, конкретному предметнику, и который способен совместно с предметником детализовать этот специфический компонент до какого-то уровня, начиная с которого предметник сам сможет уже выполнить задачу. Этот архитектор-аналитик должен обладать некоторыми понятиями в технологиях, чтобы определить, в какой среде должен исполнятся каждый компонент. Он же должен вычленить бизнес-правила, категоризовать их, и так далее, короче, тяжела и неказиста его судьба.
Но наряду с этим остаётся очень важной и даже всецело возрастает роль системного программиста, который должен увязать воедино все компоненты, все инструменты, обеспечить их совместную работоспособность. Если его роль всегда была важна, то теперь без него вся эта красивая идея попросту не взлетит. Таким образом, убирая прикладного программиста или принижая его роль, мы резко повышаем роль архитектора и системщика. Вот примерно такой очень краткий ответ на тему "кто будет разрабатывать".
Я не хочу сказать, что не останется прикладных программистов. Просто появляются новые возможности у предметников, позволяющие непосредственно влиять на результат программирования, не только выдачей ТЗ, но и непосредственно заданием правил всяких бизнес-расчётов, которые позволяют предметнику быть уверенным - то, что и как он задал, так и будет исполнено. А прикладные программисты будут заниматься технологическими вещами, создавая "обвязку" для бизнес-правил, и прочим, чем они и так занимаются.
за долгие-долгие годы работы в ИТ я видел множество попыток произвести революцию в программировании, одно лишь перечисление названий этих волшебных технологий заняло бы, наверное, несколько страниц формата A4. Почти каждый раз все это сопровождалось чудовищным количеством пены, взбиваемой амбициозными разработчиками, иногда даже выплескивавшейся в средства массовой информации. После того, как ажиотаж спадал, выяснялось, что "царский путь" не получился, а новая технология представляет собой не более чем очередной полезный инструмент, который занял свое место в ящике инструментов рядом с другими инструментами. Не раз эти попытки поиска "царского пути" происходили именно в том направлении, которое обсуждается в статье. Кстати, начиная с COBOLа - "ADD GIN TO VERMOUTH GIVING MARTINI" как раз и было претензией на написание программы на естественном языке, которая была бы понятна бухгалтеру, причем подразумевалось, что со временем бухгалтер начнет не только читать эти заклинания, но и писать их сам. Результат известен. И я не думаю, что переход от ввода текста с клавиатуры к перетаскиванию картинок по экрану путем возюканья мышки по столу или тырканья пальцем в экран что-то изменит: как во времена QMF, так и во времена BRIO и Crystal Report этот самый репорт все равно строит прикладной программист, а не пользователь...
- по коболу консенсус - я как раз про то и писал. да другого и быть не могло, раз уж это заявлено в спецификации языка. что получилось.... вопрос хороший, что же получилось.... а получилось то, что человеки, в своей массе, ну, в значительном количестве, туго могут читать, ну не любят... предпочитают "комиксы" - картинки. даже прекрасно написаная программа на коболе требует изрядных усилий для прочтения с вниканием в суть. вот то, что спецификация языка предполагала написание текста программ конечными потребителями этих программ, бухгалтерами - про то не знал. И, если честно, сомневаюсь в этом очень сильно. Это ведь не php какой-нибудь, да ещё в те времена - перфокарт.... Задача ставилась на понимание происходящего в программе непрограммистом, задача достигнута, если непрограммисту будет не лень...
- про революции... их есть, и много, включая не только технологии, но и методики (экстремальное программирование, например). Не думаю, что долговременная тенденция по вовлечению пользователя (тут у нас опять консенсус) в процесс создания программ выражается революциями. Лично я тут вижу эволюционный путь. Постепенное, медленное движение.
- про технологии... Тут ведь как, этот ODM, наследник iLog, он то работает.... Но если взглянуть на другой аспект.... Вот "начальничек" дал ТЗ - "а сделайте мне красиво!". А потом дрючит всех непричастных.... За некрасиво... А тут что? Возьми сам, и сделай? Сам составь бизнес-правила? Формализуй, запиши.... Это что, думать, что ли?! То, что лично я наблюдаю в этой сфере, делится на две проблемы:
руководящие и направляющие документы неполны, зачастую противоречивы, и им нужно толкование, иначе ну никак
функциональщики затрудняются формализовать, чётко и структурно изложить требования
И если с первым пунктом ну ничего не поделать, то со вторым можно попытаться. И некий инструмент (именно что инструмент, и тут консенсус), который можно использовать для упорядочивания, структурирования и формализации расплывчатой человеческой мысли-хотелки, будет полезен. Даже если "начальничек" и не будет применять его сам, а в содружестве с программистом. Даже если программист сам вообще, но ведь результат работы инструмента в виде правил на человеческом (но структурно изложенном) языке можно показать начальнику для выяснения - а то ли я сделал? (опять аналогия с коболом, но уже совсем на другом уровне).
Так что тут не революция, тут поступательное движение. Просто фразы типа если возраст водителя меньше 30 лет и количество ДТП больше 3 то установить степень риска Высокая
и так хоть на китайском. Это можно прочитать и сказать - правильно или неправильно, даже если сам так и не смог сформулировать, за тебя это сделали другие. Может, появится новая профессия, и этим займутся специально назначенные люди. Но в целом это может помочь снизить уровень непонимания между "предметниками" и программистами. Ну и ответственность - программист всегда может сказать "пардоньте, но вы сами утвердили этот набор правил!"
Раз уж понесло нас в общефилософские рассуждения, позволю себе задать вопрос (риторический!): А доживем ли мы до формализованного искусственного языка, который снимет необходимость иметь прослойку программистов в принципе? Ведь программисты существуют только для того, чтобы расхлябанные идеи, выраженные вербально, перевести в некую более логичную форму, доступную для формальной обработки. Ежели мы будем думать на коболе, программисты-кобольщики не понадобятся, потому что каждый будет программистом-кобольщиком))).... Эк меня сегодня плющит, может, траву какую злую съел...
Ничего не общефилосовские, у кого-то любимый Natural построен на этих "общефилософских" рассуждениях. если кто забыл случаем. Мой шеф как-то, слушая очередной наш спор "кобол против явы", сказал - "все эти ваши языки программирования - от неспособности компьютера понимать человеческую речь". Так что вопрос не риторический ничуть. Вспоминая, как наука роет в эту сторону. И вспоминая результат нарытого в виде голосового ввода заметок и строк поиска на всяких планшетниках. Но, также вспоминая и анекдот "формат Цэ, Энтер!", понимаю, что есть разные области применения, для голосового ввода, поиск шлюшки кафешки, или бухгалтерская проводка. Ответственность, как бы, разная. Я бы ответил на ничуть не риторический вопрос "доживём ли?" по суховски - "это вряд ли".
1. Прикладные программисты были, есть, и будут есть, куда ж они денутся. 2. Появление "программистов правил"? Вполне может быть. Но тенденция в том, чтобы дать инструмент в руки того, кто знает ответ на вопрос "что" в смысле что делается, а не "как" в смысле как программируется. И если инструмент будет ему по плечу, то почему же им не воспользоваться? 3. По своей сути применение ODM требует тесного сотрудничества "предметника" и программиста. При вербализации правил, на каждый глагол/существительное, надо наложить функцию/переменную, и без прикладника тут никак. Появится новая профессия, как результат, на стыке? Может быть. Это будет более вероятно, если появится стандарт языка описания правил. Как пример, BPEL, ещё недавно даже представить невероятно было, а поди ж ты. Да и BPMN... Кстати, было бы удобно иметь такой стандарт, вне привязки к продукту его реализующему. IBM предлагала BRML, да что-то заглохло... 4. Язык аналитика - UML, диаграмма, это его средство связи с окружающим миром. Поэтому они и "слайдами мыслят" Появись такой язык, такая нотация, для правил, будут пользовать, куда они денутся. Другой вопрос, что многие "предметники", знающие "что", не являются аналитиками, для них инструмент нужен простой и интуитивно понятный. Вот уже результат работы этого инструмента в виде текста на некотором BRML может быть и не совсем простым, это же для аналитика уже. То есть разделение - инструмент по созданию правил, и нотация на языке. Нотацию потом движку можно скормить. IBM то создало такой язык в рамках ODM, но это не стандарт. 5. Лояльность клиентов VaGen'у обусловлена не только тем, что "работает", и "хорошо работает", но и тем, что "предметник" мог непосредственно влиять на то, что будет исполнятся, моделируя в инструменте, используя нотацию. Эта идея всегда хорошто понимается и принимается "предметниками". Которые функциональщики. EGL + ODM углубляют эту идею, и дают ещё больше влияние в руки предметника, ну или большему числу предметников, ну или снижают требтования к уровню знаний предметников о программировании вообще.
ну, вот как-то вот так. хотя всё одно, COBOL rules! надо проверить, когда в ADCD включат ужо V5.1, аж зудит нетерпится
Позволю себе выразить такую теорию. Прикладные программисты были, есть и будут. На подобии появления SQL программистов, что не создай, как ни упрости, появится прослойка программистов на этом самом. Правила по созданию правил неизбежно приводят к выпаданию аналитиков из процесса создания (они по моему вообще только слайдами мыслят) и появлению "программистов".
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
Появись такой язык, такая нотация, для правил, будут пользовать, куда они денутся. Другой вопрос, что многие "предметники", знающие "что", не являются аналитиками, для них инструмент нужен простой и интуитивно понятный. Вот уже результат работы этого инструмента в виде текста на некотором BRML может быть и не совсем простым, это же для аналитика уже. То есть разделение - инструмент по созданию правил, и нотация на языке. Нотацию потом движку можно скормить. IBM то создало такой язык в рамках ODM, но это не стандарт. 
