После публикации

Поводом к написанию этого письма послужила статья Максима Костюченко "RAD-системы: Clarion и Dеlphi" в одном из последних номеров газеты. Ничуть не умаляя достоинств системы Clarion и фирмы TopSpeed, а также группы Йенсена, являющейся ядром этой фирмы, хотелось бы немного поспорить с автором, и не столько поспорить, сколько поразмышлять над некоторыми "особенностями национального программирования", уж простите за избитую игру слов.

Начать же хотелось бы не со статьи, а совсем с другого, с технологий программирования как таковых. К сожалению, информацию о них найти крайне сложно. А без этого, без понимания идеологии системы, использовать заложенные ее разработчиками возможности на полную мощность практически невозможно. (Вообще, на эту тему весьма рекомендую почитать журнал "Открытые Системы", в частности статью Н. Вирта, а также замечательный во многих отношениях сервер CITforum). И весьма грустно читать статьи о новых продуктах, о работе с ними, где даже не упоминаются элементарные понятия и правила работы с такими системами. А может, я сгущаю краски, и все прекрасно знают, что такое объектные и реляционные базы данных, различия между ними, первичные ключи, таблицы и представления, хранимые процедуры, что SQL - это не язык программирования, что дает объектно-ориентированнное проектирование, что такое CASE, и т.д.? Увы, не уверен... Я не имел в виду обычных пользователей компьютера, я имел в виду именно тех, кто профессионально занимается программированием или считает себя таковым.

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

"Структурное программирование", "объектно-ориентированное программирование", "визуальное программирование" и т.п. ставили целью не "как" программировать, а "как удобнее и лучше". Потому и отшумело в свое время много споров по этому поводу во всем мире. Потому что "удобно и легко" - понятия достаточно субъективные, а "скорость и качество" - объективные. Но, кстати, ни одна технология не избавляет от знания рекурсивных алгоритмов и прочих азов программирования. Также как и их знание еще не говорит о том, что человек сможет написать законченную программу быстро и она будет стабильно работать и выполнять то, что нужно. (Естественно, под программой не имелся в виду расчет факториала). Итак, к чему же все это говорилось? Да, собственно, к тому, что сегодня мало владения инструментом, будь то Delphi, Visual C, Clarion или что-либо другое. Без понимания особенностей их предназначения, основных принципов организации работы в них с их помощью будет писаться что-то вроде очередной ХХ-ой версии "учета рукавиц и веников", только "под винды", и работать оно будет столь же стабильно и быстро, как та самая "винда". Да и еще, те самые "винды" написала Microsoft, а, извините, "рукавиц и веников" по стране несколько десятков как минимум.

Но вернемся к сути разговора. Статья была озаглавлена "RAD-системы: Clarion и Dеlphi". Как мне кажется, это предполагает, что автор понимает, что такое RAD-система, а также работал с системами Clarion и Delphi. (В противном случае, это будет говорить о качестве предоставленной им информации). Как когда-то говорил мой школьный учитель информатики: "Дети в школу ходят ПО ПОРЯДКУ!", вот и мы по порядку попробуем разобраться в этой статье.

Итак, что такое RAD-система в двух словах.

"Современные системы быстрой разработки приложений RAD (Rapid Application Development) - это новый этап в развитии программных средств, еще один шаг по пути, ведущему к избавлению программиста от низкоуровневого кодирования." Такая справка была дана в статье. Скажите честно, Вы поняли, что же это за страшный зверь? Кроме того, что к нему относится Clarion и Delphi? Я, например, нет. Какой этап, после какого, каким образом этот этап нас должен привести к тому самому счастливому избавлению? (Отдельный вопрос - произойдет ли оно вообще когда-либо). Вообще говоря, под RAD-системами принято понимать такие системы, где задают входные параметры, определяют выходные, а сама система генерирует исполняемый код. Но это в идеале. На практике, как Вы понимаете, дело обстоит несколько иначе. Сейчас к таким системам относят системы визуального программирования, т.е. те, в которых программист с помощью имеющихся в распоряжении компонент "собирает" программу, устанавливая взаимосвязи между объектами, их свойствами и т.д. И делает это с помощью "визуальных" средств, то есть таская объекты и компоненты мышкой по экрану. Впрочем, никто не мешает ему то же самое проделать с помощью написания кода. Да без этого, как правило, и не обойтись. Но, что самое ценное в этих системах, на мой взгляд, они предназначены и для использования в рамках RAD-технологии (методологии) при разработке программ. А сама RAD-технология представляет собой один из подходов к организации работы программистов над проектом, позволяя в достаточно краткие сроки выполнить заказ. Собственно здесь и начинается самое интересное. Сразу хочу оговориться, что я не претендую на полное академическое описание методологии. Для этого есть стандарты и прочее. Кроме того, подходов к реализации данной технологии существует несколько, да и сама она появилась не сегодня и не вчера.

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

Заметьте, наличие в группе руководителя и аналитика - ОБЯЗАТЕЛЬНО! Это те люди, от которых зависит разработка модели системы и т.д. В эту технологию прекрасно вписывается и использование CASE-средств проектирования, разработки и совместной работы над проектом, что в данном случае просто необходимо (кроме того, большинство из них программно связано с имеющимися RAD-системами разработки), как и необходимо иметь соответствующую RAD-систему программирования, позволяющую быстро собирать прототип, а затем его модифицировать, согласно требованиям модели, сделанной аналитиком. Естественно, поскольку на каждую итерацию ставятся жесткие сроки исполнения, то желательно, чтобы система предоставляла некоторый набор готовых к употреблению компонент, "полуфабрикатов", если можно так сказать. Например, модулей создания окон, сообщений, меню и т.д. Вообще-то, набор этих элементов достаточно обширен, и кроме того, никто не мешает создать недостающий, если потребность в нем возникнет. На этом заканчиваю лирическое отступление и возвращаюсь к статье, в которой, судя по названию, должен содержаться сравнительный анализ двух систем, предназначенных для подобных целей. Ну, что ж, посмотрим, что же там написано.

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

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

Впрочем, идем дальше, насчет оценки эффективности использования RAD-систем я не стану особо спорить, по той самой причине, что критерии есть, и кроме того, возникает вопрос: неужели при их использовании решение о применении той или иной системы берется с потолка? А может все-таки имеет смысл отталкиваться от решаемой задачи, от уровня подготовки программиста, от требований к вычислительным ресурсам? Хотя, конечно, выбор - дело сугубо личное и субъективное.

"Для создания чего-либо не предусмотренного разработчиками RAD-системы программисту необходимо детально разобраться со структурой созданной ею программы."

Простите великодушно, уважаемый Максим, но я, видимо, что-то недопонял. Что именно не предусмотренного? В смысле кофе сварить или создать еще один объект (модуль, компонент) и включить его в свою программу? И кто проектирует программу все же, программист или система? И как разобраться? В исполняемом коде отладчиком? Все же хотелось бы уточнить, а то ведь опять... "не понимаю..." Если рассматривать с точки зрения вышеупомянутой технологии, тогда совсем как-то все запутано получается. Структуру программы определяет аналитик, он же "проектировщик", и конечно же, некоторые коррективы вносит программист. Так что, вопрос, по большому счету, в качестве проектирования программы и реализации этого проекта программистом, а не в RAD-системе. (Так и хочется вспомнить известный афоризм от IBM: "Человек должен ДУМАТЬ, а машина - работать!").

"Кроме того, такие системы обычно берут на себя все заботы об интерфейсах создаваемого приложения к операционной среде, базам данных, ПО сервера. Для того чтобы создать что-то нестандартное, необходимо знать входной язык RAD-системы, API, ODBC, SQL и понимать все, что она уже натворила."

Вообще-то, мне казалось, что в этом есть несомненное достоинство RAD-систем, и не только. А если программист не совсем понимает, что творит его программа и что творится в ней, и не знает, как обращаться с ODBC, API, SQL, то ценность его, как программиста, весьма сомнительна.

Далее... Насчет родства продуктов я спорить не стану, поскольку история фирм Borland и TopSpeed весьма интересна и примечательна с многих сторон. От себя просто скажу, что в свое время с большим удовольствием тестировал комплект TopSpeed Pascal, C, Modula "в одном флаконе" с совершенно потрясающим оптимизатором кода.

Собственно движемся дальше, насчет языков и т.п. особенно спорить не будем, ибо это опять же вопрос "как удобней". Но насчет того, что "В Delphi все приложение - это неупорядоченный набор форм и модулей (units), что при разработке сложных приложений может затруднить работу", у меня опять возникают вопросы; Вы уж меня простите, но если так подходить к приложению, то то же самое можно сказать про любое приложение, любую программу. Мол, не более чем неупорядоченный набор команд и операторов, особенно если смотреть исполняемый код или пытаться разобраться в исходных текстах чужой системы. А если серьезно, то это зависит от культуры программирования того человека, который пишет программу и от ее проектировщика. Насколько мне известно, все модули и формы документируются на каждой итерации, чтобы к ним можно было вернуться и внести коррективы. И это делается НЕЗАВИСИМО от используемой RAD-системы. То есть, опять же, все дело в организации работы! Тем более если речь идет об одном человеке, то это вина его, а не системы.

Теперь немного отвлечемся от философских аспектов и перейдем к техническим деталям - описанию доступа к базам данных. Видимо, не удастся обойтись без еще одного "лирического" отступления, Вы уж меня простите еще раз. Вообще, понятие "БАЗА ДАННЫХ" достаточно широкое. Для тех, кто хочет действительно разобраться во всех тонкостях, а не только изучить FoxPro или MS Access, рекомендую книгу К. Дейта "Введение в базы данных", а также книги и статьи С. Кузнецова на все том же www.citforum.ru. Итак, мы будем в данном случае рассматривать как организацию доступа к серверам БД, т.е. к системам управления базами данных (СУБД) типа Oracle, Informix, Sybase, MSSQL Server, InterBase и т.д., так и к локальным таблицам (в частности, в виде файлов), находящихся чаще всего на жестких дисках пользователей типа dBase, FoxPro (DBF - формат), Paradox, Excel и т.д. Вообще говоря, фирма Microsoft предлагает единый интерфейс доступа к БД для пользователей и приложений, называемый ODBC. В комплекте с ним идет стандартный набор драйверов для доступа к основным типам БД. При необходимости этот набор можно расширить ЛЮБЫМ драйвером! Как правило, фирмы разработчики СУБД в комплекте поставляют драйвер ODBC к своей системе. Это означает, что конкретному пользователю переживать за доступ к СУБД нет необходимости, к тому же установкой драйвера занимается не он. Далее, доступ к ODBC можно получить, между прочим, и из Microsoft Word, если на то пошло, не говоря уже про современные системы программирования. Теперь вернемся к самой статье.

"Здесь Clarion, безусловно, лидирует. Он снабжен собственными драйверами доступа к БД разнообразных форматов. Среди них как собственные форматы Clarion и Top Speed, так и широко распространенные - ASCII, Basic, Btrieve, Clipper, dBase, FoxPro, Paradox.

Доступ к БД других форматов и удаленным SQL-серверам обеспечивается посредством драйвера ODBC."

Первое предложение я не буду комментировать, посмотрим его аргументацию. Собственные драйверы доступа к БД. Надо полагать, Delphi ничего подобного не предлагает, и в любом случае, это лучше, чем ODBC. Далее, давайте посмотрим на форматы этих файлов. Формата ASCII как такового мне еще не встречалось, то есть в любом случае это какой-то текстовый файл с определенной структурой, иначе как определить расположение полей, строк и столбцов или других необходимых данных. Драйверы для оных вариантов представления БД имеются в ODBC, да и не только. Формат данных BASIC, честно говоря, меня несколько смущает. Видимо, это один из очень редких и эксклюзивных форматов данных, используемый лишь настоящими профессионалами. Btrieve - тоже имеется драйвер ODBC, нужно лишь немного не полениться. Clipper, dBase, FoxPro - все используют формат DBF, который опять же доступен через ODBC.

А теперь далее:

"Delphi обеспечивает доступ к локальным базам только в форматах Paradox и dBase, а также к локальному серверу InterBase. И даже для этого требуются достаточно громоздкие дополнительные компоненты: библиотека методов доступа к БД Borland Database Engine (BDE), Local Inter Base Server (LIS)."

Вот сейчас я нахожусь в тяжких раздумьях. Работавшие с Delphi меня прекрасно поймут. Сказать, что информация неточная - не сказать практически ничего! Итак, во-первых - Delphi обеспечивает доступ не только к Paradox и dBase, а практически ко всему перечисленному для Clarion. И даже более того. Во-вторых, с помощью BDE можно получить доступ (идет в комплекте) к основным СУБД - Oracle, Sybase, Informix и так далее. Для более точной информации я бы рекомендовал автору просто установить у себя BDE и во время установки посмотреть, какие драйверы предлагается установить. Для доступа же к локальным данным, если это не InterBase, LIS вообще-то и не нужен. Ну, и конечно же, ODBC всегда рядом на самый крайний случай. А насчет громоздкости я бы все же хотел услышать, в чем она измеряется в данном конкретном случае и как это соотносится с предоставляемыми BDE возможностями. И, кроме того, Clarion и "свои" драйверы БД - это хорошо, а Delphi, имеющий тоже свои драйверы и "енжайн" для них, - это плохо? Наверно, я опять, по своей привычке, чего-то недопонял.

"Это приводит к тому, что при разработке достаточно простых локальных приложений БД заставляет пользователя осваивать дополнительное ПО."

Простите меня еще раз, но ЗАЧЕМ пользователю осваивать дополнительное ПО в данном случае? При корректно написанном приложении пользователь вообще не должен видеть и заботиться о том, как и с помощью чего это приложение работает! Это раз. Во-вторых, в исключительно сложных случаях установки приложения это делает либо системный программист, либо сам разработчик, если ему не удалось воспользоваться специальными пакетами типа InstallShield.

"В Delphi сложнее осуществлять перенос готовых приложений с одной машины на другую: там, где приложение Clarion вместе с необходимыми драйверами в виде DLL-библиотек занимает одну дискету, приложение Delphi (вместе с BDE и LIS) может занять пять-десять (не говоря уже о сложности его установки)."

Без комментариев. См. выше.

"Вместе с тем при разработке приложений типа клиент-сервер в Delphi обеспечивается доступ к широкому набору удаленных серверов."

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

"Компактность готовых приложений драйверов БД, простота их развертывания, "самодостаточность" системы - все это безусловные преимущества Clarion по сравнению с Delphi."

См. выше. Кроме того, что значит "самодостаточность" в рамках RAD-технологий?

"Даже самая детальная оценка свойств RAD-систем не позволяет сделать вывод относительно удобства применения конкретной системы вообще."

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

И, пожалуй, необходимое послесловие.

RAD-технологии, равно как и RAD-системы, сами по себе не могут служить панацеей от всех бед, как и быть залогом качества программ, и свои отрицательные стороны у них тоже есть. Более того, кроме них существует еще много такого "что и не снилось нашим мудрецам...", и, как любым инструментом, и любой технологией нужно пользоваться исходя из РЕАЛЬНЫХ условий и того, какой выигрыш она может принести. Правда, это мое субъективное мнение. В жизни, как Вы понимаете, все по-другому. Но тем не менее состояние культуры программирования и использования технологий программирования меня наводит на весьма печальные мысли. Не столько то, что большинство ими не пользуется - это полбеды, но еще то, что о них не знают, и это незнание, к сожалению, иногда даже пропагандируется... не в явной форме, а скрыто. Мол, зачем знать какие-то заумные вещи, если достаточно двинуть мышкой туда, потом кликнуть здесь - и вот ты уже "суперспециалист". Впрочем, весьма возможно, что это мое субъективное мнение.

И последнее. Я никоим образом не хотел обидеть автора статьи, и приношу свои извинения, если показался слишком резок и язвителен в своих замечаниях. Равно как и не имею ничего против фирмы TopSpeed и ее продукта Clarion.

Дмитрий Вандич