问题：人越来越多，代码越来越乱
随着团队成员增多，每个人在缩进、换行、空格以及大小写方面有不同的习惯，导致代码越来越乱。代码风格问题尚且不致命，更严重的是这些问题：
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 认证培训，能够帮助开发者们达到相应的标准，可识别二维码了解详情。