Выбор критериев оценки



Posted by Сергей Холево, фирма Централь Минск on July 18, 1999 at 07:03:35:

In Reply to: Re: Точка зpения posted by Андpей Акопянц on July 10, 1999 at 12:04:03:

В Вашей статье критериями сопоставительных оценок выступают такие понятия как сетевой трафик, производительность, масштабируемость, транзакция и т.д. Большинство из них связаны с сегодняшним уровнем развития компьютерной техники.

Но технический прогресс порой обладает завидной динамикой и через некоторое время проблемы ограниченности производительности процессоров и пропускной способности коммуникаций могут отойти на второй план. Какие критерии сравнения станут главными?

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

Некоторые из описанных Вами примеров трудностей при разработке клиент-серверных систем носят чисто логический характер и будут возникать при разработке систем, работающих без компьютера на бумаге, на счетах или на аборигеновских бусах.


:Сложности, носящие принципиальный
:характер, никуда не делись - их просто искусно замаскировали,
:точнее, протоптали и заасфальтировали некоторое количество
:обходных дорожек и обсадили их красивыми формочками,
:Help'ами и Wizard'ами.

Но ведь Wizard - это попытка предложить уже готовый, интеллектуально насыщенный, но ограниченный и недостаточно поворотливый инструмент решения проблемы. А может инструмент должен быть проще, гибче, универсальней и надежней?

:Это породило новые поколения инструментальных средств
:разработки, ориентированных на не слишком
:квалифицированного пользователя и стирающих различия в
:разработке настольных и клиент-серверных систем.

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

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

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

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

Программа "Финансы без проблем", которой я пользуюсь уже 8 лет, обладает наилучшей живучестью из всего, что я видел. Лаконично построенная конструкция (счета и начальные условия, дерево видов операций и проводок, файлы-коэфициенты и отчетные формы, формы-истории, факты) достаточно проста, но функционально полноценна. Встроенные средства диалектического контроля, контроля синтаксиса, динамический пересчет данных придают приложениям, построенным на ФБП, удивительную устойчивость. До появления функции [sed..] и [ged..] программа полностью автоматически обеспечивала целостность данных!

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


P.S. В программировании считаю себя дилетантом, поэтому прошу относится ко всему вышеизложенному с должной снисходительностью.



Пpишедшие ответы: