本文目录：
一、写在前面
二、，未来已来
三、的方法
四、学术界的研究启示
五、距离还有多远？
六、参考文献
一、写在前面
如果有一天机器人可以代替我们做代码，会自动分析出当前代码变更集对相关功能的影响，对迭代完成的影响，甚至对软件成本的影响。并且指导程序员如何修改代码，降低缺陷几率；或者招聘时，候选人的简历不再是简单的文字描述，而是切实的度量指标，并且个体指标可以和组织现有的集体指标进行弥合，来预测他的加入对团队所产生的影响，从而决定一个面试者是否合适。这一切会到来吗？
为什么软件工程始终无法像建筑工程那样可以工业化，说到底就是软件工程中的静态数据（代码本身的特性）、动态数据（软件过程）、差异性大、维度复杂、随机性大，所以软件工程预测学已经研究了十几年，仍旧没有商用。然而已经打败了傲视群雄的柯洁，苹果也在上公布了若干支持机器学习的应用。这一切对软件工程的发展产生什么样的积极影响？(智能化)离我们还有多远？
二、，未来已来
曾经在推特上看见一个网友这样定义：“ is eats ”，也就是说是用软件来定义基础设施，这个定义比所谓的 as Code更准确一些。不仅仅止于代码本身，目前比较流行的趋势是用相对成熟的开发体系整合运维体系，将部分运维的工作前移到开发阶段，用流程改进的方法让开发和运维统一，这样运维就可以享受较为成熟的开发工具，规范的设计方法，规范的开发流程。我常在想，为什么不是用运维的模式，指导思想整合开发工作呢？
除了部署以外，运维的大量工作都在监控基础设施，对异常问题进行事件告警，并且采取干预行动保证生产环境稳定、健康、可靠。运维工作的数据来源是机器，而开发工作毋庸置疑是由人主导，但是由人产生的数据就随性，复杂很多。所以数据的角度看，运维工作更加刚性，开发工作比较柔性。目前阶段用开发的方法统一运维就显得简单，并且可操作了。但是！统一的过程中不知不觉形成了一个微妙的变化。具体是什么呢？
阶段
特征
个人集成开发工具
原始，依靠个人能力，错误难以避免
组织内领域支撑工具
领域内，组织内自动化：统一的需求环境，统一的编译环境
1.0
贯穿生命周期
2.0
以容器云为基础设施
AI Ops
智能化运维
智能化开发，智能化运维，智能化生命周期管理
从上面软件工程发展来看，我们可以得出两个趋势：由零散到整合，由自动化到智能化。这背后的动因就是：的本质是软件生命周期数据链的形成。而利用数据做事一直是运维擅长的。
目前已经有不少组织开始在运维方面运用人工智能的方法使传统运维变的智能化。目前将部分运维工作整合到开发，而剩下的工作将以智能化运维的方式代替，这也就是为什么我认为今后运维的规模要缩减很多的原因。
而当我们有了数据链之后，就为传统运维意识：“监控事件告警行动”向整个软件生命周期进军铺平了道路。也就是说这种度量意识是从运维反馈给开发的。在度量意识驱动下的智能化运维将具有以下模式：
在理想情况下，人们只需要参与度量和行动环节，而其他环节都可以由机器自动的完成。并且度量环节只在系统初始化的时期设定，除非业务目标调整，一般是不会进行持续改变的。指导环节是很有必要的，即便在度量目标已经达到的情况下。我在以往的文章中讲过，度量有三中类型：过犹不及型，越多越好型，以及越少越好型。所以当目标达到时，并不是继续冲高更好。举个例子，当任务目标达标时，并不是给予研发人员更多的压力更好，更多的压力会带来代码质量低下，以及潜在的问题数增多。所以，会更加全面的利用软件工程的数据，挖掘潜在的影响因素，帮助我们更好的完成软件开发。
说到软件预测研究其实并不是一个新的话题，这些年来有大量的研究论文围绕如何预测软件缺陷，或者软件维护成本等问题展开。如果搜索软件预测方面的论文，你会发现发表日期可以追溯到2000年左右，可见软件预测的发展历史已经很久了，可是为什么没有一家商用的预测软件呢？究其原因有以下几点：
但随着数据链的完善，云设施的广泛部署，以及微服务带来的软件开发复杂度，管理复杂度攀升。在技术设施，商业需求上已经逐渐成熟。说了这么多，让我们来看看如何将人工智能运用到软件工程领域。
三、的方法
如何开展一个软件预测性研究，目前的关注点主要是以下几个方面：
模型
预测分析主要采用两大类算法体系：统计方法、机器学习的方法。
统计的方法就是以若干属性为维度找出数据集在另一维度上数据分布情况。其实统计的方法已经很成熟了，比如以时间的角度去看缺陷如何变化的燃尽图。短时间内变化不如长时间段看趋势有指导意义。不过，计的数据只在某些维度下比较有意义。如果维度过多，并且度量的范围过大就没有意义了，因为整体趋势总是类似的。
目前研究的大热门，机器学习大部分文章围绕在如何基于经典的分类器（朴素贝叶斯，逻辑回归，决策树等）设计出自己的预测算法。一般来说采用机器学习的方法进行预测的套路是这样的：
让深度学习家喻户晓，其实深度学习也是机器学习的一个领域。那么深度学习较之之前的逻辑回归，或者部分朴素贝叶斯算法有什么优点呢？以逻辑回归为例，它无法将不同的特征量合并产生新的特征量，例如贝叶斯也有条件无关性假设，即如果用X Y Z作为建模的度量指标，它们必须无关才行；但是这点有时很难做到。比如人员规模和进度有关联吗？当然有关联。另外大多数度量点和预测结果远非线性关系，这对于逻辑回归和非连续的朴素贝叶斯来讲就很难产生好的预测结果，使用者必须非常小心的挑选度量点。而深度学习就可以解决上面这些棘手的问题。
度量点怎么选？
度量点的选择是一个技巧性的问题。研究证明并没有一套最佳度量点可以放之四海，也就是说对于不同的预测上下文（预测目标），需要选择不同的度量点，比如说缺陷预测的度量点和软件维护成本预测的度量点就不一样。可以用以下分类方式对目前流行的度量点进行分类。
类型
说明
静态代码
文件大小，增加的代码行，删除的代码行，修改的代码行
缺陷历史
研究对象之前的缺陷在不同维度下的变化
过程数据
变更人，代码提交日期，平均解决问题时间
另外一个需要关心的问题就是，度量点数到底多少为好呢？一般情况下相关的度量点越详细，那么对于问题捕捉的准确度越高。但经常遇见的问题就是，如果数据质量不高，还想做预测该怎么办？有一篇“How Many be for ?”，答案是最少需要三个度量点。
数据如何预处理
一般而言，获得的数据一般会分为两块：
在开始进行建模之前，必须对数据集进行一定的数据清洗。很多算法的输入条件都比较苛刻。比较理想的数据研究对象是，有问题的和没有问题的各占一半，这样模型才有充分样本可以学习。如果说一个模块的缺陷率有0.3%，这样就会造成一个数据不平衡的问题（Data ）；以及如果数据特征不够明显，最终的模型也会产生过拟合的问题，这也会造成模型的不准确。因此一般会采用一些方法点对数据进行清洗：特征选择（ ）、规则化（）、噪音处理（Noise ）。
如何评价算法有效性？
如果有若干个备选模型，或者备选度量点，如何评价该采用那一个（套）呢？在算法的评价方法上，学界还是有共识的。我们先普及一下这几个指标：
预测有缺陷
预测没有缺陷
实际有缺陷
有缺陷预测准确TP（True ）
有缺陷预测有误FN（False ）
实际上没有缺陷
没有缺陷预测有误
FP（False ）
没有缺陷预测准确
TN（TRUE ）
由上面的几个基本指标再派生出例如，精密度（, TP/(TP+FP)）、查全率（, TP/(TP+FN)）、以及两者的综合F度量，分值越高证明算法既能预测到更多的研究对象又比较稳定。详细的概念就在这里不再赘述了。
四、学术界的研究启示
有一篇比较有意义的论文“ Bias: The Use of ”，他对2012年以前出现的机器学习法软件预测学论文进行了研究，并以“分类器、数据集、度量点、研究团体”四个维度进行了汇总分析“Meta-”。文章的结论还是比较震撼的，作者用了“”这个词对论文进行了总结：
难道无法实现了吗？，近些年研究者在可获取的数据量，数据广度，或者研究方向上都有了明显的变化，如“Deep for Just-In-Time ”，“ for ”这两篇已经开始用深度学习的方法，进行更有时效性的缺陷预测。之前也讲了深度学习模型的特点，在这两篇论文中都是用了深度置信网络DBN为模型进行预测，DBN由多层玻尔兹曼机RBN组成。相对之前直接用度量点的数据为输入进行建模的方式，DBN在用分类器进行结果判定之前，用若干层RBN对数据进行处理，从而得出特征值，再用该值进行判定，输入值和结果值不被限定在线性关系，因此DBN比简单的分类器方法更加可信。比如论文“ for ”不再以传统的度量值为输入，而是对代码的语义进行解析，形成特征向量，再输入到DBN中进行模型训练。
此外，近些年的论文在数据量大小以及项目多样性方面已经具有所谓“大数据”的特征。研究者们有更多并且高质量的数据可以使用研究。正如李飞飞教授所说，数据集将在高级人工智能研究方面扮演至关重要的角色。这也为软件预测的发展奠定了良好的基础。
五、距离还有多远？
在商用软件架构领域，这些年也在发生着悄然生息的变化：容器和微服务解决了基础设施和软件结构的问题。API经济学，语义网络解决了数据共享以及数据关系的问题。等软件工程相关的公有云解决了工程数据可用性的问题。那接下来就是用一个标准的语义格式去连接这些数据，并且做分析的问题了。虽然已经有类似OSLC的标准进行了先期探索，但是受限于数据存储、查询效率等各种问题的制约止步不前。从数据应用的角度看，自服务的数据使用方式也渐渐融入更多的机器学习算法。
所以其实我们与的距离并不那么遥远了，待软件工程管理的复杂度越来越大，智能化管理的需求越来越高，也许就是临门一脚的事情。因此，我们应该有充分的信心期待软件工程领域会出现类似一般的研究成果。
六、参考文献
1. Sarah ，Tracy Hall, David Bowes. A of Fault used in (2010).
2. Wang, Taghi M. , Naeem . How Many be for ? (2010).
3. , Llu´ıs , R. . using (2011).
4. , David Bowes and Tracy Hall, Bias: The Use of
in (2012).
5. Nam , on (2014).
6. Xinli Yang, David Lo, Xin Xia. Deep for Just-In-Time (2015).
7. Song Wang, Liu and Lin Tan. for
(2016).
相关文章
