系统可以100%进行数据驱动吗?


44

我的新老板已经在这个项目上工作了很多年。我只来过这里几个星期,但我不确定是否有可能。他想设计一个“ 100%数据驱动”的系统。

因此,如果我们输入足够的数据,则可以定义并生成任何应用程序。我至少设法让他承认某些事情,例如用户,或者应用程序应该具有预定义的值,但是他喜欢系统结构,用户界面和逻辑都存储为数据的概念。

这里有一些简单的演示,他基本上重新发现了一些面向对象编程和基本模板系统的简单想法,但总的来说,我认为这个目标实际上是不可能的。

我不知道如何在不使系统变得如此复杂以至于无法进行实际编程的情况下使用数据定义逻辑。

我认为从理论上讲,这不是因为解释数据的内容最终需要完整描述应用程序,因此您只是将问题上移了一层,甚至没有任何净收益。

这样的100%数据驱动应用程序有可能吗?


4
仅当您编写自己的编程语言时。如果您确实需要编写许多类似的应用程序,则可能需要更好的库,更好的体系结构,或者在极端情况下需要使用特定于领域的语言(DSL)。
Michael K

6
我认为您需要以更特定的方式定义“数据驱动”的含义。
GrandmasterB 2014年

9
在某些语言(如Lisp)中,代码和数据之间没有明确的界线。这可能会导致数据库表或列包含要对与之并存的数据执行操作的指令,但是我不确定这是否在作弊。
罗布

20
当然可以!数据作为Java源文件存储在文件系统上。我们只是编译和部署,然后您就可以开始了。100%的灵活性,100%的数据驱动。
杰里米·斯坦

6
@JeremyStein击败了我。我要说的是我的数据存储在Subversion中,而对“配置”的更改是通过持续集成系统和其他部署过程来应用的。
Mindor先生2014年

Answers:


46

您的老板应阅读以下文章:Bad Carma:“视觉”项目,有关内部平台效应或第二系统效应的警示性故事。

抽象

我们这些从事信息技术(IT)工作的人都参与了一个重要的事情不正确的项目。我们知道,大多数人都知道,但是没有人能够以令人信服的方式来解决这个问题。

这个故事是关于这样一个IT项目的,这是我经历过的最壮观的失败。结果导致完全解散了一个中型IT部门,并最终导致了在成长中的行业中成长中的公司的毁灭。该公司(我们称为“新贵”)是一家成功且盈利的订阅电视业务。

该项目发生在1990年代初期,它是一个定制的订单输入和客户服务应用程序,与现在称为“客户关系管理”或CRM的内容非常相似。该系统的核心功能包括:

  • 订单输入和库存
  • 客户服务,服务台
  • 总分类帐,应收帐款,开票和应付帐款

该应用程序名为“ Vision”,名称既是其正式宣布的对Upstart的承诺,也是对其架构师的一次自我赞美。该应用程序具有创新性,其灵活性足以适应将来业务的任何变化。不仅是对业务的可预见的未来变化,而且对任何形式的业务也绝对没有任何变化。这是一个了不起的主张,但Vision旨在成为有史以来最后构建的应用程序。它通过完全由数据驱动,提供无限的抽象以及使用当时最先进的面向对象编程技术来获得这种完全的灵活性。

像许多旨在创建关键任务应用程序的项目一样,开发工作跨越了两年的时间,比最初计划的要长大约一年。但这是可以接受的,因为这是可以永久使用的应用程序,可以适应将来的任何需求,并提供无限的投资回报(ROI)。当该应用程序最终“上线”时,公司中几乎每个人都对其进行了大量投资,以至于公司的命运取决于其成功。

但是,在整个项目出现故障的情况下,在互联网泡沫时代,运行跨国公司核心业务的关键任务应用程序无法获得成千上万个“ .com”公司所展示的那种快速熄火的豪华体验。在Vision投入使用的一个月之内,对所有人(除了在其架构方面承担最重的责任),所有人都认为这是一次失败。

也可以看看

http://en.wikipedia.org/wiki/Inner-platform_effect


3
+1内部平台效果。我认为这个TDWTF总结得很好:thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx

4
当人们没有看到编写少量代码的成本远低于构建整个平台的成本时,这很有趣。
brianfeucht 2014年

9
@brianfeucht:无限可配置平台的想法很诱人。
罗伯特·哈维2014年

1
内部平台效应使我想起了诸如Guava之类的Google库,其中的代码不是使用if语句,而是填充了大量的Predicate实例。那太可怕了。
luke1985 2014年

3
@RobertHarvey,构建过程很有趣。只要我不必支持最终用户;)
brianfeucht 2014年

17

答案是肯定的,可以创建一个完全由数据驱动的系统,是的,通常这是一个非常糟糕的主意。

完全数据驱动的程序是其中所有逻辑和配置都由存储的值处理的程序,该值在另一种情况下将被视为数据。1980年代生产了许多4GL产品,这些产品提供了使用输入多种表格,存储在表格中并可以通过报表访问的数据项生成报表,表格,表格和逻辑的功能。我曾经将这样的系统称为“按数字绘制”,但现在看到它已被称为“内部系统”效果。好名字。

创建这些系统的人正在尝试(不管他们是否知道)创建一种新的编程语言。由于他们没有技能,所以他们做得不好。从JVM / CLR的角度来看,已编译的Java / C#程序只是数据。在这种情况下,它做得很好。无论哪种情况,无论语言是什么,都需要程序员使用该语言。

我知道有一种特定的方法可以使这项工作。您可以构建所需的每个组件的框架:表单,报表,表格等。您提供一种通过设置数据项来配置这些组件的各个部分的机制。对于一组选定的功能,您需要做出决定并将其冻结到系统中,并且特别是拒绝配置这些功能。

您还将实现一种能够对逻辑操作进行编码的语言。我的建议是使用现有的语言,例如lua或Python。您可以在需要逻辑操作的任何地方嵌入这段代码。

通过这样做,您可以大大减少实施每种表格,报告,表格等所需的书写量。该系统似乎是数据驱动的,但仅限于一点。

此时,您刚刚实现了一个新的4GL。如果您碰巧成功完成此操作,请告诉我。大多数人悲惨地失败了。我将是第一个祝贺您取得成就的人。


2
不错的文章。SAP(ERP系统)是这种系统的经典示例。您无需在其中进行编程,而是对其进行“配置”。它是如此复杂,无法完成任何重大工作,以至于它围绕着它创建了整个咨询行业。
Tonny

@Tonny:谢谢。我没有使用SAP的第一手经验,但是我知道SAP / R3和ABAP接近此描述,并且是战争故事的主要产生者:错在哪里以及预算被炸毁了多少次。仍然使公司赚了很多钱。
david.pfx

作为拥有SAP的第一手经验的人,我想发表评论……(现在有人可以告诉我去庇护的方式吗?)
shawty 2014年

6

我认为您基本上是正确的。语言运行时已经是一个完全灵活的数据驱动系统。它接收一条数据(程序),并使用它来确定它应如何作用于其他数据。它甚至可能有一个多用户方案来存储代码,以供其他程序重新使用(从包含路径到适当的安装管理)。

粗略地说,“脚本语言”是一种语言运行时,其中此代码输入是人类可读的。编译器在用户和运行时之间增加了一个额外的步骤。诸如Malbolge 和APL之类的“笑话”语言不需要任何形式的人类可读性。但这在一个层面上都是一样的,而且人类可读性并不意味着所有潜在的用户都有阅读或编写它的技能,或者可以期望开发它们。

充分的理由说明为什么您通常不直接向最终用户公开语言运行时。主要的是消除灵活性会增加便利性。

如果我想输入SO帖子,我只想输入。我完全有能力编写一个C ++程序来输出它,但是我不会使用公开C ++程序编辑器而不是常规文本框的Web浏览器。不了解C ++的人不仅不会使用浏览器,而且不会使用。

如果我想配置某些业务参数,那么我并不一定要使用图灵完备的规范语言来做到这一点,即使我这样做,也可能与在其他任何编程中“硬编码”那些相同的业务参数没有区别。语言。您仍然需要考虑您所写的内容是否意味着您想要的意思。您仍然需要测试更改是否正确。也就是说,对于那些具有一定编程技能的人来说,他们仍然需要编程技能来完成这些琐碎的事情,这些人确实具有编程技能,他们为您配置(“使用”)准备了专门的子系统(“应用程序”)。

因此,如果您打算使用100%数据驱动的系统,只要提供正确的数据就可以执行任何操作,那么您有两个问题要问自己:

  1. 我们是在发明编程语言吗?
  2. (为了我们的目的)我们的新编程语言是否会比我们现有的更好,并且我们会根据需要支持和开发它吗?

有时答案是肯定的,并且您编写了某种特定于域的语言。如果您是Sun / Microsoft / Stroustrup / van Rossum /其他许多人,甚至是真正的通用编程语言。有时答案是否定的,而您却具有“内部平台”的作用-经过大量的努力和反复试验,您最终得到了一些回报。如果幸运的话,它只比您使用它编写的编程语言稍差,并且使用起来并不容易。

某些语言比其他语言更难或更容易使用,特别是如果它们专门用于R之类的目的,那么某些用户会发现它们更加容易。您可能不会做的是从根本上简化常规应用程序的编程。在任何时候,世界上可能有几个人/组织有这样做的潜力,但是您的老板/公司必须诚实地考虑是否包括他/您。

游戏中经常使用一种技巧,即将Lua绑定公开给游戏引擎。这使设计人员可以使用相对简单的语言进行编程,但在性能或访问引擎或平台的特定功能所需的地方,仍可以聘请“真正的”程序员。就引擎而言,最终的Lua脚本是“数据”。与配置数据相反,它们并不需要全部包含您称为“逻辑”的内容,并且通常它们几乎可以定义所有情节和环境,而不是整个游戏过程。这不是100%的数据驱动,当然也不是100%的无错误,但这是一个有趣的实际折衷方案。


说得好。与100%数据驱动最接近的是系统是一种编程语言。我们已经拥有了这些数据,所以现在我们的工作就是以文本语句的形式向其中之一提供实际数据,以使其提供我们当前所需的实际功能。
RBarryYoung 2014年

4

我曾在一家以目标为目标的公司工作。SQL片段存储在数据库表中,在运行时读取并执行。可以想象,性能太差了,而且错误频繁发生。没有堆栈跟踪或任何其他使生活变得轻松的调试也是不可能的。

“数据驱动的编程”是由于对程序员的基本缺乏了解而导致的。即使您已经设法在用户界面中混合了两个想法,任何能够使算法实现的数据实际上都是“编程”。现在,这并不意味着您不能从另一个方向将这两个想法结合在一起,因此所有代码都是数据;这就是Lisp的前提,Lisp通过其同音性得以启用,并被其宏系统所利用。是的,这些概念听起来很相似,但实际上它们的含义和应用却大不相同。

同样,这可能是在编辑,但是我遇到过的需要“完全数据驱动”编程的地方确实不重视他们的程序员。他们将代码视为成本中心,将其外包或忽略。


我使用的系统使使用域特定语言系统构建表单,报表等更加容易。这使某些专家用户可以学习自己做这些事情。这也意味着我可以通过对运行时模块进行更正来修复所有站点上的错误,而不必弄乱专门为不同客户配置的任何内容。我同意这样的想法,即以成本中心进行编程既是外包代码的正确商业理由,又是摧毁公司的最佳方法。

4

你的意思是你的老板要你写这个:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

要生成此:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

第一个是JSON,第二个是JavaScript

澄清度

我认为从理论上讲,这不是因为解释数据的内容最终需要完整描述应用程序,因此您只是将问题上移了一层,甚至没有任何净收益。

这样的100%数据驱动应用程序有可能吗?

这是我刚开始的地方。对于我的回答,我试图与原始文章一致:可能,但是您是正确的,它只会将问题上移一个级别,而没有[明显的]好处


程序员会游览概念性问题,并给出答案解释问题。抛出代码转储而不是进行解释就像将代码从IDE复制到白板一样:它看起来很熟悉,甚至有时是可以理解的,但是感觉很奇怪……只是很奇怪。白板没有编译器
Mar14

@gnat感谢您的评论;我已经更新了答案,以使其更加清晰。如果仍然不清楚,请告诉我。
Mahdi 2014年

0

我认为,您可以令人信服地争论任何Web浏览器应用程序都可以视为100%数据驱动1

当然,这并没有使在Web上构建应用程序变得更简单或更容易,实际上,这使它们变得更加困难。

告诉您的老板,他正在重新发明Web浏览器,他最终将不得不重新发明JavaScript以构建任何相当复杂的东西。

1好吧,如果您忽略插件,JavaScript和HTML5


-1

是。据我所知,像Mathematica这样的系统是建立在您老板所期望的类似想法之上的,它是一种所谓的强大编程语言,但本质上是一种外壳。Wolfram Mathematica现在变得足够复杂,因此可以轻松完成许多计算任务。

数据驱动是一个概念。如果我们的程序员打算以一种简单的方式来操作数据,那么我们需要一个易于使用数据的外壳。尝试理解一下,一旦我们开始谈论学习基于语法的编程语言,我们实际上就是在学习应用程序接口或仅仅是它的外壳。如果我们了解外壳程序,就可以驱动程序。

对于100%数据驱动,如果编译器或解释器可以理解shell,则将驱动计算。如果数据具有与外壳程序或接口相同的基础结构,则数据也可以由编译器或解释器驱动。我认为Mathematica是一个很好的解释,为什么我会回答“是”。


1
这篇文章很难阅读(文字墙)。您介意将其编辑为更好的形状吗?
2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.