Выбор инструмента по “Компасу”
Зерна отольются в пули,
Пули отольются в гири.
Таким ударным инструментом
Мы пробьем все стены в мире!
В. Бутусов
Поговорим о вещах неприятных. Поговорим о вещах болезненных и мучительных. Поговорим о той печальной поре в жизни “софтовой” фирмы, когда становится очевидным, что все дорогие сердцу проекты, которые развивались, совершенствовались и поддерживались в течение нескольких лет, начинают устаревать. Чтобы не получилось, как у Александра Грина: “Они жили долго и умерли в один день”, - надо приступать к принципиально новой разработке, использующей новую операционную среду, новые принципы сопровождения, новые подходы к структурам данных, новое, новое, новое...
Вот тут-то очень часто и обнаруживается, что старое и любимое инструментальное ПО (и даже его прямые потомки) уже не годится. Оно умерло еще раньше, чем базирующиеся на нем прикладные комплексы. Надо искать что-нибудь другое. Но что? И разработчики превращаются в читателей, слушателей, вопрошателей, ищут материалы со сравнительным анализом различных трансляторов, СУБД, интегрированных пакетов, мечутся по семинарам и курилкам, жадно впитывая любые мнения и цифры.
Именно в этом положении оказался отдел программирования фирмы “Компас”, занимающейся созданием бухгалтерского, экономического и прочего управленческого ПО, когда пару лет назад приступил к разработке Windows-версии своего пакета. Поняв после первых же тестов, что CA окончательно загубила Clipper, ибо объявленный его Windows-развитием пакет Visual Objects (а вкупе с ним и продукция третьих фирм, типа FiveWin) предоставляет в полное распоряжение программиста множество ошибок, “дырок” и несуразностей, мы тут же начали искать статьи, в которых сравнивались различные инструменты, пригодные для создания финансово-экономических приложений. Нашли. И выяснили, что они нам ничего не дадут, ибо тестировщики озабочены в первую очередь тем, чтобы дать совет программистам, создающим приложения для конкретного пользователя, а интересы “рыночников” совершенно упущены из виду!
Первые сомнения закрались, когда мы читали описания задач, реализованных в качестве теста. Это были какие-то простейшие одно- двухтабличные базы данных, предоставлявшие пользователю возможности пополнения, корректировки, поиска, сбора элементарной статистики и не требовавшие реализации сложных расчетных процедур или особых ухищрений для наглядной визуализации информации. Затем мы обнаружили, что, как и много лет назад, когда мы выбирали DOS’овскую СУБД (тогда-то и был выбран Clipper), основной упор при анализе быстродействия делается на характеристики выборки данных из базы. Это переполнило чашу, и мы составили свой собственный перечень критериев, на основе которого и провели тестирование инструмента.
Почему? Да потому, что для реализации упомянутых выше тестовых задач вполне достаточно методов визуального программирования, которых не хватает даже для того, чтобы написать приличную бухгалтерскую задачу. Попробуйте организовать на современном “софтверном” рынке продажу чисто “визуальных” программ, которые похожи одна на другую, как две капли воды, - я имею в виду и внешний вид, и функциональные возможности. Можно, конечно, но с каждым годом становится все труднее, так как в условиях ужесточающейся конкуренции нужно, чтобы продукт имел “изюминки”, выделяющие его среди всех остальных.
Еще причины? Пожалуйста! Скорость выборки данных - вещь, конечно, важная. Именно поэтому все инструментальщики “вылизывают” влияющие на нее куски в своем ПО. Одни выигрывают, другие проигрывают, но разница составляет на реальных объемах какие-то миллисекунды. В то же время очень часто не обращают внимания на быстродействие чисто расчетных процедур, которых в приличном пакете великое множество.
Итак, назову некоторые из сформулированных в “Компасе” критериев.
Первый и самый главный - открытость системы программирования. Наличие развитого языка, позволяющего дописывать все то, что не предусмотрели создатели инструмента в качестве стандартных компонентов. Уже стало общим местом (см. результаты конкурса “Бизнес Софт ’97”), что “рыночная” программа должна включать в себя встроенные языки настройки (а порой и программирования), доступные бухгалтеру или экономисту. Но попробуйте-ка создать транслятор визуальными средствами!
Второй - скорость разработки. Понятно, что сравнивать надо опять-таки не в режиме визуального программирования, но все-таки и его учесть не помешает... Приведу пример. Во время вступительного интервью один из претендентов на работу в “Компасе” пел дифирамбы Visual C++. Когда же его спросили, почему тестовое задание он выполнил на Delphi, ответил: “Ну что вы, на Visual C++ это заняло бы гораздо больше времени!”. Это о чем-то говорит, правда?
Третий критерий, тесно связанный с двумя первыми, - поставка исходных текстов компонентов, а также образцов использования языковых структур. Наглядный пример полезности такого критерия - реализация табличного представления информации. Как бы ни были хороши встроенные средства (класс TBrowse в Clipper’е, функция Browse в FoxPro 2.6, класс TDBGrid в Delphi, класс Data Window в PowerBuilder), все равно в них чего-нибудь да не хватает. Ну, например, понадобились нам многострочные заголовки колонок таблицы. В Delphi и C++ Builder достаточно было исправить исходный текст компонента, и проблема была решена. А попробуйте-ка реализовать эту возможность в FoxPro 2.6! Или, например, раскрасить строки таблицы в разные цвета по какому-нибудь критерию с помощью SQL Windows...
Кроме того, самый быстрый способ обучения - это чтение и переделка чужих исходных текстов. Да и сэкономить время при проектировании, найдя подходящий образец, - тоже дело стоящее!
Следующий критерий - удобство при описании “базовых” операций. Уж на это-то автор DataBase Application должен тратить минимум усилий.
Пятый параметр выбора носил скорее рекомендательный характер. Требовался развитый генератор отчетов, причем желательно с исходными текстами.
Причины? Смотри выше.
Немаловажный момент - встроенные средства для вычисления размера текста при использовании TrueType шрифтов и его приведения к нужной ширине колонки печатной формы. Вы будете долго смеяться, но они есть не во всех современных инструментах. А это вызывает большие проблемы при создании так называемых “отчетов переменной ширины”, когда приходится проводить “разрезы” не только поперек, но и вдоль распечатываемого текста. Ох как мучаются пользователи, склеивая потом несколько страниц в широченное полотнище! Но сами ведь заказывают такие формы.
Седьмой критерий - быстродействие расчетных процедур, о котором я уже упоминал выше.
Восьмой - скорость обнаружения ошибок и поиска “обходных путей”. Никуда не деться - ошибки бывают везде!
Я не буду говорить о менее болезненных или более очевидных вещах, таких, как доступ к API, OLE2 и DDE, поддержка SQL, возможности проектирования intranet/Internet-приложений (хотя считаю, что для большинства управленческих подсистем оптимальной является привычная клиент-серверная или файл-серверная технология, но для некоторых задач, например “Заказ готовой продукции”, идеально подходит Internet). Думаю, что перечисленного вполне хватит, чтобы составить представление о выборе “по "Компасу"”, а также дать пищу для размышлений тем, кто еще не влипал в ситуацию, когда постоянно вспоминается цитата: “Погубит тебя богатство выбора!”.
Лучше скажем пару слов о тестовых задачах.
Их в процессе выбора использовалось ровно две. Первая - сложная многопараметрическая инструментальная функция, объект или класс для реализации все того же табличного представления информации со специфическим “компасовским” интерфейсом для задания критериев поиска и фильтрации данных, подсчета итогов, активной помощи при вводе с клавиатуры, контроля по справочникам и т. д. и т. п. Мы прекрасно понимаем, что при разработке больших проектов никто не начинает сразу писать “склады”, или обработку журнала хозяйственных операций, или что там еще? Сначала на базе инструментального пакета создается инструмент следующего уровня иерархии (часто это собственные CASE-средства “софтверной” фирмы), а только потом в игру вступают чистые проблемники. Вот тогда-то и приходит время для реализации всяческих красот типа многострочных заголовков или раскрашивания таблицы в разные цвета и для проверки, сможем ли мы создать на основе тестируемого пакета свой фирменный инструмент.
Дорогая проверочка, скажете? Но мы уже успели к тому времени “пролететь”, выбрав для выпуска небольшого Windows-проекта такой, казалось бы, знакомый после Clipper’а FoxPro 2.6, в результате чего не смогли реализовать некоторых вещей, “за пять копеек” прописанных в DOS’овской версии! Опыт этот, кстати, произвел такое потрясение, что ведущие программисты фирмы наотрез отказались хотя бы краем глаза взглянуть на следующие версии FoxPro.
Вторая тестовая задача была намного проще. Она предназначалась для проверки быстродействия и состояла из разветвленного по IF циклического вызова “пустой” функции с несколькими десятками параметров и набора арифметических операторов. Почему? Бывалые программисты, поработавшие еще на IBM 360, помнят, как при выпуске оптимизирующего компилятора с языка PL-1 разработчики на два порядка ускорили обработку вектора параметров по сравнению с классическим F-компилятором, где она была выполнена крайне небрежно. Думаете, на ошибках учатся? Последние испытания показали, что, например, в Delphi такая тестовая функция работает на порядок быстрее, чем в компилированном варианте PowerBuilder’овского текста (в интерпретируемой версии Р-кода разница возросла еще в несколько раз). Весьма существенные цифры для большого проекта, где вызов на вызове сидит и вызовом погоняет!
В результате для перспективного проектирования “Компас” выбрал C++ Builder (конечно, этот пакет выигрывал не по всем параметрам, но на то и существует понятие многокритериального отбора). Удобства Delphi плюс богатые возможности действительно профессионального языка программирования.
Конечно, первая версия, как всегда, чревата ошибками, а Borland с апгрейдами не спешит, но... ошибки оказались быстро выявляемые и “обходимые”.
Реализовать с помощью этого инструмента можно практически все, что нужно для хорошего управленческого комплекса, и достаточно быстро!
В общем, мы этап выбора благополучно миновали. А вы? Надеюсь, что эти заметки хоть в чем-нибудь помогут нашим коллегам и следующая статья на эту тему (уже не моя!) будет начинаться словами: “Поговорим о вещах приятных”.
Игорь Якобсон - главный эксперт ООО “Компас” (С.-Петербург). К нему можно обратиться по адресу: sensr@kompac.spb.su.
Игорь Якобсон
