CODING DevOps 系列第四课：DevOps 中的质量内建实践

什么是质量内建

随着时间的推移，我们项目的开发效率会逐渐降低，直到几年之后整个项目可能就无法维护，只能推倒重来。具体的表现首先就是随着时间推移，我们会发现整个需求列表里面能做的需求越来越少，因为每当我们增加一个新特性，需要改动的代码就非常多，所以最后每提出一个新的需求，团队评估出来的改动成本都非常高，导致最后难以增加新的特性。

第二个表现就是缺陷难以修复。我们做出来的系统只要有人用就会有反馈一些线上的故障，一开始代码很简单的时候修复起来是很快的，但是随着代码越来越复杂、代码行数越来越多，我们会发现定位问题太难了。尤其是现在我们的项目采用的是非常复杂的架构，所以当用户线上报错的时候，我们很难去定位到是哪里出了问题。但其实只要定位到了问题，修复起来是很快的。

第三个表现我们称之为“打地鼠现象”，简单来说就是当你“按”下一个缺陷的时候，又会蹦出来几个新的缺陷。这样会导致大家在工作的过程中压力非常大、心情也会比较沉重。

所以对于这些挑战，我们也有想办法去解决，CI、CD 以及 DevOps 的出现都让我们看到了很好的方向。但是我看到很多团队其实只是靠 DevOps 解决了一些基本的问题，并没有解决核心的问题。这是为什么呢？因为核心问题主要是靠开发人员的能力提升来解决的，但由于改变一个人是很难的，所以企业往往会绕开这些问题。所以我今天分享的内容主要会涉及到开发人员如何去写代码等一些实践。

我们在刚开始启动一个项目的时候，我们会制定一些代码规范，所以代码相对来说是比较清晰的。但是随着需求的演变，在实现这些需求的时候，每个人都会选择最低成本、最保险的方式。这就会导致没有人敢去大幅度地改动代码，只会在里面追加一些代码，造成了代码里面有大量的重复、过长的方法。同时开始的时候设计的架构也是非常清晰的，但是如果后续没有很好的落地、监控、自动化地发现问题，架构就会在这过程中腐化，变得一团乱。

Deming 先生曾提出“问题发现得越早，修复的成本越低”，这句话也是我们去降低软件开发成本、更高效地保证质量的重要原则。所以我们采用质量内建的方式，可以把整个软件质量的保障内嵌到开发的过程中去，而不是留到后面再去检测，因为越往后修复的成本越高。

85% 的缺陷都是在代码编