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

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

Но иногда им все‑таки хочется большего — как‑то повлиять на то, чем они, собственно, пользуются. Речь, разумеется, не о тех пользователях, которые от нехрен делать втыкают в телефон, судорожно пролистывая цветастые картинки на уровне двадцать пятого кадра. Нет, мы говорим о профессионалах своего дела, замотивированных и ответственных, каждый день с девяти до пяти сидящих перед монитором, на который выведены кнопочки и иконки большой и сложной системе. В ней, особенно если система соприкасается с постоянно осциллирующими бизнес‑требованиями постоянно возникают мелкие задачи, которые программисту делать лень. Какие‑нибудь условия получения скидки клиентом в зависимости от цвета волос, года рождения и фазы Луны в этот момент. Интеллектуального интереса они не представляют никакого — обычно это длинная цепочка if‑elsif‑else. Компилировать заново мегабайты сложного кода ради такой ерунды даже как‑то стыдно, отладка потом предстоит долгая и муторная, в общем, это те задачи, от которых хочется сбежать подальше.

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

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

С точки зрения программирования в этом деле — делегировании некоторых полномочий — особых сложностей нет. В конце концов все сведется к каким‑нибудь полям ввода, содержимое которых потом попадет в таблицу базы данных, откуда и будет каким‑то образом интерпретироваться.

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

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

С другой стороны, он не должен быть совсем уж универсальным и не дай бог полным по Тьюрингу, потому что это тянет за собой длинный хвост всем известных в нашей профессии проблем — проклятые ошибки с последующей долгой отладкой и молитвами при перезапуске.

И он должен быть, конечно же, специализированным — под конкретные задачи и круг должностных обязанностей. С использованием известных и понятных пользователю метафор и соответствующей терминологии.

Первое, что приходит в голову, — засунуть в готовую систему Javascript и отобразить на его объекты соответствующие внутренности. Решение, конечно, убогое. Наш пользователь — не программист и не собирается им становиться, у него уже есть своя любимая профессия, и менять ее он не собирается. Ему совершенно неинтересно разбираться, с какой радости typeof null получается вдруг объект и отчего знак «равно» пишется по два раза, будто при заикании.

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

Нет, нет, нет, никакой императивности, ну или совсем ее по‑минимуму, если без этого никак не обойтись. Наш язык должен быть чисто (или хотя бы в основном) декларативным — вот так я хочу, а как это сделать — придумай сам.

Кроме того, представление программ в виде текста народным массам по большому счету чуждо. Читать любят немногие, а уж вычитывать, то есть замечать опечатки, — так и вовсе никто, кроме программистов, корректоров и горстки граммар‑наци. Впрочем, даже последние тут не пригодятся, поскольку им будет не с кем ругаться и некому демонстрировать свое превосходство.

Нужна визуальная форма. Поэтому второе, что приходит в ту же самую голову, — это Scratch с милым котиком, призванным смягчить шок вкатывания в IT. Да, но нет. Скретч — это тоже самое программирование, хоть и визуальное. От текстового файла оно отличается только тем, что все ключевые слова заключены там в красивые рамочки разных цветов. Но наши пользователи, напомню еще раз, не программисты, не дети программистов, и обучаться программированию в их ближайшие планы не входит.

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

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

1. Таблица

Тут и рассказывать особо нечего. Если у вас есть какая-то величина, которая по сложным и нелогичным законам зависит от одной-двух остальных, то ничего лучше обычной таблички нету. С первого взгляда все понятно, доступно и ничего не надо объяснять.

От вас как от программиста требуется только отобразить описательные выражения на внутренние переменные, а дальше как хотите — можете интерпретировать эту табличку на ходу, можете скомпилировать ее в код из месива if и switch.

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

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

2. Пошаговые планы

Бизнес очень любит выдумывать всякие акции для клиентов вроде «заплати за две порции и получи вторую за полцены», а вот программисты их реализовывать совсем не любят. Опять же — неинтересно и муторно. Вот отличный кандидат для передачи в твердые и уверенные руки продвинутых пользователей.

Ментальная модель здесь подходит такая — делим выполнение на отдельные шаги, состоящие из последовательности действий. Шаг «Старт» запускается первым, остальные шаги или планируются через определенное время, или срабатывают по возникновению каких‑то внешних событий.

Акции часто ограничиваются какими‑то условиями, поэтому пригодится еще соответствующее поле.

Тут уместно будет привести картинку редактора акции, что будет понятнее тысячи слов.

Как видите, фактически у нас теперь есть GoTo и If условий, следовательно, язык получился полный по Тьюрингу — с условиями и циклами. Но не волнуйтесь, мы его урежем. Чтобы избежать падения в смоляную яму надо всего лишь ограничить и условия, и действия заранее определенным списком. Ну и вообще‑то у нас ведь нет переменных. Так что много и сложно юзера не наворотят, даже если очень захотят.

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

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

3. Мешок фактов

Представьте себе службу техподдержки какого‑то большого предприятия, например, провайдера Интернета. Звонит клиент с обычной жалобой «у меня не работает». «Что именно не работает?». «Все!».

Получив эту исчерпывающую информацию, оператор должен быстро (клиент висит на линии и нервно дышит в трубку) понять в общих чертах, что происходит, для чего просмотреть множество сведений, обычно разбросанных на паре‑тройке разных экранов. Проблема может быть в закончившихся на счете деньгах (экран «Финансы»), в сломавшемся оборудовании клиента (экраны «Текущий трафик» и «Прошлый трафик») или в поломке на самой линии (экран «Сообщения от ремонтных бригад»).

Все необходимые сведения в системе есть, но хорошо бы их свести как‑то воедино. Да вот беда — операторы бывают разные и с разными обязанностями, и смотреть им приходится потому в разные стороны. Вот бы хорошо было, если бы каждый из них (или хотя бы самый продвинутый) мог соорудить себе помощника, да потом еще оперативно его менять по своему вкусу и новым требованиям.

Что ж, этой беде можно помочь.

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

Но вот тут‑то они будут в самый раз. Бинго! Ведь метафора у них очень простая — есть мешок фактов, лежащих в совершенном беспорядке. Например, «Клиент=145», «Текущая скидка = 2», «Состояние линии = сломана» и т. п. И есть длинный‑предлинный список условий с привязанными к ним действиями. Условия независимы друг от друга, срабатывают они не по порядку, а ровно в тот момент, когда обнаруживаются их факты.

ЕСЛИ <Cостояние линии>="сломана" ТО Сообщить оператору: "Ничего не работает, так и скажите, пусть ждут"

ЕСЛИ <группа клиента>="VIP" И <Клиент>!=5 ТО Сообщить оператору "Любимый пользователь, разговаривайте особо вежливо"; Послать начальнику отдела сообщение "Важный клиент {{Клиент}} жалуется на качество связи"

Ну и так далее, вплоть до конкретных заказчиков, для которых нужны особые тонкости.

Если от оператора требуется какая‑то дополнительная информация, то можно еще добавить отдельные поля ввода, сделав их содержимое автоматически добавляемыми в мешок отдельными фактами.

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

Кстати, на той же основе вполне можно, вспомнив истоки, запилить и мини‑экспертную систему, перенеся в нее часть неявных знаний работников.

Что же касается реализации этого самого мешка, то прошедшие десятилетия все‑таки даром не прошли. Экспертные системы хоть и растеряли свои вселенские амбиции, но выжили словно ящеры в царстве млекопитающих, и скрываются теперь под скромным именем Business rules. Под крышкой там все те же старые добрые сети Рете или их коллеги. Нечто грандиозное вроде CLIPS или DROOLS, наверное, брать для своих проектов не стоит, но что‑то поменьше можно найти практически для любого языка. Например, если вы используете JS, обратите внимание на проект rools.

А я на этом раскланиваюсь и желаю всем творческих успехов.