CodeReview的目的是提升代码质量,尽早发现潜在缺陷与BUG,降低修复成本,同时促进团队内部知识共享,帮助更多人更好地理解系统。
如果使用Object-C进行开发,CodeReview分为两个阶段:本地 Review、远端 Review
使用OCLint来进行本地走查,关于其安装和使用,参考文章: OCLint 代码静态分析 自动化 Code Review OCLint 安装与使用 OCLint 规则与结果分析
远端 Review 和 本地 Review 大体相似,区别在与引用构建的脚本的对象从 Xcode 变成了 Jenkins CI ,报告的展示者从 Xcode 变成了 SonarQube 。 具体流程也在自动化 Code Review文章中可以找到。 以上过程可以说还是在自我检查阶段。
在团队(尤其是大规模团队)协作中,一般需要有人工Review的过程,如使用gitflow或其他协作工具,代码提交更新时,需要先经过CodeReview,通过后才允许合并,参考文章: 从零开始Code Review Git 在团队中的最佳实践--如何正确使用Git Flow
一个类只能干一个事情,一个方法最好也只干一件事情。比较常见的违背是一个类既干UI的事情,又干逻辑的事情,这个在低质量的客户端代码里很常见。
例如: 1)缓存是否统一 2)错误处理是否统一 3)错误提示是否统一 4)弹出框是否统一 5)……
代码有没有对其他模块强耦合
1)是否考虑线程安全 2)数据访问是否一致性 3)边界处理是否完整 4)逻辑是否健壮 5)是否有内存泄漏 6)有没有循环依赖 7)有没有野指针 8)是否检查了数组的“越界“错误 9)……
新的改动是打补丁,让代码质量继续恶化,还是对代码质量做了修复
1)关键算法的时间复杂度多少?有没有可能有潜在的性能瓶颈 2)客户端程序对频繁消息和较大数据等耗时操作是否处理得当
衡量可读性的可以有很好实践的标准,就是 Reviewer 能否非常容易的理解这个代码。如果不是,那意味着代码的可读性要进行改进
1)命名对可读性非常重要 2)是否跟系统属性命名造成冲突 3)英语用词尽量准确一点,必要时可以查字典
1)函数太长的不好阅读 2)类太长了,检查是否违反的 单一职责 原则
恰到好处的注释,不是注释越多越好
不要太多,一般不要超过 3 个
作者:忠橙_g 链接:https://www.jianshu.com/p/4b382cc95850