Негативная роль традиционных КИС в современной школе программирования
Стоп, стоп! Не надо сразу на меня набрасываться, багроветь в гневе и рвать статью, не дочитав до конца (удалять файл, закрывать окно браузера), давайте вместе размышлять. Во-первых, посмотрим, программисты по каким языкам требуются бизнесу для поддержания работоспособности КИС. Ага, что тут у нас? 1С, Парус, Галактика, Аксапта, Навижн. Ну что ж, можно было и не смотреть, результат очевиден. Во-вторых, чуть позже вернемся к названию статьи и посмотрим, как упомянутые выше КИС влияют на современную школу программирования.
Что представляют собой традиционные КИС?
Такие КИС концептуально устроены схоже: все имеют реляционную СУБД в качестве хранилища данных (я не беру во внимание старые файл-серверные версии, в них всё еще хуже), толстый клиент получает данные из хранилища данных, обрабатывает их и выдает тонкому клиенту (т.е. конечному пользователю). Сохранение данных – в обратном порядке. Все эти КИС поставляются с собственными встроенными языками, призванными по желанию Заказчика нарастить функционал КИС до желаемого. Казалось бы, всё правильно, но давайте посмотрим внимательно на причины такого устройства КИС
Почему традиционные КИС устроены именно так?
Собственный язык программирования. Его необходимость обусловлена тем, что, только закрыв исходный код, производитель КИС снижает риски несанкционированного копирования КИС (или её фрагментов) конкурентами и потребителями. Попутно решаются некоторые другие задачи: пользователь получает доступ к данным только через объекты и процедуры такого языка (инкапсуляция), что сильно снижает возможности настройки, но одновременно снижает риски краха всей системы, т.к. «кривыми руками» можно «наломать дров». Правда, это касается ситуации, когда собственный язык программирования сам достаточно стабилен, что не всегда очевидно, да и от «кривых рук» не спастись по большому счету. Толстый клиент. Нужно понимать, что перед производителями КИС стоит не только высокая задача «устроить корпоративные данные наилучшим образом», но и вполне приземленная - «как можно быстрее и дешевле внедрить свою КИС Заказчику». Т.е. главное тут успешный старт, то, что будет дальше – уже другая задача, а поскольку «толстый клиент» оперирует данными с помощью алгоритмов (в то время как большинство языков СУБД относятся к транзакционным и оперируют данными, как множествами, с помощью SQL), делать первую инсталляцию легче, т.к. алгоритмический тип мышления более свойственен человеку и на первом этапе требуется меньшая квалификация персонала. - И как это всё влияет на культуру программирования? – спросите Вы. Терпение, читаем дальше, посмотрим, чем грозит Заказчику такое устройство КИС.
За все приходится платить!
Собственный язык программирования. Вообще говоря, практика показала, что любая программа может быть с легкостью «сломана» и вопросы защиты интеллектуальной собственности смещаются в сторону правовой области. Так надо ли защищать исходный код? А ведь разработка собственного языка программирования - очень дорогостоящая задача и платить за её решение вынужден заказчик. Кроме того, корпоративное ПО, по сути, ничем не отличается от любого другого ПО. Оно так же требует системного подхода, профессиональной среды разработки и управления данными. Ни один разработчик КИС не в состоянии предоставить среду разработки сколько-нибудь сопоставимую с DELPHI или Visual Studio. Разницу в производительности и гибкости собственного языка и профессиональных сред можно представить, если сопоставить функционал NotePad и Word. Казалось, какое дело Заказчику КИС до красоты и мощи среды разработки, ему важен результат за приемлемые деньги. Но скажите, если конструкция машины слаба, разве может работать такая машина долго? Очевидно, что риски просто переносятся на более поздний период. То же касается и управления данными. Управление данными с помощью встроенных в собственный язык объектов намного менее эффективно по сравнению с тем, как это делают MS SQL или Oracle. То, что объекты могут генерировать SQL-код и общаться с СУБД, мало помогает. Для подтверждения этих слов попробуйте взять текст SQL-запроса средней сложности и вставить в MS Query или MS Access, сразу получите сообщение, что построитель не может представить такой запрос, а ведь объект, генерирующий SQL-код, по сути, тот же построитель. Тут мы подходим к понятию «косвенного девелопмента». «Косвенный девелопмент» - это ситуация, при которой разработчик КИС в профессиональной среде разработки строит другую среду разработки (собственный язык), которая управляет или администрирует данные. Толстый клиент. Когда производитель или поставщик КИС говорит о внедрении Заказчику, имеется ввиду, что функционал КИС будет достаточным, чтобы Заказчик начал функционировать на новом ПО, и тут кроется большая проблема, которую видно не сразу. Приведем пример. Представьте ребенка (это наш Заказчик) и портного (поставщик КИС), задача – сшить ребенку одежду. Портной шьет одежду, примеряет и, в конце концов, все готово, сделка состоялось, каждый получил своё. Но вот проходит время, и ребенок начинает расти, ему нужна одежда других параметров, фасонов и предназначения, причем, по условию, Портной может лишь изменять и переделывать ту одежду, которую сшил в самом начале. Тут и начинаются проблемы. Выясняется, что сшить одежду на ребенка и изменять её по мере роста – разные задачи, соответственно, требования к первоначальной конструкции одежды и инструментам Портного много более широкие, чем это кажется вначале. Применительно к КИС, пример означает, что встроенный язык и «толстый клиент» являются ускорителями внедрения (т.е. условиями, достаточными, чтобы сшить одежду ребенку), но при этом становятся тормозом при дальнейшем наращивании и изменении функционала, а перенос таких рисков на более поздний период лишь удорожает совокупную стоимость КИС. Тезис о том, что существуют стандартные бизнес-процессы, которым соответствует КИС, и это предприятие Заказчика должно измениться и подстроиться под эти бизнес-процессы, очень и очень спорен. Поясню опять же на примере. Если внимательно посмотреть вокруг (на людей, животных, деревья и т.п.), то при всей схожести, Вы не найдете двух одинаковых экземпляров. С бизнесом похожая картина, конкуренция заставляет его расти, меняться, перепрофилироваться и т.п.. И с течением времени функционал КИС может так далеко уйти от первой инсталляции, что только применяя именно профессиональные среды разработки и управления БД, можно расширить функционал КИС до требуемого уровня и при этом не порушить саму системность КИС, таким образом будущее становится более определенным. Но вернемся к теме статьи…
Как традиционные КИС влияют на школу программирования?
Итак, с одной стороны, очевидно, что для сопровождения традиционных КИС требуется армия специалистов по языкам этих КИС. С другой стороны, с точки зрения профессиональных средств разработки, эти языки весьма слабы и напоминают по своей мощности процедурные языки 20-летней давности. Всё это очень снижает культуру самого программирования. Зачем программистам знать принципы объектно-ориентированного программирования? Какие такие нормальные формы? Зачем писать красивый и устойчивый код и что такое рефакторинг кода? Как документировать функционал и как управлять проектом? Всё это совершенно не нужно, потому что, чтобы устроиться на работу на приличную зарплату, достаточно знать лишь синтаксис того языка, который использует КИС работодателя. Получается замкнутый круг: Традиционные КИС не предоставляют средств профессиональной разработки. Соответственно, требования к программистам снижаются и сводятся к знанию синтаксиса встроенных языков. Как следствие, снижается и общая культура программирования, а значит, развивающийся бизнес не может рассчитывать на системное сопровождение своей КИС и довольствуется лоскутной автоматизацией. В результате такого падения культуры программирования огромное (по разным оценкам от 50% до 80%) количество проектов попадает в категорию «неудачных».
Таки надо что-то делать!
Я ни в коей мере не хочу принизить заслуги уважаемых производителей КИС. Я лишь хочу обратить внимание читателя на то, что рекламные буклеты и суровая правда жизни – вещи разные, что времена меняются и концепции построения КИС также нужно менять.
Что такое «прямой девелопмент»?
«Прямой девелопмент» - это ситуация, при которой разработчик КИС строит эту КИС в профессиональной среде (скорее, средах, например, DELPHI + MS SQL), затем предоставляет клиенту (или сопровождающей фирме) исходный код и дальше сопровождение КИС идет прямо в той же среде, что и разработка (отсюда «прямой девелопмент»). Именно «Прямой девелопмент» является наиболее предпочтительной концепцией развития современных КИС. Другими словами, на мой взгляд, если КИС будут строиться в соответствии с концепцией «Прямого девелопмента» и поставляться с открытым кодом выигрыш для бизнеса очевиден: - Заказчик будет иметь возможность расширять/изменять функционал по своему усмотрению, при этом производительность труда IT специалиста существенно повысится (на то они и профессиональные среды) - у производителя КИС отпадет надобность создавать свой внутренний язык, снизится количество ошибок, повысится качество продукта, удешевятся затраты на производство ПО. «Прямой девелопмент» forever! - спрос и требования к высококлассным IT-специалистам возрастут, их станет больше, появится конкурс, возможность выбора. Как следствие, культура программирования возрастет, IT-проекты станут устойчивее, дешевле, надежнее и будут работать на бизнес, помогая осуществлять основную для бизнеса задачу – зарабатывать деньги. Ко всему прочему, по стандартным языкам программирования написана масса книг, они преподаются в большинстве технических вузов и Заказчик может быть уверен, что он найдет требуемого специалиста и, таким образом, будет застрахован от некомпетентного поведения IT-сотрудника или внедряющей компании.
Вместо послесловия
В этой статье я пытался взглянуть на сложившуюся ситуацию на рынке КИС и их связь с культурой программирования под иным, чем это традиционно принято, углом. Видение, которое высказано в статье – это лишь видение мое и Компании «Софтоматика». Мы не претендуем на истину в последней инстанции, но размышляем над тем, как можно поднять культуру программирования в стране. Если читатель получил пищу для размышления или взглянул на проблемы иначе, статья удалась. Спасибо за внимание. Теперь можно набрасываться, багроветь в гневе и рвать статью, дочитав до конца (удалять файл, закрывать окно браузера) или благодарить.
©NEWS
© Галактика, 2006
© Издание 12NEWS (ИП Маринин А.Л.), 2006
