关于代码审查的一点想法
2017-07-27 23:32
351 查看
重要性
可以防患于未然,提高系统的稳定性和可维护性,很重要#常见的方式
方式一
在每次提交代码时(或前或后),在代码审查系统中由提交人发起代码审查流程,由指定的审查者审查本次提交的代码.- 优势: 由于每次提交的代码都经过了审查,如有问题会及时改正,并由代码审查系统中的流程保证,如此,代码库中的代码理论上讲,都是符合规范的.
- 不足: 为了保证所有人都严格执行上述流程,必然需要硬性规定,给整个编码环节增加”额外”动作. 由于是规定,而非自发,必然缺乏动力,以至于影响整个审查流程的效果,久而久之,必流于形式.
方式二
要求任何人在任何时候,发现代码中任何人的问题,以特定方式立即向该人提出意见,并公布在统一位置,由专人定期检查意义的修复情况,如未修改,要么给出不修改的理由,要么给出修改时间.如有争议,找经验丰富者判断是否需要修改,并在意见下方给出回复或标记.- 优势: 提出意见者在发现问题后,并提出修改意见,显然能证明其技高一筹,试问有谁不愿意比别人强呢?而被提意见者,肯定定会努力提高自身水平,以降低犯错的机率,有谁愿意天天被人指指点点呢?
- 不足: 问题代码不一定能够找到主人,要么代码记录没了,要么人已经走了; 整个流程不便于监督,目前并未发现此类跟踪系统;在某些时候,不一定要完美的代码.
本人推荐第二种.
相关文章推荐
- 关于知乎话题“程序员有哪些借口可以让自己写出低质量的代码?”的一点想法
- 关于代码生成的一点想法
- 关于代码复杂度的一点想法
- 关于Java数组的一点想法
- 关于春运高峰期的一点想法
- 关于action默认执行execute()方法一点想法
- 关于REST的一点想法,欢迎大家讨论。
- 关于企业级Web2.0的一点想法
- 关于标签系统的又一点想法。
- 关于在线代码运行网站的一个想法
- 关于产品与数据该如何结合的一点想法(一)
- [置顶] 关于一款广告软件的一点想法
- 关于软件规模代码行(LOC, Line of Code)度量的一些想法
- 关于学习的一点想法
- 关于代码重构的一点感想
- 关于博客我的一点想法
- “熵”--关于 读论文的一点想法
- 关于代码运行效率问题的一个总结和一点疑问
- 关于query_cache改进的一点想法
- 关于ARM2440中断源个数的一点想法