DevOps中的质量内建实践

本文探讨了DevOps中的质量内建重要性,指出85%的缺陷在编码阶段引入,强调了早期发现和修复缺陷的价值。通过自动化测试、重构和简单设计等手段,可以在编码阶段降低缺陷,从而降低软件开发成本。此外,文章还讨论了技术债的概念,提倡使用‘质量门禁’策略防止代码质量下降,并提出了技术债的偿还策略和自动化在提升效率和避免错误中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

点击观看大咖分享


什么是质量内建

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

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

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

 

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值