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

Когда я впервые ее увидел, я подумал, что это что-то вроде принципиальной электрической схемы. На самом деле это диаграмма в Visio (12-я из 136), которая содержит один из этих сложных производственных модулей. Позвольте мне перефразировать: диаграмма не представляет рабочий процесс или показывает, как рабочий процесс закодирован, это и есть рабочий процесс. Давайте взглянем поближе.

Хотя так и может показаться, но тот блок не стандартный компонент Visio. Это - "Действие Рабочего Процесса" - самодельный компонент, который был разработан консультантами. Каждый из блоков Действий Рабочего Процесса ссылался или сам был объектом ссылки для других Действий, которые могли быть определены в той же диаграмме Visio, другой диаграмме Visio или внешнем J2EE модуле.
Ядро системы использует эти диаграммы Visio для работы своей логики деловых рабочих процессов и динамической генерации пользовательского интерфейса, и именно через эти диаграммы достигается "Дружественность к Клиенту". Чтобы дополнить или изменить функциональность системы, все что "технически неподготовленный" пользователь должен был сделать, это изменить одну из этих диаграмм. Вот так все было просто.
Очевидно, что ни один пользователь никогда не видел или притрагивался к этим диаграммам. Хотя "теоретически" все было довольно просто для "технически неподготовленного" пользователя, изменение логики рабочего процесса требовало работы высококвалифицированного программиста и сверхмощную рабочую станцию (2-4Гб ОЗУ). И вот тут в дело включился Джон, он умудрился пройти шестимесячную тренировку, необходимую для "программирования" диаграмм.
Последним для Джона было задание по проведению "простого изменения интерфейса". Вот когда он узнал, что чтобы сделать сгенерированный интерфейс более пригодным к использованию система позволяла разработчику использовать JavaScript-овые "tweak файлы". Это в итоге привело к тому, что вся лицевая часть системы стала javaScript-овой: с его помощью делалось все: от отображения строки навигации до проверки входных данных на форме.
А что же было тем "простым изменением интерфейса" в задании Джона, возможно, спросите вы? Оно звучало так: "используйте основанный на JavaScript HTML парсер (/inc/p2/v/hparser.js) для отфильтровывания специфичного для штата Айова текста до того, как он будет передан рендереру страниц (/inc/p2/v/hrenderer.js)".
Оригинал:http://worsethanfailure.com/Articles/The_Customer-Friendly_System.aspx