如果有一天机器人可以代替我们做代码 Review，会自动分析出当前代码变更集对相关功能的影响，对迭代完成的影响，甚至对软件成本的影响。并且指导程序员如何修改代码，降低缺陷几率；或者招聘时，候选人的简历不再是简单的文字描述，而是切实的度量指标，并且个体指标可以和组织现有的集体指标进行弥合，来预测他的加入对团队所产生的影响，从而决定一个面试者是否合适。这一切会到来吗？

为什么软件工程始终无法像建筑工程那样可以工业化，说到底就是软件工程中的静态数据（代码本身的特性）、动态数据（软件过程）、差异性大、维度复杂、随机性大，所以软件工程预测学已经研究了十几年，仍旧没有商用。

然而 AlphaGo 已经打败了傲视群雄的柯洁，苹果也在 WWDC2017 上公布了若干支持机器学习的应用。这一切对软件工程的发展产生什么样的积极影响？AIDevOps(智能化 DevOps) 离我们还有多远？

AIDevOps，未来已来  

曾经在推特上看见一个网友这样定义 DevOps：

DevOps is software eats infrastructure

也就是说 DevOps是用软件来定义基础设施，这个定义比所谓的 Infrastructure as Code 更准确一些。不仅仅止于代码本身，目前 DevOps 比较流行的趋势是用相对成熟的开发体系整合运维体系，将部分运维的工作前移到开发阶段，用流程改进的方法让开发和运维统一，这样运维就可以享受较为成熟的开发工具，规范的设计方法，规范的开发流程。

我常在想，为什么不是用运维的模式，指导思想整合开发工作呢？

除了部署以外，运维的大量工作都在监控基础设施，对异常问题进行事件告警，并且采取干预行动保证生产环境稳定、健康、可靠。运维工作的数据来源是机器，而开发工作毋庸置疑是由人主导，但是由人产生的数据就随性，复杂很多。所以数据的角度看，运维工作更加刚性，开发工作比较柔性。 目前阶段用开发的方法统一运维就显得简单，并且可操作了。但是！DevOps 统一的过程中不知不觉形成了一个微妙的变化。具体是什么呢？

目前已经有不少组织开始在运维方面运用人工智能的方法使传统运维变的智能化。目前 DevOps 将部分运维工作整合到开发，而剩下的工作将以智能化运维的方式代替，这也就是为什么我认为今后运维的规模要缩减很多的原因。

从上面软件工程发展来看，我们可以得出两个趋势：由零散到整合，由自动化到智能化。这背后的动因就是：DevOps的本质是软件生命周期数据链的形成。而利用数据做事一直是运维擅长的。

而当我们有了数据链之后，就为传统运维意识：“监控事件告警行动”向整个软件生命周期进军铺平了道路。也就是说这种度量意识是从运维反馈给开发的。在度量意识驱动下的智能化运维 AIDevOps 将具有以下模式：

·                     度量：针对软件生命周期内的不同行为进行度量点定义，并且定义度量点的度量指标，对软件生命周期数据进行度量。

·                     分析：对现有数据进行收集汇总，针对不同业务目标确定预测模型，或者对原有模型进行调整。

·                     学习：用数据进行建模，通过对不同模型效能的评估，确定可用模型。

·                     预测：通过数据对业务目标进行预测。

·                     指导：针对预测结果和度量目标的对比，对实践者进行最佳实践指导。

·                     行动：按照指导行动，并为下一次的度量积累数据。

在理想情况下，人们只需要参与度量和行动环节，而其他环节都可以由机器自动的完成。并且度量环节只在系统初始化的时期设定，除非业务目标调整，一般是不会进行持续改变的。指导环节是很有必要的，即便在度量目标已经达到的情况下。我在以往的文章中讲过，度量有三中类型：过犹不及型，越多越好型，以及越少越好型。所以当目标达到时，并不是继续冲高更好。举个例子，当任务目标达标时，并不是给予研发人员更多的压力更好，更多的压力会带来代码质量低下，以及潜在的问题数增多。所以，AIDevOps 会更加全面的利用软件工程的数据，挖掘潜在的影响因素，帮助我们更好的完成软件开发。

说到软件预测研究其实并不是一个新的话题，这些年来有大量的研究论文围绕如何预测软件缺陷，或者软件维护成本等问题展开。如果搜索软件预测方面的论文，你会发现发表日期可以追溯到 2000 年左右，可见软件预测的发展历史已经很久了，可是为什么没有一家商用的预测软件呢？究其原因有以下几点：

·                     软件工程能力成熟度不同，预测的价值有时属于锦上添花。

·                     预测研究所用的数据比较单一，数据可用性不强。

·                     不同项目，不同产品的管理过程不同，因此同一种数据会有不同的数据上下文。

但随着数据链的完善，云设施的广泛部署，以及微服务带来的软件开发复杂度，管理复杂度攀升。AIDevOps 在技术设施，商业需求上已经逐渐成熟。说了这么多，让我们来看看如何将人工智能运用到软件工程领域。

AIDevOps 的方法  

如何开展一个软件预测性研究，目前的关注点主要是以下几个方面：

·                     研究采用什么样的预测模型。

·                     所采用什么样的度量指标进行预测。

·                     如何进行数据预处理。

·                     如何评价模型的预测结果。

    模型  

预测分析主要采用两大类算法体系：统计方法、机器学习的方法。

统计的方法就是以若干属性为维度找出数据集在另一维度上数据分布情况。其实统计的方法已经很成熟了，比如以时间的角度去看缺陷如何变化的燃尽图。短时间内变化不如长时间段看趋势有指导意义。不过，计的数据只在某些维度下比较有意义。如果维度过多，并且度量的范围过大就没有意义了，因为整体趋势总是类似的。

目前研究的大热门，机器学习大部分文章围绕在如何基于经典的分类器（朴素贝叶斯，逻辑回归，决策树等）设计出自己的预测算法。一般来说采用机器学习的方法进行预测的套路是这样的：

·                     选定度量指标（特征）。

·                     从例如代码库，项目管理工具，测试工具等系统中抽取度量值。

·                     对度量值进行预处理。

·                     使用数据对若干个模型进行训练，并且选定一个最优的模型。

·                     进行正式预测。

AlphaGo 让深度学习家喻户晓，其实深度学习也是机器学习的一个领域。那么深度学习较之之前的逻辑回归，或者部分朴素贝叶斯算法有什么优点呢？以逻辑回归为例，它无法将不同的特征量合并产生新的特征量，例如贝叶斯也有条件无关性假设，即如果用 X Y Z 作为建模的度量指标，它们必须无关才行；但是这点有时很难做到。比如人员规模和进度有关联吗？当然有关联。另外大多数度量点和预测结果远非线性关系，这对于逻辑回归和非连续的朴素贝叶斯来讲就很难产生好的预测结果，使用者必须非常小心的挑选度量点。而深度学习就可以解决上面这些棘手的问题。

    度量点怎么选？  

度量点的选择是一个技巧性的问题。研究证明并没有一套最佳度量点可以放之四海，也就是说对于不同的预测上下文（预测目标），需要选择不同的度量点，比如说缺陷预测的度量点和软件维护成本预测的度量点就不一样。可以用以下分类方式对目前流行的度量点进行分类。

另外一个需要关心的问题就是，度量点数到底多少为好呢？一般情况下相关的度量点越详细，那么对于问题捕捉的准确度越高。但经常遇见的问题就是，如果数据质量不高，还想做预测该怎么办？有一篇“How Many Software Metrics Should be Selected for Defect Prediction?”，答案是最少需要三个度量点。

    数据如何预处理  

一般而言，获得的数据一般会分为两块：

·                     第一块，训练数据集，用来训练和建立模型；

·                     第二块，验证数据集，在已经建立的模型上对不同模型（分类器）在不同场景下进行测试，选择适合的模型。

在开始进行建模之前，必须对数据集进行一定的数据清洗。很多算法的输入条件都比较苛刻。比较理想的数据研究对象是，有问题的和没有问题的各占一半，这样模型才有充分样本可以学习。如果说一个模块的缺陷率有 0.3%，这样就会造成一个数据不平衡的问题（Data imbalance）；以及如果数据特征不够明显，最终的模型也会产生过拟合的问题，这也会造成模型的不准确。因此一般会采用一些方法点对数据进行清洗：特征选择（Feature Selection）、规则化（Normalization）、噪音处理（Noise Handling）。

    如何评价算法有效性？  

如果有若干个备选模型，或者备选度量点，如何评价该采用那一个（套）呢？在算法的评价方法上，学界还是有共识的。我们先普及一下这几个指标：

由上面的几个基本指标再派生出例如，精密度（Precision, TP/(TP+FP)）、查全率（Recall, TP/(TP+FN)）、以及两者的综合 F 度量，分值越高证明算法既能预测到更多的研究对象又比较稳定。详细的概念就在这里不再赘述了。

学术界的研究启示  

有一篇比较有意义的论文“Researcher Bias: The Use of Machine Learning Software Defect Prediction”，他对 2012 年以前出现的机器学习法软件预测学论文进行了研究，并以“分类器、数据集、度量点、研究团体”四个维度进行了汇总分析“Meta-analysis”。文章的结论还是比较震撼的，作者用了“Striking”这个词对论文进行了总结：

·                     很多分类器并没有很好的鉴别作用，并且他们之前的差别也并不明显；因为还有一些未知的因素对模型效果产生了比较大的影响。

·                     较之分类器模型，不同研究团体之间的研究成果差距明显。也就是说算法并不重要，谁做的研究更重要。

·                     因为预测套路大多都是在已经存在的数据集之上建模，并且用已知的数据进行测试，用已知结果来反推算法让模型变得可用，这样以来研究小组总是发明自己的算法，造成算法的复杂度越来越高，换一个数据集可能模型就没有移植性。

·                     研究成果有没有随着时间的推移更加成熟了呢？并没有！因为以上的原因，研究的持续性比较差，也就是说很少有论文在之前论文的基础上开展更加深入的工作。

难道 AIDevOps 无法实现了吗？近些年研究者在可获取的数据量，数据广度，或者研究方向上都有了明显的变化，如“Deep Learning for Just-In-Time Defect Prediction”，“Automatically Learning Semantic Features for Defect Prediction”这两篇已经开始用深度学习的方法，进行更有时效性的缺陷预测。之前也讲了深度学习模型的特点，在这两篇论文中都是用了深度置信网络 DBN 为模型进行预测，DBN 由多层玻尔兹曼机 RBN 组成。相对之前直接用度量点的数据为输入进行建模的方式，DBN 在用分类器进行结果判定之前，用若干层 RBN 对数据进行处理，从而得出特征值，再用该值进行判定，输入值和结果值不被限定在线性关系，因此 DBN 比简单的分类器方法更加可信。比如论文“Automatically Learning Semantic Features for Defect Prediction”不再以传统的度量值为输入，而是对代码的语义进行解析，形成特征向量，再输入到 DBN 中进行模型训练。

此外，近些年的论文在数据量大小以及项目多样性方面已经具有所谓“大数据”的特征。研究者们有更多并且高质量的数据可以使用研究。正如李飞飞教授所说，数据集将在高级人工智能研究方面扮演至关重要的角色。这也为软件预测的发展奠定了良好的基础。

距离 AIDevOps 还有多远？  

在商用软件架构领域，这些年也在发生着悄然生息的变化：容器和微服务解决了基础设施和软件结构的问题。API 经济学，语义网络解决了数据共享以及数据关系的问题。GitHub 等软件工程相关的公有云解决了工程数据可用性的问题。那接下来就是用一个标准的语义格式去连接这些数据，并且做分析的问题了。虽然已经有类似 OSLC 的标准进行了先期探索，但是受限于数据存储、查询效率等各种问题的制约止步不前。从数据应用的角度看，自服务的数据使用方式也渐渐融入更多的机器学习算法。

所以其实我们与 AIDevOps 的距离并不那么遥远了，待软件工程管理的复杂度越来越大，智能化管理的需求越来越高，AIDevOps 也许就是临门一脚的事情。因此，我们应该有充分的信心期待软件工程领域会出现类似 AlphaGo 一般的研究成果。

（胡帅原创）

如果有一天机器人可以代替我们做代码 Review，会自动分析出当前代码变更集对相关功能的影响，对迭代完成的影响，甚至对软件成本的影响。并且指导程序员如何修改代码，降低缺陷几率；或者招聘时，候选人的简历不再是简单的文字描述，而是切实的度量指标，并且个体指标可以和组织现有的集体指标进行弥合，来预测他的加入对团队所产生的影响，从而决定一个面试者是否合适。这一切会到来吗？

为什么软件工程始终无法像建筑工程那样可以工业化，说到底就是软件工程中的静态数据（代码本身的特性）、动态数据（软件过程）、差异性大、维度复杂、随机性大，所以软件工程预测学已经研究了十几年，仍旧没有商用。

然而 AlphaGo 已经打败了傲视群雄的柯洁，苹果也在 WWDC2017 上公布了若干支持机器学习的应用。这一切对软件工程的发展产生什么样的积极影响？AIDevOps(智能化 DevOps) 离我们还有多远？

AIDevOps，未来已来  

曾经在推特上看见一个网友这样定义 DevOps：

DevOps is software eats infrastructure

也就是说 DevOps是用软件来定义基础设施，这个定义比所谓的 Infrastructure as Code 更准确一些。不仅仅止于代码本身，目前 DevOps 比较流行的趋势是用相对成熟的开发体系整合运维体系，将部分运维的工作前移到开发阶段，用流程改进的方法让开发和运维统一，这样运维就可以享受较为成熟的开发工具，规范的设计方法，规范的开发流程。

我常在想，为什么不是用运维的模式，指导思想整合开发工作呢？

除了部署以外，运维的大量工作都在监控基础设施，对异常问题进行事件告警，并且采取干预行动保证生产环境稳定、健康、可靠。运维工作的数据来源是机器，而开发工作毋庸置疑是由人主导，但是由人产生的数据就随性，复杂很多。所以数据的角度看，运维工作更加刚性，开发工作比较柔性。 目前阶段用开发的方法统一运维就显得简单，并且可操作了。但是！DevOps 统一的过程中不知不觉形成了一个微妙的变化。具体是什么呢？

目前已经有不少组织开始在运维方面运用人工智能的方法使传统运维变的智能化。目前 DevOps 将部分运维工作整合到开发，而剩下的工作将以智能化运维的方式代替，这也就是为什么我认为今后运维的规模要缩减很多的原因。

从上面软件工程发展来看，我们可以得出两个趋势：由零散到整合，由自动化到智能化。这背后的动因就是：DevOps的本质是软件生命周期数据链的形成。而利用数据做事一直是运维擅长的。

而当我们有了数据链之后，就为传统运维意识：“监控事件告警行动”向整个软件生命周期进军铺平了道路。也就是说这种度量意识是从运维反馈给开发的。在度量意识驱动下的智能化运维 AIDevOps 将具有以下模式：

·                     度量：针对软件生命周期内的不同行为进行度量点定义，并且定义度量点的度量指标，对软件生命周期数据进行度量。

·                     分析：对现有数据进行收集汇总，针对不同业务目标确定预测模型，或者对原有模型进行调整。

·                     学习：用数据进行建模，通过对不同模型效能的评估，确定可用模型。

·                     预测：通过数据对业务目标进行预测。

·                     指导：针对预测结果和度量目标的对比，对实践者进行最佳实践指导。

·                     行动：按照指导行动，并为下一次的度量积累数据。

在理想情况下，人们只需要参与度量和行动环节，而其他环节都可以由机器自动的完成。并且度量环节只在系统初始化的时期设定，除非业务目标调整，一般是不会进行持续改变的。指导环节是很有必要的，即便在度量目标已经达到的情况下。我在以往的文章中讲过，度量有三中类型：过犹不及型，越多越好型，以及越少越好型。所以当目标达到时，并不是继续冲高更好。举个例子，当任务目标达标时，并不是给予研发人员更多的压力更好，更多的压力会带来代码质量低下，以及潜在的问题数增多。所以，AIDevOps 会更加全面的利用软件工程的数据，挖掘潜在的影响因素，帮助我们更好的完成软件开发。

说到软件预测研究其实并不是一个新的话题，这些年来有大量的研究论文围绕如何预测软件缺陷，或者软件维护成本等问题展开。如果搜索软件预测方面的论文，你会发现发表日期可以追溯到 2000 年左右，可见软件预测的发展历史已经很久了，可是为什么没有一家商用的预测软件呢？究其原因有以下几点：

·                     软件工程能力成熟度不同，预测的价值有时属于锦上添花。

·                     预测研究所用的数据比较单一，数据可用性不强。

·                     不同项目，不同产品的管理过程不同，因此同一种数据会有不同的数据上下文。

但随着数据链的完善，云设施的广泛部署，以及微服务带来的软件开发复杂度，管理复杂度攀升。AIDevOps 在技术设施，商业需求上已经逐渐成熟。说了这么多，让我们来看看如何将人工智能运用到软件工程领域。

AIDevOps 的方法  

如何开展一个软件预测性研究，目前的关注点主要是以下几个方面：

·                     研究采用什么样的预测模型。

·                     所采用什么样的度量指标进行预测。

·                     如何进行数据预处理。

·                     如何评价模型的预测结果。

    模型  

预测分析主要采用两大类算法体系：统计方法、机器学习的方法。

统计的方法就是以若干属性为维度找出数据集在另一维度上数据分布情况。其实统计的方法已经很成熟了，比如以时间的角度去看缺陷如何变化的燃尽图。短时间内变化不如长时间段看趋势有指导意义。不过，计的数据只在某些维度下比较有意义。如果维度过多，并且度量的范围过大就没有意义了，因为整体趋势总是类似的。

目前研究的大热门，机器学习大部分文章围绕在如何基于经典的分类器（朴素贝叶斯，逻辑回归，决策树等）设计出自己的预测算法。一般来说采用机器学习的方法进行预测的套路是这样的：

·                     选定度量指标（特征）。

·                     从例如代码库，项目管理工具，测试工具等系统中抽取度量值。

·                     对度量值进行预处理。

·                     使用数据对若干个模型进行训练，并且选定一个最优的模型。

·                     进行正式预测。

AlphaGo 让深度学习家喻户晓，其实深度学习也是机器学习的一个领域。那么深度学习较之之前的逻辑回归，或者部分朴素贝叶斯算法有什么优点呢？以逻辑回归为例，它无法将不同的特征量合并产生新的特征量，例如贝叶斯也有条件无关性假设，即如果用 X Y Z 作为建模的度量指标，它们必须无关才行；但是这点有时很难做到。比如人员规模和进度有关联吗？当然有关联。另外大多数度量点和预测结果远非线性关系，这对于逻辑回归和非连续的朴素贝叶斯来讲就很难产生好的预测结果，使用者必须非常小心的挑选度量点。而深度学习就可以解决上面这些棘手的问题。

    度量点怎么选？  

度量点的选择是一个技巧性的问题。研究证明并没有一套最佳度量点可以放之四海，也就是说对于不同的预测上下文（预测目标），需要选择不同的度量点，比如说缺陷预测的度量点和软件维护成本预测的度量点就不一样。可以用以下分类方式对目前流行的度量点进行分类。

另外一个需要关心的问题就是，度量点数到底多少为好呢？一般情况下相关的度量点越详细，那么对于问题捕捉的准确度越高。但经常遇见的问题就是，如果数据质量不高，还想做预测该怎么办？有一篇“How Many Software Metrics Should be Selected for Defect Prediction?”，答案是最少需要三个度量点。

    数据如何预处理  

一般而言，获得的数据一般会分为两块：

·                     第一块，训练数据集，用来训练和建立模型；

·                     第二块，验证数据集，在已经建立的模型上对不同模型（分类器）在不同场景下进行测试，选择适合的模型。

在开始进行建模之前，必须对数据集进行一定的数据清洗。很多算法的输入条件都比较苛刻。比较理想的数据研究对象是，有问题的和没有问题的各占一半，这样模型才有充分样本可以学习。如果说一个模块的缺陷率有 0.3%，这样就会造成一个数据不平衡的问题（Data imbalance）；以及如果数据特征不够明显，最终的模型也会产生过拟合的问题，这也会造成模型的不准确。因此一般会采用一些方法点对数据进行清洗：特征选择（Feature Selection）、规则化（Normalization）、噪音处理（Noise Handling）。

    如何评价算法有效性？  

如果有若干个备选模型，或者备选度量点，如何评价该采用那一个（套）呢？在算法的评价方法上，学界还是有共识的。我们先普及一下这几个指标：

由上面的几个基本指标再派生出例如，精密度（Precision, TP/(TP+FP)）、查全率（Recall, TP/(TP+FN)）、以及两者的综合 F 度量，分值越高证明算法既能预测到更多的研究对象又比较稳定。详细的概念就在这里不再赘述了。

学术界的研究启示  

有一篇比较有意义的论文“Researcher Bias: The Use of Machine Learning Software Defect Prediction”，他对 2012 年以前出现的机器学习法软件预测学论文进行了研究，并以“分类器、数据集、度量点、研究团体”四个维度进行了汇总分析“Meta-analysis”。文章的结论还是比较震撼的，作者用了“Striking”这个词对论文进行了总结：

·                     很多分类器并没有很好的鉴别作用，并且他们之前的差别也并不明显；因为还有一些未知的因素对模型效果产生了比较大的影响。

·                     较之分类器模型，不同研究团体之间的研究成果差距明显。也就是说算法并不重要，谁做的研究更重要。

·                     因为预测套路大多都是在已经存在的数据集之上建模，并且用已知的数据进行测试，用已知结果来反推算法让模型变得可用，这样以来研究小组总是发明自己的算法，造成算法的复杂度越来越高，换一个数据集可能模型就没有移植性。

·                     研究成果有没有随着时间的推移更加成熟了呢？并没有！因为以上的原因，研究的持续性比较差，也就是说很少有论文在之前论文的基础上开展更加深入的工作。

难道 AIDevOps 无法实现了吗？近些年研究者在可获取的数据量，数据广度，或者研究方向上都有了明显的变化，如“Deep Learning for Just-In-Time Defect Prediction”，“Automatically Learning Semantic Features for Defect Prediction”这两篇已经开始用深度学习的方法，进行更有时效性的缺陷预测。之前也讲了深度学习模型的特点，在这两篇论文中都是用了深度置信网络 DBN 为模型进行预测，DBN 由多层玻尔兹曼机 RBN 组成。相对之前直接用度量点的数据为输入进行建模的方式，DBN 在用分类器进行结果判定之前，用若干层 RBN 对数据进行处理，从而得出特征值，再用该值进行判定，输入值和结果值不被限定在线性关系，因此 DBN 比简单的分类器方法更加可信。比如论文“Automatically Learning Semantic Features for Defect Prediction”不再以传统的度量值为输入，而是对代码的语义进行解析，形成特征向量，再输入到 DBN 中进行模型训练。

此外，近些年的论文在数据量大小以及项目多样性方面已经具有所谓“大数据”的特征。研究者们有更多并且高质量的数据可以使用研究。正如李飞飞教授所说，数据集将在高级人工智能研究方面扮演至关重要的角色。这也为软件预测的发展奠定了良好的基础。

距离 AIDevOps 还有多远？  

在商用软件架构领域，这些年也在发生着悄然生息的变化：容器和微服务解决了基础设施和软件结构的问题。API 经济学，语义网络解决了数据共享以及数据关系的问题。GitHub 等软件工程相关的公有云解决了工程数据可用性的问题。那接下来就是用一个标准的语义格式去连接这些数据，并且做分析的问题了。虽然已经有类似 OSLC 的标准进行了先期探索，但是受限于数据存储、查询效率等各种问题的制约止步不前。从数据应用的角度看，自服务的数据使用方式也渐渐融入更多的机器学习算法。

所以其实我们与 AIDevOps 的距离并不那么遥远了，待软件工程管理的复杂度越来越大，智能化管理的需求越来越高，AIDevOps 也许就是临门一脚的事情。因此，我们应该有充分的信心期待软件工程领域会出现类似 AlphaGo 一般的研究成果。

（胡帅原创）