CODING DevOps 线下沙龙回顾一:DevOps 代码质量实战

腾讯云CODING举办的DevOps技术沙龙聚焦代码质量和效能,分享了如何通过代码规范、Lint工具、持续集成以及自动化测试来确保和提高软件质量。建议采用IDE、Git commit hook和服务端检查结合的方式强制执行代码规范,并利用持续集成进行质量内建。此外,提倡开发人员自测并编写测试代码以增强代码信心,提倡尽早引入自动化测试以应对业务增长和回归测试挑战。

11 月 22 日,由 CODING 主办的 DevOps 技术沙龙系列「质量」专场在上海圆满结束。在活动现场,四位来自腾讯等知名企业的技术大咖们分享了研发质量与效能的实战经验,与观众们共同探讨如何采取有效手段以保证和提高软件质量。

在这里插入图片描述

本期沙龙回顾为大家带来的,是来自腾讯云 CODING 布道师杨周的议题——《DevOps 代码质量实战》

问题:人越来越多,代码越来越乱

在这里插入图片描述

随着团队成员增多,每个人在缩进、换行、空格以及大小写方面有不同的习惯,导致代码越来越乱。代码风格问题尚且不致命,更严重的是这些问题:

  • Hard code:在代码中书写各种环境配置、链接、密钥,导致安全风险
  • 魔法数字(Magic Number):难以理解和维护
  • 代码行数过多:难以维护,违反面向对象的 SOLID 原则

不少业界大厂公布了代码规范,推荐大家直接采用,因为自己发明规范往往不够全面,很难服众。

代码规范不只是缩进换行问题,通过强制约束圈复杂度、文件行数和方法行数,可促使大家按照面向对象的方式设计。

如何强制执行代码规范

有了代码规范,但怎么落地?是很多团队面临的问题。Lint 程序用来检查代码规范,各个语言(比如 Kotlin、Java、PHP)都有自己的规范和 Lint。

自动检查代码规范有三个时机:

  • IDE:最实时方便的,但需要所有人进行配置、某些 IDE 可能不支持
  • Git commit Hook:提交时,会调用命令行工具强制检查,优点是非常及时,然而存在可被删除的风险
  • 服务端:在 Git push 之后,在服务端进行检查,很可靠,但缺点是不够实时
    因此,建议同时使用这三种方式。

在这里插入图片描述

在代码检查之后,如何处理?老项目有成千上万处不规范,很显然不能一次清理干净,让所有人停下老项目去清理老代码并不现实,而且一次改动太多文件的风险也很高。因此建议使用增量检查,尤其是 Java 增量检查方案比较复杂,详情可识别下图二维码阅读 CODING 文档

在这里插入图片描述

服务端检查:建议使用持续集成(持续不断地把代码集成到主干,实现质量内建)。流程为:锁定 Git 主干,所有人开发功能拉取小分支,小分支提交后触发持续集成进行代码规范检查,通过之后再通知同事进行代码评审,通过这套流程来提高代码质量。CODING 持续集成兼容 Jenkins,图形化界面易上手,如果项目已经在用 Jenkins 可平滑迁移。

在这里插入图片描述

代码整洁了,但结果正确吗?

很多项目到最后面临的困境——没有人敢改老代码。比如开发人员会把已有函数如get() 复制一份再修改,变成了 get1()、get2(),这种做法导致项目逐渐溃烂。根源在于没有人知道修改老代码会不会导致其他地方调用出错。

在开发和测试分离的团队架构中,一个负责任的开发者在写了代码之后要自测,然后提测给测试人员。但是后期大家逐渐会变得不耐烦,从自测 10 种情况到 5 种情况,再到只测一种,最后到完全不自测直接提测,所有的压力都慢慢转移到了测试人员身上。负责任的开发逐渐变成不负责任的开发,问题还是出在机制上。

国外十几年前就开始这个方案:测试人员转岗学编程开发,仅保留少部分的人工测试。开发人员自己写测试代码,测试覆盖率不达标(比如 80%)则禁止合并。

开发人员如何对自己的代码有信心?不是靠聪明才智,因为人总会百密一疏,即使顶尖的程序员也可能会犯最初级的问题,因此自己写测试代码才是最可靠的方案,测试代码覆盖了多种边界情况,即使其他人来改写代码也无需担心挂掉。

最晚什么时候开始自动化测试?

自动化测试很好,但是也面临困境:业务太忙,没有时间写测试代码。

从个人职业发展的角度,把手动操作 Postman 自测的时间用来写自动化测试代码,这样一来,自己的水平得到了提高,后续改代码的时候重测时间也得到了节省,不再是一直堆业务代码,难以成长。

以前中国的大公司项目质量普遍十分糟糕,因为前 20 年是 2C 的红利期,大家在快速抢占市场,但现在到了守地盘的时候,这两年大公司开始重视代码质量问题,建议大家为这个机遇早做准备。

从公司角度,主要看时机。比如 2C 项目逐渐成熟,用户量变大,线上的故障损失已经大于多招开发人员的成本,或者随着项目功能逐渐增加,回归测试时间越来越长,如果一个网站一天上线多次,一天把整个网站所有功能测过来是不实际的,因此自动化测试才能保障持续的高上线频率。而 ToB 项目初期出现了严重 bug 可能就要赔偿客户,因此初期就需要自动化测试。

代码质量评级标准:从下图中可以看到,“优”级别的代码质量标准圈复杂度最多允许 5,类行数不能超过 50,函数行数不能超过 10,测试覆盖率需达到 90%。CODING的合作伙伴优普丰提供了 CSD 认证培训,能够帮助开发者们达到相应的标准,可识别二维码了解详情。

在这里插入图片描述

那么本次的分享就到这里,大家可以前往 B 站观看演讲视频并获取完整 PPT,或者前往 CODING 了解更多。

当前系统开发方法的大规模无效可能归因于其有关系统开发过程的基本假设的不正确或不充分。 在本文中,我们提出了一个信息系统(IS)设计过程的描述性替代模型,该模型强调了约束在定义可行设计空间中的重要性以及作为发现约束的工具的假设的重要性。 此外,约束/假设(C / A)模型不是像当前的主导模型那样假设设计活动按逻辑和规定的顺序发生,而是约束/假设(C / A)模型关注设计活动的相互依赖性质。从三个方面来看,开发和验证系统设计过程的替代模型的重要性。 首先,关于系统设计的实证研究很少,我们将其归因于缺乏指导这类研究的理论。 其次,教育者对我们在这一过程中对学生进行教育的能力提出了严重怀疑。 第三,专业系统设计人员普遍无法按计划,在预算范围内开发系统并无法提供全套指定功能,这令人震惊,甚至令人震惊。以前的研究表明,当客户和设计人员都将IS设计过程视为一种设计时,才能产生出出众的设计。学习经验,并努力互相教育。 约束/假设模型通过区分客户向设计师学习的内容和设计师向客户学习的内容,进一步阐述了这种相互学习的论点。 C / A模型断言,在设计过程的任何阶段,都会同时发生两个对话。 客户/设计者对话详细说明了设计空间,即设计过程中的一组约束,规定了所需的性能和功能,组织和政治氛围,可用于开发和运行系统的资源等。一方面,重点在于解决设计问题的可行解决方案,就技术可行性进行验证,将其可接受的设计空间相一致以及将其详细说明为可实施的设计。 设计空间和实际设计都是每个对话的输入,并且它们之间的相互依赖关系是由于每次对话仅修改其自己的产品的能力而产生的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值