聊Code review(上)

篇前的话：本文主要关注互联网应用程序如何做Code review(代码审查）方面。上篇主要描述什么是code review， 为什么要去做，主要包含哪些内容；下篇，主要讲如何组织人员做代码review，对程序员，以及团队有什么影响，重点在下篇。

从事过几年程序开发的猿猿们（注1），听过、或抱怨过： “某某系统的代码太烂”或“某某人的代码太烂”。本文着重说应用软件的code review，将从这些问题去探讨：为什么要做代码review？如何去做代码review，应该注意些什么？在代码层面之外，它能带来什么惊喜吗？

为什么要做代码review？

先看一段Wiki百科的对 Code reveiw 的论述：

代码审查（英语：Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。

代码质量特性归类为6个方面：功能性、可靠性、可用性，效率、可维护性，可移植性。（注2）      

通俗的讲：程序代码，是解决问题的，是和计算机交互的语言，即指令。代码审查，是为了确保指令下达后，能得到预期的结果，并且不会带来我们不希望的东西。程序是用来解决问题，为我们工作的；代码审查，就是确保代码质量，问题得到正确解决，并不能带来新的、不能接受的问题（问题是永远不可能消灭干净的，问题始终是转换中）。

代码，不仅是人和计算机交互沟通的语言工具，更是程序员之间沟通的主要载体。根据贝尔实验室的研究，程序员80%以上的时间花在沟通上。所以有必要在进入软件开发之前，软件团队应该有对代码规范达成共识、并形成相应的文档。该文档，通过代码review的工作进行不断的完善，使之成为新加入程序员的首要学习的知识文件，帮助其快速融入团队和工作。即应该把代码当作团队沟通的一门语言去进行规范，以减少团队沟通成本。

代码规范，以Java为例，可以包括命名规范和书写规范。命名规范包括，包、类，接口、成员变量、方法声明、局部变量、常量的命名。一般遵循下列原则：

1、 尽量使用完整的英文描述符
2、 采用适用于相关领域的术语 ；如医疗软件中各种专业术语。
3、采用大小写混合使名字可读 ；如驼峰命名。
4、尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一
5、 避免使用长的名字（小于 15 个字母是个好主意）
6、避免使用类似的名字，或者仅仅是大小写不同的名字
7、 避免使用下划线（除静态常量等）

下列是一些不符合规范代码的简单例子：

• int  a, b, c；
• public boolean insert1(...);          

正确的代码，应该反映出业务相关性，如：

• int  previous, current, next;
• public boolean createUser(...);

对于一些有争议的方面，例如接口命名是否采用大写“I”开头，集合类型的变量是否采用复数。团队采用一个统一的标准就好，不需太过纠结。

书写规范，主要指代码样式、方法或接口的声明、表达式使用是否恰当，代码是否需要拆分，是否有重复代码可以抽取出来，注释是否清晰明了，异常处理、日志记录等。是用空格，还是制表符，用什么换行符？接口入参，是否需要加入版本参数？超过100行的方法代码是否可以拆分？异常处理是由程序本身处理，还是抛出给调用方？日志该如何记录？以上这些都需要结合具体应用或部署场景来做决定。一般建议，为了移植性，统一使用空格，换行符应根据生产系统决定。当接口需要给不同用户，提供有差别的服务时，加入版本参数更好。超过100行的代码要看逻辑是否还可以拆成更小的逻辑单元和代码复用角度去衡量。异常处理，当调用方知道异常类型，而且异常和业务相关时；应将异常抛出由调用方处理。当调用方无法知道或确定的异常，应由程序本身进行处理，并做适当的日志记录。

下列是一些简单代码的例子：
           x = x ^ y;
           y = x ^ y;
           x = x ^ y;
和
          temp =  x;
          x = y;
          y = temp;

上面的代码都是做值交换操作，前者高效，后者明了。可读性决定了维护性，比效率更为重要。好的代码，应该让大家一眼能看出来，即必须有良好可读性，例如加上一行注释会不会更好呢：
           //   整型值互换
           x = x ^ y;
           y = x ^ y;
           x = x ^ y;

以上只是一些列举，其它约定还有很多，安全性、效率、依赖耦合性要求等，但一般通用原则是应当加入到通用规范中去，例如开闭原则，迪米特法则，单一职责原则；根据语言的不同，是先编译后运行，还是动态编译；运行环境的不同，如32位，64位，小型机、大型机，会有不同的要求。扩展开来，完全可以写成一本书，此处不一一列举。在做代码规范时，把考虑进去是完全必要的。互联网行业发展快，往往因为市场机遇等原因，时间成本的原因，可以将实现功能、稳定可靠地运行、易于阅读理解和维护，作为基本的软件质量要求的底线；效率、安全、可移植性，作为提升软件质量的次要重点。

代码质量是软件的生命线，应当在团队进入软件开发前，达成的共识，依靠团队的力量，不断完善代码的实践，形成良好规范，达到最终提高代码质量的目的。团队成员的代码质量意识，是做好code review的基础，好的代码体现出来的是程序员的素质和人品。

注1：并没性别歧视的意思，为方便男女程序员统一用“猿猿”代称。

注2： 《代码质量》——Diomidis Spinellis，电子工业出版社，P4。

易荣平，架构师，总体规划成员, 负责国美在线总体架构规划，技术规范制定和技术研发推广。善于分析解决复杂业务需求，提出技术解决方案。了解产品设计、敏捷开发，对技术充满热情，关注电商、互联网、云计算、大数据、人工智能。

个人公众号：荣平