浅谈code review

原文链接: https://dsx2016.com/?p=710

微信公众号: 大师兄2016

什么是Code Review

中文为代码审查,是指一种有意识和系统的召集其他程序员来检查彼此的代码是否有错误的地方.

通常进行Code Review会有以下效果:

• 更好的代码质量,提高代码的可维护性,统一性,可理解性等.
• 查找缺陷,发现性能问题,安全漏洞,可能的后门和恶意代码等.
• 最佳实践,能够更好的完成任务和需求的有效方法.
• 知识分享,review别人代码的同时,也是学习有益技术的方式之一.

要不要Code Review

Code Review是一把双刃剑,用的好就事半功倍,用的不好,反而对团队和项目有不利影响.

一些道理和技术虽好,但也要看看是什么场合和环境,因势利导,求同存异才是核心所在.

显然review和其他事物一样,也需要花费大量的时间,对于任务本就极其紧张的团队,在如何取舍上值得好好思考一番.

review也需要人与人之间的沟通和配合,同时也比较检验技术深度.

要知道,最难搞定的就是人.人都有惰性,也有自己的一套行为准则和规范,在这个层面强加进来,很容易产生抗拒心理.

最后,怎么说呢,试试又不吃亏,不要心存完美主义,小步快走,快速迭代,不正是软件开发的第一要义吗?

Code Review前置条件

Code Review本身是一件后置工作,有着查漏补缺的作用.

但是推行它也需要准备一些前置条件,能够让团队更快更好的去接受和实施.

• 建立团队规范,不论是代码层面还是协作层面,如命名规则,语法检查,分支规范等.
• 建立完善的文档,方便团队和新人查阅,在内容上大家可以共建和建议,不能某个人一言而决.
• review流程制定,设定职责,设定周期,设定目标,从轻量级代码审查开始,同时建立积极的审查文化.

完成上述基本骨架后,就可以开始尝试review了.

这一时期通常是刀耕火种的时间段,极大概率迎来各种阻力,如果推行之后的效益低于之前的,可以在适当时间调整和放弃.

如何有效的Code Review

先不提细节,每个团队和技术架构都有各自的规范.

从通用的方法层面有以下几点可以进行有效的审查:

• 一次查看少于400行代码
• 一次检查不要超过30分钟
• 使用清单(上述内容提到的团队规范文档,可以更细化为某个目标清单)

人的精力是有限的,了解自己的当前状态尤为重要.

一些常见的规范和审查元素:

• 命名可读性,能自我阐述的最好,英文用词尽量准确(命名是所有程序员的头痛之一)
• 注释,恰到好处的注释,重要的地方及时备注,不需要的地方要删除一定的注释信息,代码既是给机器运行的,也同时是交接给人看的.
• git commit提交规范,不标注信息和不及时commit都是严重阻扰review的因素之一,除了常规的描述信息外,还可以按类型等备注:feat: 新特性/fix: 修改问题/refactor: 代码重构/docs: 文档修改/chore: 其他修改/test: 测试用例修改/style: 代码格式修改等等等

注意到没,上述的都是在信息层面做文章,这也是有效沟通的方式之一.

你的代码,你的注释,你的提交,不仅仅是业务,也同时包含了很多对外的信息,对团队是否友好可读,都潜移默化的表达了出来.

任何事物都可以分为初级/中级/高级,也可以理解为草稿/正文/优化/美化,等层层递进的关系和阶段.

从易到难,你还可以做以下审查(通用的居多):

• 低级的错误,语法错误,多余变量,类型检查,全局污染,强耦合,代码格式化等,通常可以先用自动化插件检查,其次才是人工检查.
• 最佳实践,避免过时的语法,避免过多的if else,避免参数过多,尝试用新特性,语法糖,更好的设计模式,数据结构等重构代码.
• 重复代码,主要看有没有把公共的组件,函数,可复用的代码片段抽离出来,仅此一点,可省去后期大量时间和避免错误发生率.
• 代码的健壮和优雅,是否可扩展,低耦合,逻辑是否健壮,有没有潜在的bug,保证数据和行为的统一性,如统一错误提示,统一缓存等

到此涵盖了review的一小部分,剩下的可以自行扩展,并非是固定的标准,每个团队的实现和目标都不一样.

Tips

一句老生常谈的话,大家都是成年人了,该做什么,怎么做,都要自己独立思考,积极行动.

团队的Code Review有没有推行没关系,有,固然可能更好,没有,也并不妨碍你的自我提升.

但凡有好的事物都应该主动去尝试,去坚持,克服外来因素影响,一个人,也同样可以review自己和同事代码.

尤其是自己的.