本文于2017年6月21号发布在个人博客中,因为个人博客关闭,全部迁移到CSDN,以下是正文:
今天召开了项目组例会,搞了一件非常大的事情:部门代码质量规范!
规范
规范提了很多要求:
- 个人级review
- 代码合入主干前必须经过多个流程
- 开发者review
- core review
- PM review
- 项目组成员包括:
- PM:负责产品层面的把关,决定某个特性是否合入版本
- core:核心开发者,对代码架构非常熟悉,负责技术层面的把关,决定某个实现方式是否合适
- others:开发者、其他对该项目感兴趣的群众,对于项目成员提交的代码可以发表个人意见,但不影响代码的合入
- 代码review工具:gerrit
- 各角色职责:
- PM:workflow -1 ~ +1
- core:code-review -2 ~ +2
- others: code-review -1 ~ +1
- 代码合入主干前必须经过多个流程
- 版本级review:飞检
- 固定版本周期从同能力中心的飞检资源池中找两名非项目组成员,由项目组架构师负责功能讲解,挑出高风险片段进行飞检
丑媳妇见公婆
经过最近一段时间的CICD之旅,我逐渐明白一些事情,代码质量提升的关键在于参与编写代码的每一个人,外在施压效果很有限。
我举个编写单元测试用例的例子。早上上班,打开邮箱就看到了每日构建的报告,报告内容大致是:
startExecution_case01.....
startExecution_case02.....
startExecution_case03.....
startExecution_case04.....
stopExecution_case01.....
stopExecution_case02.....
stopExecution_case03.....
stopExecution_case04.....
xx test cases, xx failure...
再看一个,文件命名的例子。打开项目目录树:
project-------
......
|---testCase
|---JamesUnitCase
|---TomUnitoCase
......
在诸多的代码提交中,绝大部分提交代码行数超过100行,打开一看,“哦,原来是一个不了解抽象的家伙”。
如何提升质量
我觉得想要提升代码质量,需要时刻记住:
- 目标受众是谁?这里的目标受众包括:代码review的人、计算机、以及那个记性不好的自己等等
- 目标受众想要看到什么?
我很喜欢一句话:你有多用心,就有多精彩!