再论代码规范的落地

在上一篇 论代码规范在传统业务研发部门的落地中，我们尝试着给出一种自认为能够切实有效地将代码规范真正执行下去的策略。本文中我们将尝试更进一步，从全局的角度解释如何将代码规范的落地构成一个闭环，以最大限度地确保代码库中源码的质量。毕竟正如上一篇文章中已经提到的"代码质量是公司赖以生存的土壤。产品质量是红线，任何时候都不能逾越"。

1. 再谈代码规范的背景

没有人会否认源码质量对于软件产品质量的重要性；同时也很少有人否认很多软件公司，尤其是传统软件行业公司在这一方面做得并不好。笔者尝试以自身经历总结下原因：

1. 公司自身业务特性。例如软件产品化，生命周期跨度大，维护时间长；需求奇葩，冗杂，时限短等。
2. 缺乏相应团队文化。例如几乎没有相应培训机制，没有制度化的代码审查，缺乏奖惩措施等。
3. 其它团队问题。例如人手紧张，人员职业素养偏弱，待遇偏低，团队成员更迭速度快（这不仅仅体现在团队成员的入/离职上，还有就是团队内部组员经常以救火队员的形式在各个小组之间频繁流动）等。
4. 其它。

软件开发是一项集体活动，而集体活动就必然涉及大量的交流沟通；作为软件产品基本组成单元的源代码是人类大脑活动的产物，而"一千个人心中有一千个哈姆莱特"。软件开发的这两个特性就决定了：

1. 如果放任自流，那每个人的代码几乎就只能本人维护，其它人接手基本就意味着重写。
2. 上面总结的各种原因恰恰放大了交流中的问题。

因此，我们需要为代码约定一套标准和最佳实践，使一个项目乃至一个公司的代码具有完全统一的风格，就像同一个人编写的一样，最终达到降低交流成本，提升产品质量的目的。

2. 实现代码规范闭环式落地

接下我们就尝试实现代码规范检查落地的完整流程。

2.1 使用SCM的pre-commit功能实现预检查

这一步至关重要，且必须作为三步曲中的第一步来执行。它的先行能让接下来的其它操作执行起来的可能性和彻底性大大增加。

鉴于公司自身软件工程组织管理的限制，我们必须借助这一步来实现鲶鱼效应 ，强迫研发人员开始正视代码规范，让他们无法回避“自己所犯的错误”和"历史债"。

相关参考：

1. SVN集成Checkstyle实现代码自动静态检查
2. CheckStyle规则之ImportControl
3. SVN集成PMD实现代码自动静态检查
4. SVN之常用Hook

2.2 推进相应IDE辅助插件落地

通过推动相应的IDE辅助插件的落地，我们可以极大缩短引入错误的发现时间，降低修复成本。

有了第一步的加持，这一步措施的推进和执行情况将会顺利很多。尤其是对于那些尚未建立相应反馈机制的公司而言。可以说正是有了第一步，这一步才能真正得到执行，彻底执行。寄希望于有限的几次培训，人员的自觉性，以及全人工的事后代码审查，至少在笔者所在的公司是失败了。

以笔者的真实经历，在开始执行第一步并层层加码规则，加上为所有的SCM仓库嵌入校验钩子，以及不断宣扬"强烈建议安装相应IDE插件，不要把规则校验拖延到SCM提交时"，三个月之后的现在，依然有不少研发人员没有完成这一步操作！

相关的IDE插件安装方法，以及如何进行自定义规则的导入？ 相应的教程在网上比比皆是，关键字："Eclipse CheckStyle"。

2.3 实现代码质量的量化

在实现了上面两步（更准确地说应该是上面第一步）之后，所有的团队成员都确信源代码仓库的代码质量正在向好的方向发展，但旧有债务有多少？本次的提交修复了多少，又引入了多少新的？这些我们都无法得到准确的答案。

正如管理学之父彼得德鲁克所说：“如果你不能度量它，你就无法改进它”，我们还需要最后一步——借助SonarQube来建立SCM源代码度量系统，量化与代码质量相关的一切操作，最终做到人人心中有畏，领导心里有底，奖惩有凭。

通过引入SonarQube，除了引入其独有的规则来实现更丰富的校验外，还能通过基于全部源码的整体校验，找出更为隐蔽的问题，进一步加强代码质量。

这一步因为缺乏第一步中的强制性，所以我们需要提供额外的扩展来确保效果：

1. sonarqube + nexus 分析项目组成员代码状况,并生成报表
   通过定期（周/月/年）生成相应统计报表并发送给对应人员以及负责人的方式来确保人员对于规则的理解和执行。
2. WebHook - Office Site
   WebHook作为官方提供的扩展功能，借助它我们可以提供实时的分析结果反馈，将每次的分析结果发送给对应的研发人员和负责人，确保SonarQube特有规则的执行，降低修复成本。

第一步的pre-commit虽然很美好，但其校验相较于SonarQube存在不少的局限（例如缺乏对于其它语言的校验，缺乏SonarQube特有规则，只能进行增量校验等），而且最重要的是SonarQube提供了强大的度量能力，综上所述SonarQube是作为压轴出场的。

相关参考：

1. SonarQube的搭建
2. SonarLint与Eclipse集成

3. 总结

以上三步环环相扣，有着严格的时间迭代顺序。最终实现"提交前强制增量检查"；"提交后整体检查并将检查结果通知相应人员"；最后就是"周期性地量化度量报告"，通过这些量化成果，领导层就能进行相应的奖惩，进一步强化代码规范的落地。

4. 全局视角

代码质量保证-整体流程图