数据驱动软件工程，是时候把它召唤回来了
前阵因为论文看到过有关驳数据驱动的文章。的确，数据驱动方法存在一些问题。在90年代，Google 曾经做过一个实验，将程序员分成2组，一面教授模型驱动设计，另一面教授的是数据驱动设计。结果是，学习了数据驱动设计的开发者的代码冗余性提高，拓展性降低。就是所谓的低内聚高耦合。不过，那是90年代。回过头来看看现代的软件开发。首先，软件开发从原先的经典开发方法改变到了现在的持续性开发方法。其次，最终用户已经不能满足经典开发的速度。再次，软件市场由 PC 逐渐移动到移动设备，竞争更加激烈。最后，最终用户由于现在软件市场的竞争使得对一个软件的敏感度下降很快。所有的一切都告诉开发者，开发的要快，开发的要好。记得袁腾飞曾经说过，多快好省本来就是矛盾的，但是，最终用户的心里现在就是这样希望软件做的又快又好。开发者只能想办法来提高开发的效率。
现在有一些开发的方法，比如敏捷开发，基于原型的开发以及可持续开发。这些开发方法的共同点在于，都是通过软件运行时的 Log 以及用户的回馈来进行软件再开发。如果抛开开发过程，只看测试反馈的这一部分，那么，这里的开发方法其实是数据驱动的。这说明，数据驱动方法并不是一无所用。
数据驱动软件工程的主要作用有2点。
1. 实时的软件回馈数据来驱动软件的再开发以及质量控制。一个比较著名的方法就是 Continuous Integration (CI)
2. 强调软件开发参与者之间的交流与合作。例如 DevOps
微软亚洲研究院有一个项目叫做软件分析，其实他们也是数据驱动软件工程的一部分。他们的主旨在于通过分析错误堆栈定位软件代码，从而提速再开发速度。Etsy 通过 Automatic Daily Build 检测他们的在线商务网站中存在的问题，而后根据自动测试的结果修复问题。这也是数据驱动软件工程哦。
综上所述，当前可行的数据驱动软件工程方案其实就是尝试将 CI 和 DevOps 结合在一起，目的是为了提高软件质量，加速软件再开发的速度。适应人群为整个IT界+最终客户的圈子。IT 界中主要是软件开发者以及研究者。当然了，Consultants 拿这些测试的结果还可以去 consulting 呢。
未来的软件工程，我认为就是模型驱动整合进数据驱动工程，设计一个软件可以通过以下的步骤：
[1]. 通过数据驱动设计方法，根据客户需求收集并回归相关信息
[2]. 使用 [1] 中的结果，采用模型驱动进行软件设计
[3]. 开发完成后，通过 CI 的方式以及Agile的开发方法，将原型机交付客户检测，进行实际数据采集分析，这里采用数据驱动设计的方法。
[4]. 对软件分析进行分工，分配给软件分析师或者研究员，加强他们与实际软件开发者的联系。可以参考 MSR Asia 的那个项目。这一点十分重要。大家已经发现，现在的科研机构，包括公司内部的，和实际的研发机构的技术脱节过大，很多的项目在科研机构产生但是由于是在是没用，不但花了一大笔钱，还收获不到什么。
[5]. 经常性的询问用户的需求，采用具体的方法针对具体的客户进行软件再设计。
[6]. 最终交付，当然，这个要询问客户是否已经满意当前的需求。然后争取用户许可跟踪用户的实际应用，在维护期内尽量提高软件性能。
[7]. 做好开发文档。包括[2]中的或改动的模型设计，以及开发时的注意要点。其他冗余的东西其实是不需要记录的。尽量精简的信息可以让后继的开发者或者研究员很快上手项目。
[8]. 对于移动开发者：通过数据驱动的方法收集开发的软件涉及到的领域，发掘新的可再开发的要点，对软件进行修改以及更新，并重复[3]到[7]。如果模型上有更大的改动，则从[2]开始。
当前数据驱动软件工程可以完全整合 CI，DevOps以及模型驱动软件工程方法，以及部分整合经典开发方法，根据不同的对象进行不同方式的开发。例如在开发过程中，单一迭代内局域瀑布式开发，全局迭代式开发，在开发后期面向经验测试以及面向原型进行再开发。因此，数据驱动软件工程领域有很大的发展空间：
首先，技术上，今年 MIT 可以通过分析做到自动代码生成，辅助开发者开发软件。所以模式识别，人工智能以及遗传算法等可以加入进来。
其次，人与人交流上，做到高效的进行合作交互。开发者和研究员毕竟都是人，如何让他们合作在一起产生更高的效率，就需要我们亲爱的人类学家来做啦。
再次，领域上，数据驱动方法可以说是完全跨领域的。有意思的是，当前用的最多的是在西方政治中进行决策分析用。软件工程上涉及真正的数据驱动思想还是很少的。
某位大佬说，今年，2012年是数据驱动年。毕竟软件业和10年前完全不同了。数据驱动软件工程将会整合现在流行的方法，变成一个更加好用的通用方法也说不定 :)
Ye Tian at SAP Research Karlsruhe
