CODING DevOps 代码质量实战系列第一课：代码规范与 Git Flow

讲师介绍

杨周
CODING DevOps 架构师
CODING 布道师

连续创业者、DIY/Linux 玩家、知乎小 V，曾在创新工场、百度担任后端开发。十余年一线研发和带队经验，经历了 ToB、ToC、O2O、国内、出海各类项目，见证了云计算时代的诞生，擅长研发最佳实践：Code Review、DevOps、Git Workflow、敏捷开发、架构、极客办公硬件。

背景

随着 ToB（企业服务）的兴起和 ToC（消费互联网）产品进入成熟期，线上故障带来的损失愈来愈大，代码质量愈来愈重要，而「质量内建」正是 DevOps 核心理念之一。并且提升代码质量的最佳实践，不仅适合新项目，也为老项目提供完善的渐进式方案。

常见代码质量问题

• 英语拼写错误
• 泄露密码
• 无效注释
• 魔法数字
• hard code（写死）
• 缩进等代码风格问题

如何解决代码质量问题

Code Review

第一步是锁定主干，禁止直接提交，采用多分支开发。先拉取一个分支，修改代码并推送分支，而后发起一个合并请求，请同事进行代码评审了。比较高级的技巧是推代码时自动建立一个合并请求，合并后临时分支被自动删除。

建立合并请求后，须要把连接发给同事进行评审，这也是敏捷开发倡导的一个理念——高效沟通。通常选择直接经过企业聊天工具通知同事，若是不及时通知，可能同事好几天才会看到，耽误项目进度。收到合并请求后，请尽可能作到当天评审，不要拖延。

须要注意每次提交代码只提交最小粒度的一件事，即「原子性提交」，而不要把几件事作完一次性提交。好比有三件事，其中一件是修 Bug，结果修的有问题要回滚。若是三件事分三次提交，就能够轻松回滚有问题的，另外两个正确的不受影响；而一块儿提交的话就无法回滚。

Code Review 必定是在每次代码合并进去以前进行评审，发现问题减小故障，若是错误的代码已经合并上线了，这个时候再看就叫「故障反思会」而不叫「Code Review」，就没有意义了。

Lint 代码规范的增量检查

Lint 叫代码静态扫描程序，各类语言对应的 Lint 程序是不一样的，对应的规范也不一样：

• Lint 的使用时机

一、在 IDE 里实时运行，边写边检查，这样是最方便的，缺点是须要每一个人都进行配置。

二、Git commit 提交代码时检查：每一个 Git 项目都有 .git/hooks 目录，修改里面的 pre-commit 脚本，便可在提交代码时进行拦截检查。缺点是可被删除。

三、最可靠的就是服务端检查。当代码推送到服务器上时，进行持续集成检查，这种方式很是可靠且不会被删除，缺点就是不如本地那么及时。

这三种方式通常结合使用。

• 增量检查

老项目的规范问题每每不少，一次清理干净须要耗费大量人力，并且一次改动的代码越多，风险就越高，可能致使线上故障，尤为是缺少自动化测试的项目。

因此建议使用增量检查。若是同窗们对 git 命令熟悉的话就很好理解，增量检查就是 git diff。在本地提交时 git diff 能够拿到全部新增的、修改的和删除的文件，只要把删除的文件排除掉，把别的文件挑出来，传递给 lint 程序就能够了。同窗们必定要熟悉 Linux 命令、git 命令，不要一直用 git 的图形界面，那你就很难掌握这些内容。

访问 CODING 帮助文档（ https://help.coding.net/ ），搜索「增量检查」，便可看到完整的配置代码。

Git workflow

单兵做战的时代就如上图所示，一我的提交代码，不须要什么工做流，一直往主干里提交就能够。而如今多人协做作项目时，每一个人都往主干里提交就会产生冲突。以下图所示，多分支开发，每一个需求每一个 Bug 都拉一个小分支，开发完毕再合并进主干里。

有两种经常使用的工做流，第一种最简单叫：Feature branch workflow（需求分支工做流）。能够从下图中看到主分支里拉下来两个分支，一个作登陆，一个作支付。登陆作完就合并进去，后续有个短信的 bug 修复了，也合并进去后就发布了，但支付功能还在开发，这时就会出现问题。原本登陆和支付要一块儿上线，表示同一时期同一阶段的两个功能相互有依赖，结果由于线上的短信 bug 修复，就把登陆先带上线了，这就致使了问题，因此大项目不适合用这种模式，而是使用第二种。

简易 Git Flow 是双分支的开发模式，除主分支外还有一个 develop 分支。Develop 分支对应敏捷开发里的迭代，每次迭代都会建立一个 develop，此次迭代里的全部功能开发完都合并到 develop，而不会合到主干上。主干保持随时可发布的状态，有 Bug 就在主干上修，等此次迭代所有结束，再把 develop 合到主干上。

Fork

Fork 不是工做流，团队协做必定不要用 Fork。Fork是专门用于开源项目的。当咱们试图修改开源项目时，因为没有建立分支的权限，只能把这个项目复刻（官方翻译）成为本身的项目，而后再在本身的项目里拉分支，修改代码，最后发起一个跨项目的合并请求，合并到做者的开源项目里，若是后面还想再开发的话，须要再同步过来。因此 Fork 仅仅用于开源协做，彻底不适合团队协做，同窗们千万不要搞错，具体的文档能够扫码进行查看。

结语

最后总结一下代码质量的升级路线。从最原始的提交主干不检查代码，不检查规范，到锁定主干进行人工检查，而后人工检查太累，但愿能作自动检查，把尽可能多的东西都作成自动检查。但有些东西是自动检查作不了的，好比代码里使用了拼音，语法没有报错；或者英文单词用错，好比用户的「积分」应该使用points 而不是integral。因此不能看见自动化检查过了，就直接赞成合并，这是不负责任的作法，必定要进行人工检查。

通过这个流程，同窗们的代码就会很是干净漂亮，团队协做的风格也一致了。通常会挑一个知名的业界大厂的代码规范，而不要本身发明规范，这样不只不能服众，并且之后再参加开源项目的话，难以和业界保持一致。

点击观看课程回放

关于 CODING，了解更多