Android开发规范：CodeReview规范

我的新书《Android App开发入门与实战》已于2020年8月由人民邮电出版社出版，欢迎购买。点击进入详情

目录

CodeReview目的

CodeReview清单 VS Bad Smell

CodeReview方式

CodeReview输出

---

CodeReview目的

老生常谈==>>>

代码有这几种级别：1，可编译；2，可运行；3，可测试；4，可读；5，可维护；6，可重用。

通过自动化测试的代码只能达到第3层次，而通过code Review的代码可以上升到更高的层次。

1、提升开发人员代码编写质量

2、现有版本的优化

3、开发人员间代码和业务互相熟悉

 

CodeReview清单 VS Bad Smell

以下摘抄自网络：

常规项

• 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
• 所有的代码是否简单易懂？
• 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
• 是否存在多余的或是重复的代码？
• 代码是否尽可能的模块化了？
• 是否有可以被替换的全局变量？
• 是否有被注释掉的代码？
• 循环是否设置了长度和正确的终止条件？
• 是否有可以被库函数替代的代码？
• 是否有可以删除的日志或调试代码？

安全

• 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
• 在哪里使用了第三方工具，返回的错误是否被捕获？
• 输出的值是否进行了检查并且编码？
• 无效的参数值是否能够处理？

文档

• 是否有注释，并且描述了代码的意图？
• 所有的函数都有注释吗？
• 对非常规行为和边界情况处理是否有描述？
• 第三方库的使用和函数是否有文档？
• 数据结构和计量单位是否进行了解释？
• 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？

测试

• 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
• 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
• 单元测试是否真正的测试了代码是否可以完成预期的功能？
• 是否检查了数组的“越界“错误？
• 是否有可以被已经存在的API所替代的测试代码？

代码审查单还可以利用现有的代码检测工具来实现，比如findbugs等等。

同样，代码审查清单也需要不断迭代更新优化，每个团队得有一个CodeReview代码审查清单(CodeReview-checklist)。  

补充

关于CodeReview清单，另外补充一点：

每个团队都需要有自己的技术选型规范，比如网络请求用什么框架，图片加载用什么框架，Adapter用什么方案等等。

因为每一个功能可能有多种实现方式，为了不在一个项目里面对同一种功能采用多种实现方式（比如使用Glide，又引入了Picasso），保证统一性，所以我们在CodeReview的时候也需要对这一块进行检查。

 

CodeReview方式

1、face 2 face

2、抓重点，比如设计、架构、可读、健壮

3、所有人参与codereview

4、

简单点：技术经理可以从这周提交的代码中找出典型的代码片段，拿出来进行讲解和讨论；

完善点：每个开发者互相codereview，找出有问题的代码片段，拿来给大家进行讨论。

灵活点：遇到问题就可以跟开发人员面对面或者IM沟通。

 

CodeReview输出

每个项目团队每周CodeReview后需要在文档管理系统上总结CodeReview的内容，按照CodeReview-checklist汇报。