浅谈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本身和同事代码.

尤为是本身的.