Может ли кто-нибудь привести пример успешного непрограммиста, 5GL (не то, чтобы я был уверен, что это такое!), Визуального кода, 0 исходного кода или аналогичных инструментов, которые бизнес-пользователи или аналитики могут использовать для создания приложений?
Я не верю, что есть, и я хотел бы оказаться неправым.
В компании, в которой я работаю, мы разработали собственный MVC, который мы используем для разработки веб-приложений. По сути, это сокращенный конечный автомат, написанный на XML (а-ля Spring WebFlow ) для контроллера, и простой механизм на основе шаблонов для представления. Некоторые из преимуществ:
- динамический характер: не нужно перекомпилировать, чтобы увидеть изменения
- уменьшенная «семантическая нагрузка»: в основном, действия в контроллере знают только «если». Поэтому легко научить кого-то разрабатывать приложения.
Текущая тенденция в компании (или, по крайней мере, на уровне управления) состоит в том, чтобы попытаться создать инструменты для платформы, которые требуют нулевого исходного кода, являются визуальными и т. Д. Это хорошо влияет на клиентов (или, по крайней мере, на уровне управления). ) с тех пор:
- они могут быть убеждены, что таким образом им не понадобятся программисты или, по крайней мере, они смогут нанимать программистов конца цикла, которые стоят намного дешевле, чем типичные программисты.
- Похоже, что это связано с уменьшенным риском, поскольку инструмент ограничивает разработчика или пользователя (просто не используйте слово программатор!) В том, что он может сделать, так что меньше шансов, что он может внести ошибку
- Похоже, что это упрощает всю проблему, так как кажется, что в ней нет программирования (общеизвестно сложно). Поскольку приложения загружаются динамически, сложности жизненного цикла J2EE меньше, чем обычно, связанные с компиляцией, упаковкой, развертыванием и т. Д.
Я лично скептически отношусь к тому, что чего-то подобного можно достичь. Решение, которое мы имеем сегодня, имеет ряд проблем:
- Разработчики пишут код JavaScript для обогащения страниц (можно решить с помощью разработки виджетов). Хотя и на стороне клиента, он все еще является кодом, который может стать очень сложным и привести к некоторым трудным ошибкам.
- Уже есть визуальный инструмент, но разработчики предпочитают редактировать XML, так как он быстрее и проще. Для сравнения, я полагаю, что не многие используют плагин Eclipse Spring WebFlow для редактирования потока XML.
- Существует очень плохое повторное использование в решении (основано на копировании-вставке XML). Это сдерживает производительность и некоторые другие аспекты, такие как развитие деловых знаний.
- Были многочисленные проблемы с производительностью и другие проблемы, связанные с неправильным использованием инструментов. Независимо от того, насколько уменьшено игровое поле, всегда есть место для ошибки.
- Хотя платформа, вероятно, более производительная, чем Struts, я сомневаюсь, что она более производительна, чем современные веб-платформы RAD, такие как RoR или Grails.
- Многословность
Исторически в этом направлении были многочисленные неудачи. Идея программ, написанных непрограммистами, стара, но AFAIK никогда не был успешным. На определенном уровне все, кроме силы исходного кода, становится незаменимым.
Сегодня много говорят о DSL , но не как о чем-то, что должны писать непрограммисты, больше как о чем-то, что они могут читать.
Мне кажется, что направление, в котором движется компания в этом отношении, является тупиковым. Что ты думаешь?
РЕДАКТИРОВАТЬ: Стоит отметить (и вот откуда приходит некоторое вдохновение), что многие крупные игроки экспериментируют в этом направлении. См. Microsoft Popfly, Сайты Google, iRise , множество решений Mashup и т. Д.