10 тысяч электронных услуг
Представьте себе портал, с огромным количеством различных пользовательских форм. Например, такой как gosuslugi.ru, где имеется порядка 10 000 электронных форм получения государственных услуг. Представили? А теперь представьте, что людей, которые генерят требования для создания этих форм, то есть заказчиков, примерно в 10 раз меньше чем самих форм — всего-то около тысячи. Ну и, наконец, представьте сколько нужно разработчиков, чтобы сделать около 300 уникальных, со своими тараканами, форм за месяц? Около 100! Причем они должны быть высококвалифицированные, чтобы самостоятельно могли все сделать. Стажеры тут не справятся. А еще каждую форму надо перед разработкой проанализировать, после — протестировать, дать заказчику на приемку, поправить замечания и передать на установку. А это значит, что нужны еще тестировщики и аналитики.
Итого получается около 200 высококвалифицированных человек на месяц. Если предположить, что такую команду и получится собрать, что само по себе почти невозможно, себестоимость такой разработки будет зашкаливать и многократно превышать адекватную на рынке стоимость такой работы. Очевидно, чтобы решить такую задачу, необходимо что-нибудь автоматизировать. Но что?
А что такое услуга?
Чтобы понимать масштаб бедствия, давайте посмотрим что необходимо сделать, чтобы разработать и передать на установку работающую форму получения услуги.
- Разработать пользовательскую форму
Страница(ы) портала, на которой пользователь заполняет необходимую информацию для подачи заявления на получение услуги
- Подготовить XML документ запроса в информационную систему ведомства
Перед отправкой во внешнюю информационную систему данные, которые ввел на форме пользователь, должны быть преобразованы в XML-документ специального формата. Какого – определяет ведомство, которое и является заказчиком разработки услуги.
- Обернуть и подписать XML-документ электронной подписью
Сформированный XML-документ отправляется не напрямую в ИС ведомства, а в специальную шину, которая называется СМЭВ – система межведомственного электронного взаимодействия. Эта система также требует, чтобы входящие XML документы были определенного формата. Поэтому перед отправкой мы должны сформированный на этапе 2 XML документ «завернуть» в другой XML формат по требованиям СМЭВ, и вдогонку еще и подписать электронной подписью портала госуслуг.
- Отправить подготовленный XML документ
Только после всех этих магических действий происходит отправка документа в информационную систему ведомства через СМЭВ.
Автоматизация, Карл!
По-любому надо что-то автоматизировать, скажете вы. И будете правы. Первый кандидат – пункт 4. Надо сделать сервис, который будет принимать на вход готовый к отправке XML и отправлять его на СМЭВ. ОК, готово, сделали. Еще? Да черт возьми, пункт 3! Процесс подписания-то одинаковый всегда. ОК, готово сделали еще один сервис. На входе XML, на выходе подписанный XML. Круто! Больше автоматизации, Карл! Осталось два пункта – создание формы и генерация XML документа по формату ведомства. Хм, а вот и проблема…
Классика жанра
Как можно автоматизировать действия, которые каждый раз разные? Ведь ТЗ на услугу (форма и XML) пишут ведомства, а ожидать однотипность требований в ситуации, когда заказчики соревнуются между собой «кто круче» не приходится.
Было решено, что нужен инструмент, позволяющий:
— максимально просто описать внешний вид формы, форматно-логический контроль для полей, логические связи между полями.
— дать возможность максимально просто на основе заполненной формы сгенерировать XML-документ нужного формата.
Что скажет опытный разработчик про такую задачу? Надо писать фреймворк. Сформировали основные требования к нему и побежали кодить:
– Стандартизация внешнего вида форм, создание набора виджетов
– Легкая кастомизация, настройка виджетов
– Возможность подключать к разработке младших разработчиков и стажеров
– Наследование разработанными ранее формами всех последующих изменений в ядре
– Автоматическая генерация выходного XML документа по шаблону
В качестве технологий было выбрано:
– Слой БД: Oracle Database
– Слой приложений: Java 1.6
– Backend-шаблонизатор: Freemarker
– Frontend-фреймворк: набирающий в то время популярность jQuery
Результаты не заставили себя ждать. Буквально через месяц после начала разработки фреймворка выстроилась достаточно простая схема работы:
- Аналитик получает ТЗ на разработку услуги, валидирует его и при необходимости прорабатывает с заказчиком, после чего передает разработчику.
- Разработчик используя Freemarker набрасывает необходимые виджеты на страницу просто размещая в коде вызов необходимого макроса из ядровой библиотеки виджетов. При вызове указывает необходимые атрибуты виджета: например, код поля, обязательность поля, валидаторы итд. После этого разработчик на основе требований к формату выходного XML, используя тот же Freemarker, формирует шаблон документа, указывая код поля в нужном месте.
- Форма отдается в тестирование, отлаживается после чего передается заказчику на тестирование. После получения ОК от заказчика формируется релиз с готовыми на текущий момент формами и передается на установку.
Какие основные плюсы мы получили? Для разработки самих форм больше не требовались backend и фронтэнд-разработчики. Основное, что требовалось от специалиста – знать синтаксис и возможности Freemarker и уметь пользоваться готовой библиотекой. Для большинства форм таких навыков хватало. Для сложных случаев подключались более опытные разработчики, где могло потребоваться покопаться с html, javascript или наоборот с java. Наиболее опытные занимались разработкой ядра фреймворка, где уже требовались глубокие знания фронтовых и бэковых технологий.
Команда разработки ядра состояла в разное время из 4-8 человек – 2 фронта, 2 бэка, тестировщик и тимлид. Минимальная команда разработки услуг составляла 2 человека – половина аналитика, разработчик и половина тестировщика. Внедрение фреймворка позволило сформировать несколько независимых команд разработки услуг, а в последствии и несколько десятков таких команд, распределенных территориально. Каждая команда могла создавать 1-3 услуги в месяц, в зависимости от их сложности, а time-to-market каждой формы составлял в среднем 35-50 дней.
Таким образом производительность двадцати команд (~50 человек) составляла около 40 услуг в месяц. Неплохо. Но недостаточно. Задача была – 300 в месяц. Наращивать состав команды было уже экономически не выгодно, нужно было более оптимальное техническое решение.
Инновациям дорогу!
Несчетное количество разработчиков и аналитиков проводили дни и ночи перед своими мониторами, кодили, анализировали, звонили заказчикам, потом снова кодили, потом опять анализировали, потом исправляли ошибки и, наконец, получалась готовая услуга. Количество услуг, которые надо было делать, возрастало в геометрической прогрессии и проблема стала очевидна. Требовалось какое-то её решение. Злейшие враги существовавшего подхода были известны: сложность, скорость (точнее, её отсутствие), необходимость технических знаний в области разработки, а также человеческий фактор – чем больше человек участвовало в разработке услуги, тем больше ошибок можно было допустить, как из-за невнимательности, так и по причине недопонимания и «сломанного телефона» при путешествии постановки задачи от заказчика к разработчику.
Итак, задача стояла следующая:
– уменьшить время разработки услуги
– сократить количество человек, участвующих в процессе разработки формы
– еще больше снизить требования к необходимой квалификации разработчиков
Есть такое выражение – «если хочешь чтобы было хорошо – сделай сам». Совершенно неверное с точки зрения проектного управления, но именно оно легло в основу следующего витка развития системы разработки форм.
«Зачем тут вообще разработчики?», спросили мы себя. И действительно, что в нашем случае делал разработчик? Собирал страницу с вызовами виджетов и указывал настройки для них. Почему бы не сделать для этого пользовательский интерфейс? Как в Delphi или Visual Studio.
Забегая вперёд, скажу, что результаты были фантастические, но для этого пришлось потратить некоторое время и усилия. Всем командам разработки мы объявили о прекращении развития старого фреймворка, оставив его на поддержке и занялись разработкой нового.
Отличием в части технологий было строгое разделение модели данных и представления. Бэкенд шаблонизатор больше не требовался, сервер приложений фреймворка представлял из себя набор REST сервисов, с минимальной бизнес-логикой внутри. Основная часть логики находилась на клиенте – в браузере.
Фреймворк состоял из двух основных компонентов: конструктор форм и проигрыватель форм. В конструкторе формы создаются и редактируются в визуальном режиме, а в проигрывателе исполняются – отрисовывается сама форма, работают правила валидации, связей между полями.
Основные функции конструктора:
- Визуальное конструирование формы.
- Настройка форматно-логического контроля (валидации) полей.
- Настройка взаимосвязей между полями формы (например, скрыть какой-нибудь блок или поле в зависимости от значения другого поля).
- Создание и редактирование справочников для использования в выпадающих списках.
- Сохранение и последующее использование собственных виджетов.
- Режим предпросмотра формы.
Основные типы полей (виджеты):
- текстовое поле
- виджет ввода даты
- радиокнопка, чекбокс
- выпадающий список
- поле загрузки файла
- виджет ввода адреса по КЛАДР или ФИАС
- кнопка
- таблица
Основные функции проигрывателя:
- исполнение формы
- выполнение правил валидации, взаимосвязи между полями, промежуточных и окончательных запросов во внешние системы, описанных в конструкторе при разработке формы
- возможность встроить в любое место на любой web-странице
- настраиваемые темы визуального оформления
Основная идея, заложенная в новый фреймворк – абстрагирование от всего, кроме непосредственно экранной формы. Если представить его в виде человека, то он будет из тех, кто говорит: «К пуговицам претензии есть?» Принцип архитектуры очень простой: «Моя задача отобразить форму, выполнить все действия, описанные в конструкторе, отправить данные. Остальное мне неважно, особенно что там с этими данными потом произойдет». За счет такого подхода мы достигли поразительной гибкости, и смогли использовать любые системы-контрагенты, в которые направляются промежуточные и финальные запросы, смогли использовать любую систему аутентификации для обеспечения доступа к формам, встраивать проигрыватель на любую web-страницу любого приложения в любое окружение.
Создание формы в конструкторе выглядит примерно следующим образом:
– Создаем форму
– Выбираем из выпадающего меню нужные нам элементы, размещаем на форме
– В инспекторе атрибутов настраиваем поля, как нам требуется с помощью галочек, кнопочек и списочков
– Настраиваем валидацию полей, выбирая нужный метод проверки или набор методов из списка доступных
– Настраиваем взаимосвязи между полями
– Подкладываем XSLT шаблон формирования результирующего XML документа
– Указываем реквизиты системы-получателя
– Форма готова!
Еще одно огромное преимущество — независимость описания формы от платформы исполнения. За счет того, что форма хранится в виде метаописания в формате JSON, которое лишь описывает состав компонентов формы и их взаимосвязи, но не описывает представление, достаточно один раз разработать форму в конструкторе и ее можно исполнять на любом устройстве, для которого существует проигрыватель форм: например, на платформе iOS или Android, SmartTV и других.
Какие основные плюсы мы получили на втором витке развития фреймворка? Для разработки самих форм больше не требовались разработчики вообще. От специалиста, создающего формы требовалось только уметь пользоваться графическим интерфейсом конструктора форм и уметь написать простое XSLT-преобразование. Этого хватало для большинства форм. Были, конечно, и сложные случаи, тогда обращались к команде разработки ядра, которая по заказу за неделю-две разрабатывала необходимую функцию или виджет.
Таким образом состав команды разработки услуг удалось сократить до 1-го человека, так как никакой разработки по сути не требовалось. Создавать формы смогли аналитики, не имеющие навыков разработки. За месяц один человек смог делать 5-7 форм, а time-to-market сократился до десяти дней. В итоге производительность тех же пятидесяти человек составила уже около 300 форм в месяц. То что нужно!
Вот отзывы нескольких представителей команд разработки услуг после пилотного периода использования нового фреймворка:
Спасибо большое за вашу помощь по конструктору, нам удалось с его помощью закрыть большой контракт. Фактически было реализовано больше 120 форм за неделю с небольшим, выведено в продуктив порядка 110 форм.
С использованием новой платформы разработка идет гораздо быстрее, аналитик может сам полностью контролировать весь процесс и очень быстро вносить правки. Аналитик может сделать сам, практически на 90-100%
Хочу сказать спасибо разработчикам — насколько ускоряет процесс! У меня за день по 4 формы на выходе. С нашими сроками по ХМАО это было бы нереально сделать вручную одному разработчику.
А это отзыв руководителя группы разработки фреймоворка:
Проект запомнился магией, точнее ощущением, что ты волшебник. По крайней мере, реакция многих людей, кому мы демонстрировали продукт, была схожа с реакцией на фокус. Очень приятно, когда у тебя получается при помощи сделанного тобой инструмента удивить скептика. Сразу понимаешь, что ты и твоя команда делают правильные вещи.
Показатели эффективности
| Показатель | Старый фреймворк | Новый фреймворк |
| Размер команды разработки ядра, человек |
4-8 |
4-8 |
| Размер команды разработки услуг, человек |
2-3 |
1 |
| Производительность команды форм/месяц |
2-3 |
5-7 |
| Среднее время разработки одной формы, дней |
25 |
4 |
| Time-to-market, дней |
35-40 |
10 |
| Среднее кол-во форм/месяц при 50 человек |
40 |
300 |
Insight
В чем главный инсайт этой истории? Я выделил для себя 3 главных момента.
- В коммерческой компании любые инновации технологические, организационные или какие-то другие должны быть экономически востребованы и обоснованы.
- Делать задачу «в лоб» в быстро развивающемся IT-мире значит мгновенно потерять конкурентоспособность. Чаще всего из-за завышенной себестоимости и/или сроков.
- Необходимо «точить пилу» (С.Кови «7 Навыков высокоэффективных людей»). Если вы занимаетесь развитием инструментов, то имеете конкурентное и технологическое преимущество на рынке.
А что для себя отметили вы? Будет круто услышать в комментариях. Если тема интересна, то я готов продолжить цикл статей о Конструкторе форм.
Про что ещё можем поговорить:
– О технологической составляющей – архитектура, используемые инструменты, взаимосвязи между компонентами, точки расширения и кастомизации.
– Об организации работы большого количества человек для решения задачи «разработать 10 тысяч услуг», о создании community разработки форм, об обучении, сертификатах, стажерах, студентах и так далее.
– О развитии функций фреймворка и как из узкоспециализированного инструмента для разработки услуг он стал универсальным внутренним продуктом компании для решения различных задач.
Комментарии (19)
antirek
23.07.2015 21:26+1По тексту статьи непонятно: вы разработали портал gosuslugi.ru? Или какой-то другой портал, где также много форм как на gosuslugi.ru?
Почему не ипользовали готовые решения? Form builder'ов пруд пруди, например: www.alpacajs.org/demos/form-builder/form-builder.html Будете ли делиться наработками в open source или эта статья только маркетинг и пиар?
Сколько данных проходит через формы? Т.е. это 300 форм в месяц для сбора трех отзывов в месяц о работе корпоративного сайта? Или вы по 15 млн записей в день пропускаете через заполнение этих форм? Сделайте скриншот, чтоб посмотреть на уровень сложности форм, которые можно реализовать на вашем новом фреймворке.
maximvinnikov Автор
24.07.2015 13:08+1antirek, да инструмент разрабатывался в рамках создания портала gosuslugi.ru, и является одним из его модулей, используемым для создания форм получения государственных услуг.
Насколько часто используются те или иные формы зависит от популярности услуги. Есть услуги по которым более миллиона обращений в месяц, а есть непопулярные — по 2-3 обращения. Но нагрузка на формы это отдельная история, и стоит в стороне от непосредственно разработки услуг.
Готовые решения нам не подошли по нескольким причинам:
— на момент начала проекта (2012 г) таких решений было не так много
— большинство из них платные и не opensource
— мы знали, что потребуются очень кастомные вещи (типа виджета ввода трудовой деятельности при подаче заявления на загранпаспорт), а затраты на кастомизацию доступных на тот момент решений были сравнимы с написанием своего решения
— «зоопарк» технологий в чужих решениях. Мы ограничились стеком технологий, который уже был использован при разработке личного кабинета и каталога услуг портала gosuslugi.ru
Самое главное, из-за чего решили делать самостоятельно — помимо создания/исполнения самих форм, фреймворк должен был соответствовать ряду бизнес-процессов, принятых для построении систем электронного правительства. Например, как я писал в статье — формирование XML определенного формата, подписание электронной подписью, взаимодействие с внешними системами через СМЭВ и так далее. Ни одно существующее решение out-of-the-box нельзя без доработок встроить в эти бизнес-процессы, а доработки = затраты, сопоставимые с разработкой своего.
Объясню на примере формы записи ко врачу
www.awesomescreenshot.com/image/432244/b6860bea12e58cdc6a1df5b25747fa0b
www.gosuslugi.ru/service/10000020298/-10000000603
Сложность этой услуги заключается в том, что в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
Какое из доступных решений позволяет это сделать? Либо никакое либо мы плохо искали.
Мы же смогли все эти настройки вынести в пользовательский интерфейс и с такого рода задачами справляются аналитики за пол-дня.
Что касается opensource — нет, пока не планируем. Возможно в будущемantirek
24.07.2015 15:08Спасибо за развернутый ответ. ГосУслуги — да, это круто! (без тени сарказма и чего-то еще) Реальный проект, делающий взаимодействие с государством проще, пользовался уже неоднократно. В том числе, видимо, и делом рук ваших: )
Но немного не понимаю посыла (темы, идеи) статьи. Сначала вы делаете интригу насчет инструмента:
>> Сколько нужно программистов, чтобы сделать форму для пользователя? Ни одного!
>> Для этого достаточно создать инструмент, с помощью которого создавать формы для web-решений
>> смогут даже домохозяйки.
Затем рассказываете про ваш тернистый путь, а в выводах предлагаете традиционный набор из 3-х блюд из статьи про стартапы. Я лично надеялся получить в конце ссылки на гитхаб на ваш инструмент.
Я понимаю, что пост на Хабре — это не выпускное сочинение, но «завязка-кульминация-развязка» — основа хорошей истории во все времена.
Но все равно было интересно прочитать, особенно от человека, имеющего непосредственное отношение к проекту. Вы, случаем, не знаете разработчиков ГосМонитора и сайта Федерального агентства связи? А то была тут у меня одна история.maximvinnikov Автор
24.07.2015 15:17+1Развязка есть, просто она не соответствует Вашим ожиданиям ;))
Нет, с разработчиками этих систем не знаком
Bronx
25.07.2015 09:52> в зависимости от введенных пользователем данных выполняются запросы во ИС Минздрава и запрашиваются списки значений для других полей. Вроде бы ничего сложного, но по задумке ни одного разработчика не должно участвовать в создании услуги, и все эти взаимодействия должен настроить аналитик.
А аналитик — он программировать совсем не умеет, а умеет только контролы на формы набрасывать и свойства им выставлять? Или всё же он должен быть способен изучить API внешних сервисов, и, если нужно, написать адаптеры, валидаторы и конвертеры данных (возможно выходящие за рамки XML/XSLT) и прочую обвязку? В общем, какой уровень компетенции ожидается от аналитика?
Как у вас обстоят дела с локализацией форм? Дизайнить формы в WISIWYG за пол-дня — это приятно, но однажды наступает момент, когда нужно переводить формы на разные языки и приспосабливать к разным культурам, и тут вдруг оказывается, что после дизайнера контент и вид склеены между собой намертво, и на перевод приходится отдавать не тексты, а полный фарш из разметки, текстов, правил валидации, байндингов, и назад он возвращается нередко в слегка помятом виде (там спецсимволы не заескейпили, там кодировку файла подменили, там служебное слово перевели и тому подобные шутки, которые могут вылезти уже в продакшене). В общем, локализация — это целый процесс, и занимает он уже далеко не пол-дня и требует определённой квалификации. Кто у вас за него отвечает? Аналитики?maximvinnikov Автор
28.07.2015 15:40Аналитик программировать по-умолчанию совсем не умеет, но изучить формат взаимодействия внешних сервисов должен уметь.
Универсальные адаптеры, обработчики запроса/ответа, механизмы валидации, заложены в ядре фреймворка. Для настройки внешних запросов аналитику достаточно написать XSLT описывающие преобразование запросов, ответов, и с помощью графического интерфейса настроить маппинг полученных снаружи значений на поля формы.
Что касается локализации — да, это известная головная боль. Пока такие возможности во фреймворк не заложены, то есть он — одноязычный.
Но если добавлять такую фичу, то сначала переработка ядра — локализация набора виджетов, визуальных элементов, добавление новых свойств к объектам. Это работа группы разработки ядра.
Затем донастройка самих форм — заполнение добавленных языковых атрибутов. С этим уже легко справятся аналитикиBronx
28.07.2015 22:00«Написать XSLT» — это ведь тоже программирование, причём на достаточно вырвиглазном языке с довольно убогими (в сравнении с другими языками) средствами. Мы сейчас тоже занимаемся похожей проблемой, и довольно странно мне, почему считается, что кастомизировать с помощью XSLT — это ок, написать свой собственный зубодробительный XSD для конфигурации с логическими конструкциями, по сути изобретая ещё один недоLISP упакованый в XML и заставляя людей изучать этот псевдо-язык-однодневку — тоже ок, а вот попросить писать подключаемые модули кастомизации на каком-нибудь традиционном языке с богатым синтаксисом и библиотеками (тот же С#, например), с юнит-тестами, блэкджеком и девицами — это ни-ни, аналитик испугается и убежит. Непонятна мне эта предвзятость к обычным языкам и любовь к изобретению собственных.
maximvinnikov Автор
31.07.2015 13:02Человека без подготовки гораздо проще научить писать XSLT-преобразования, чем писать код на любом из языков высокого уровня. Чтобы писать нормальный код надо хорошо знать теорию ООП, паттернов разработки, API живущих рядом модулей итд.
Для написания XSLT всего этого не нужно знать. К тому же, отладка гораздо проще, не надо никаких IDE устанавливать, не надо никаких vcs настраивать, ну и всех остальных разработческих штук.
И все-таки в нашей системе XSLT используется скорее не для кастомизации, а для описания преобразования нашего входного/выходного формата данных к API внешних систем, а они априори различны в нашем случае.Bronx
31.07.2015 19:32Чтобы написать модуль кастомизации, нужно знать лишь основы ЯП и библиотеку, предоставляемую разработчиками. Скажем, нужно поменять логику валидации данных; можно мучаться с XML, а можно использовать какой-нибудь .NET FluentValidator, где такая логика описывается в разы проще. Или написать функцию на JavaScript, если используется node.js. От этапа сборки можно избавиться, если использовать динамическую компиляцию (как в ASP) или интерпретируемый язык (как в ноде).
По поводу «не надо IDE и VCS»: эти аналитики работают «с колёс», т.е. фиксят конфиги в Блокноте на рабочей системе в продакшине? Или они всё же ставят себе рабочее окружение, инструменты, заботятся об организации файлов в проекты, о версионировани, о тестировании и его автоматизации? Если верно второе утверждение, то IDE и VCS — не аргумент, они им по-любому нужны, и аналитик — такой же девелопер, только пожиже. Если же верно первое — я бы такого аналитика гнал бы от проекта ссаными тряпками, ибо это обезьяна с гранатой.
itur
24.07.2015 03:42Статья интересная, но однобокая несколько — форму создать это не хмл править — её учитывать надо, регистрировать, данные с неё куда-то идут, по ним отчёт надо выдать; потом каждая форма это, обычно, начало процесса… да и саму форму разрабатывает не один человек от «нечего делать» а группа какая-то. 1000 заказчиков — это уже кошмар. 10.000 форм — если в них есть смысл, то это очень очень много. И тогда 100-200 технарей это нормально. только к ним ещё надо менеджеров 300+ добавить…
maximvinnikov Автор
24.07.2015 15:09itur форма — один из элементов функции «электронная государственная услуга». Перевод услуги в электронный вид и есть цель создания в том числе формы.
Наше решение покрывает 2 элемента — экранная форма и настройка части бизнес-процесса, которая должна выполняться на портале госуслуг — заполнение и отправка заявления гражданина на получение услуги. Остальная часть — регистрация, обработка данных, подготовка ответа — выполняется уже в информационной системе ведомства, оказывающего услугу.
И тогда 100-200 технарей это нормально. только к ним ещё надо менеджеров 300+ добавить
Одной из целей создания решения как раз и было минимизировать количество технарей, сохраняя при этом производительность.
Каждый человек, разрабатывающий формы общался напрямую с представителем заказчика и сам потом настраивал все как надо на форме. Это сократило издержки на «сломанный телефон» заказчик -> аналитик -> разработчик
capslocky
24.07.2015 06:34Статья подтверждает старый тезис о том, что только закончив проект, понимаешь, как его надо было делать. Далее уже стоит сложный выбор — или продолжать пилить то, что получилось, или переписать проект с нуля. Ваш случай — это удачный пример второго пути.
maximvinnikov Автор
28.07.2015 15:48Век живи — век учись ))
Бывает так, что когда решаешь какую-то задачу даже не представляешь во что она трансформируется через год, два, итд.
Так и было в этом случае — сначала надо было сделать-то порядка 100 услуг, но со временем количество возрастало, а сроки уменьшались. И мы следом за спросом/рынком оптимизировали наши инструменты чтобы оставаться конкурентоспособными.
kefirfromperm
24.07.2015 09:19+1Всё уже украдено до нас. www.orbeon.com
Вообще, для меня это очень странно. На рынке уйма решений для проектирования и заполнения форм. Разработка собственного фрэймворка, в большинстве случаев, приводит к печальным последствиям для компании. Так что решение о разработке такого фрэймворка крайне опасное и глупое.maximvinnikov Автор
24.07.2015 15:22Согласен, что надо пользоваться готовым если если есть возможность, а не изобретать велосипеды. Но в нашем случае задача была слишком специфичная и существовавшие на тот момент решения нам не подошли.
ArthurKushman
В PHP, например, да и не тоьлко такая мода уже давно прошла и генерация форм доступна на любом уровне, в моделях любого фреймворка.
По сему не вижу ничего «инновационного» в этом.
Еще и с XSLT — зачем, когда можно просто писать чистый код, на том же PHP, а на выходе получаешь все готовые элементы формы.
TimsTims
Всё правильно сделали — задача клепать формы — много и недорого. Чистый код = дорогой программист * много времени. Результата нужного не добиться.
Жаль, что поняли вы это не на этапе проектирования, а уже когда запустились.
У нас на работе есть похожая тема — сначала сделали прогу, которая заполняла 10форм и вроде бы больше не требовалось. Но со временем появилась целая куча документов (около 100) и когда происходит массовое обновление — так и хочется застрелиться, потому-что надо было изначьно делать универсальный заполнитель форм, основанный на шаблонах, которые можно было бы легко менять обычным сотрудникам, а не звать программистов по каждому чиху.