重要性
可以防患于未然,提高系统的稳定性和可维护性,很重要#
常见的方式
方式一
在每次提交代码时(或前或后),在代码审查系统中由提交人发起代码审查流程,由指定的审查者审查本次提交的代码.
- 优势: 由于每次提交的代码都经过了审查,如有问题会及时改正,并由代码审查系统中的流程保证,如此,代码库中的代码理论上讲,都是符合规范的.
- 不足: 为了保证所有人都严格执行上述流程,必然需要硬性规定,给整个编码环节增加”额外”动作. 由于是规定,而非自发,必然缺乏动力,以至于影响整个审查流程的效果,久而久之,必流于形式.
方式二
要求任何人在任何时候,发现代码中任何人的问题,以特定方式立即向该人提出意见,并公布在统一位置,由专人定期检查意义的修复情况,如未修改,要么给出不修改的理由,要么给出修改时间.如有争议,找经验丰富者判断是否需要修改,并在意见下方给出回复或标记.
- 优势: 提出意见者在发现问题后,并提出修改意见,显然能证明其技高一筹,试问有谁不愿意比别人强呢?而被提意见者,肯定定会努力提高自身水平,以降低犯错的机率,有谁愿意天天被人指指点点呢?
- 不足: 问题代码不一定能够找到主人,要么代码记录没了,要么人已经走了; 整个流程不便于监督,目前并未发现此类跟踪系统;在某些时候,不一定要完美的代码.
本人推荐第二种.