代码质量

本文于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的人、计算机、以及那个记性不好的自己等等
• 目标受众想要看到什么？

我很喜欢一句话：你有多用心，就有多精彩！