DevOps
613
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 文档。
服务端检查：建议使用持续集成（持续不断地把代码集成到主干，实现质.........
