Java 代码审查规范
I
目录
1.Code Review 目的................................................................................................................................1
2.Code Review 的前提条件....................................................................................................................1
3.Code Review 的审查范围....................................................................................................................1
3.1 完整性检查(completeness)...............................................................................................1
3.2 一致性检查(consistency)...................................................................................................2
3.3 正确性检查(correctness)...................................................................................................2
3.4 可修改性检查(modifiability)...............................................................................................2
3.5 可预测性检查(predictability)............................................................................................. 2
3.6 健壮性检查(robustness).................................................................................................... 3
3.7 结构性检查(structuredness)............................................................................................. 3
3.8 可追溯性检查(traceability).................................................................................................3
3.9 可理解性检查(understandability)..................................................................................... 3
3.10 可验证性检查(verifiability)...............................................................................................3
4.Code Review 的步骤............................................................................................................................4
5.Code Review 标准................................................................................................................................4
6.Code Review 注意点............................................................................................................................4
6.1 经常进行 Code Review............................................................................................................4
6.2Code Review 不要太正式,而且要短.....................................................................................5
6.3 尽可能的让不同的人 Review 你的代码..................................................................................5
6.4 保持积极的正面的态度.............................................................................................................5
6.5 学会享受 Code Review...........................................................................................................6
7.Code Review 操作................................................................................................................................6
7.1 开发互审.....................................................................................................................................6
7.2 上级检查.....................................................................................................................................6
7.3 冲突解决....................................................................................................................................6
II
1.Code Review 目的
Code Review 是一种用来确认方案设计和代码实现的质量保证机制,通过这
个机制我们可以对代码、测试过程和注释进行检查。
Code Review 主要用来在软件工程过程中改进代码质量,通过 Code Review
可以达到如下目的:
.在项目早期就能够发现代码中的 BUG。
.帮助初级开发人员学习高级开发人员的经验,达到知识共享。
.避免开发人员犯一些很常见,很普通的错误。
.保证项目组人员的良好沟通。
.项目或产品的代码更容易维护。
2.Code Review 的前提条件
代码提交审核前,开发者必须确保代码符合如下条件,审核者需要确保所有
前提条件都已满足方可开始审查,同时也是审查的主要检查点。
.所有代码注释清晰,语法正确,编译通过。
.日志代码完整,业务日志、系统日志分开,中文描述,脱敏处理,状志变
更,全部清晰明确。
.测试代码覆盖全部分支和流程,暂时统一使用工具 Emma(备编译器可下载
对应插件)进行 Coverage Check。
.项目引用关系明确,依赖关系清晰,配置文件描述。
3.Code Review 的审查范围
代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正
确设计以符合设计要求(性能、功能)与设计文档相同等等。
3.1 完整性检查(completeness)
代码是否完全实现了设计文档中所涉及的所有流程和功能点
1
.代码是否已包含所有所需的业务日志、系统日志、异常日志,日志内容是
否完整,日志文件配置是否正确。
.代码是否使用缓存等,配置信息是否正确可配置。
.代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等
3.2 一致性检查(consistency)
.代码的逻辑是否符合设计文档
.代码中使用的格式、符号、结构等风格是否保持一致
3.3 正确性检查(correctness)
.代码是否符合制定的标准
.所有的变量都被正确定义和使用
.所有的注释都是准确的
.所有的程序调用都使用了正确的参数个数
3.4 可修改性检查(modifiability)
.代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门
的常量类等)
.代码中是否包含了交叉说明或数据字典,以描述程序是如何对变量和常量
进行访问的
.代码是否只有一个出口和一个人口(严重的异常处理除外)
3.5 可预测性检查(predictability)
.代码所用的开发语言是否具有定义良好的语法和语义
.是否代码避免了依赖于开发语言缺省提供的功能
.代码是否无意中陷入了死循环
.代码是否避免了无穷递归
2
3.6 健壮性检查(robustness)
代码是否采职措施避免运行时错误(如数组边界溢出、被零除、值越界、堆
栈、益出等)
3.7 结构性检查(structuredness)
.程序的每个功能是否都作为一个可辩识的代码块存在
.循环是否只有一个入口
3.8 可追溯性检查(traceability)
.代码是否对每个程序进行了唯一标识
.是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应
.代码是否包括一个修订历史记录,记录中对代码的修改和原因都有记录是
否所有的安全功能都有标识
3.9 可理解性检查(understandability)
.注释是否足够清晰的描述每个子程序
.是否使用到不明确或不必要的复杂代码,它们是否被清楚的注释
.使用一些统一的格式化技巧(如缩进、空白等)用来增强代码的清晰度
.是否在定义命名规则时采用了便于记忆,反映类型等方法
.每个变量都定义了合法的取值范围
.代码中的算法是否符合开发文档中描述的数学模型
3.10 可验证性检查(verifiability)
.代码中的实现技术是否便于测试
.测试代码是否正确,是否覆盖所有流程
3
4.Code Review 的步骤
目前 Code Review 步骤暂定如下,试行一段时间再根据问题做调整。
1. 代码编写者和代码审核者坐在一起,由代码编写者按照设计文档中的用
例,依次讲解自己所写的代码和相关逻辑,可采用从前端到后台的方式,例如从
Web 层->DAO 层。
2. 代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的
bug;代码编写者和代码审核者都要对这些 bug 记录在案,代码编写者修改后再
次提交审核,代确审核者对应 bug 记录进行回验。
3. 代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。
代码需要一行一行静下心看。同时代码又要全面的看,以确保代码整体上设计优
良。
4.代码审核者根据审核的结果编写代码“审核结果”并将“审核记录”和
“审核结果”提交至 git。
5.代码编写者 git pull 并根据“审核结果”给出的修改意见,修改好代码,
有不清楚的地方可积极向代码审核者提出。
6.代码编写者 bug fix 等全部修改完成后提交,代码审核者再次进行审核,
通过审核则 代码审核者更新本次审查结果并提交至 git ,审核通过对代码不能
再进行修改,任何已通过审核的代码修改必须重新进行审核流程。
7.代码审核者把 Code Review 中发现的有价值的问题更新到“代码规范”
的文档中,对于特别值得提醒的问题可群发 email 或 QQ 给所有技术人员。
5.Code Review 标准
代码审查的基础是我们的设计文档规范、代码规范、日志规范、测试代码规
范,针对新增的业务场景和设计尚未有规范对应时应先确立规范然后再进行代码
审核流程。
6.Code Review 注意点
6.1 经常进行 Code Review
要 Review 的代码太多,那么要重构,重写的代码就会越多。而越不被代码
编写者接受的建议也会越多,唾沫口水战也会越多。建议每一个功能,每一个用
例完成后都可以进行审核,将大任务拆分为小任务进行。
4
.程序员代码写得时间越长,程序员就会在代码中加入越来越多的个人的东
西。
.越接近软件发布的最终期限,代码也就不能改得太多。
6.2Code Review 不要太正式,而且要短
忘了那个代码评审的 Checklist 吧,走到你的同事座位跟前,像请师父一样
请他坐到你的电脑面前,然后,花 5 分钟给他讲讲你的代码,给他另外一个 5
分钟让他给你的代码提提意见,这比什么都好。 而如果你用了一个 Checklist,
让这个事情表现得很正式的话,下面两件事中必有一件事会发生:
.只有在 Checklist 上存在的东西才会被 Review。
.Code Review 变成了一种礼节性的东西,你的同事会装做很关心你的代码,
但其实他心里想着尽快地离开你。 只有不正式的 Code Review 才会让你和评审
者放轻松,人只有放松了,才会表现得很真实,很真诚。记住 Review 只不过是
一种形式,而只有在相互信任中通过相互的讨论得到了有意义和有建设性的建议
和意见,那才是最实在的。不然,作者和评审者的关系就会变成小偷和警察的关
系。
6.3 尽可能的让不同的人 Review 你的代码
如果可能的话,不要总是只找一个人来 Review 你的代码,不同的人有不同
的思考方式,有不同的见解,所以,不同的人可以全面的从各个方面评论你的代
码。 但不要太多了,人多嘴杂反而适得其反,基本上来说,不要超过 3 个人,
这是因为,这是一个可以围在一起讨论的最大人员尺寸。
下面是几个优点:
.从不同的方向评审代码总是好的。
.会有更多的人帮你在日后维护你的代码。
.这也是一个增加团队凝聚力的方法。
6.4 保持积极的正面的态度
程序员最大的问题就是“自负”,尤其当我们 Review 别人的代码的时候,
我已经见过无数的场面,程序员在 Code Review 的时候,开始抨击别人的代码,
质疑别人的能力。太可笑了,分析了一下,这类的程序员其实并没有什么本事,
因为他们指责对方的目的是想告诉大家自己有多么的牛,靠这种手段来表现自己
5
的程序员,其实是就是传说中所说的“半瓶水”。 所以,无论是代码编写者,
还是代码审核者,都需要一种积极向上的正面的态度,编写者需要能够虚心接受
别人的建议,因为别人的建议是为了让你做得更好;审核者也需要以一种积极的
正面的态度向编写者提意见,因为那是和你在一个战壕里的战友。记住,你不是
一段代码,你是一个人!
6.5 学会享受 Code Review
这可能是最重要的一个提示了,如果你到了一个人人都喜欢 code Review
的团队,那么,你会进入到一个生机勃勃的地方,在那里,每个人都能写出质量
非常好的代码,在那里,你不需要经理的管理,团队会自适应一切变化,他们相
互学习,相互帮助,不仅仅是写出好的代码,而且团队和其中的每个人都会自动
进化,最关键的是,这个是一个团队。
7.Code Review 操作
目前我们将 Code Review 分为两个阶段,开发互审和上级审查两个阶殷。
7.1 开发互审
任意两名开发人员(建议不要固定配对,避免思维定势)进行交叉代码审查,
代码编写者准备所开发的代码相关的全部资料列表,包括需求、设计文档、代码
工程、类、方法、配置文件、数据库修改、数据修改等全部资料的版本号等详细
信息,向代码审查者全面介绍代码的目标和设计实现。代码审查者按照需求文档、
设计文档、开发规范进行代码(业务、日志、测试)审查, 代码审查者将审查
结果提交至 git,出现的问题由代码编写者进行修改并由代码审查者复审,复审
结果提交至 git 保留。代码审查者对所审查的代码员责。
7.2 上级检查
开发互审完成后,由上级进行上级审查,流程与开发互审相同,对于三次复
审仍未通过的代码需要代码编写者组内进行检讨问题原因,并书面列出改进计
划。
7.3 冲突解决
当开发互审时对于检查内容出现争议时由上级进行协调解决或逐级向上协
调解决。当上级审查时出现争议时逐级向上协调解决。
6