概述
代码的预审与审计 (Review and Audit) 其实是两个相似但是又有区别的代码审查流程.
Review(预审)
用于预推送的代码审查称之为 “预审”.
Audit(审计)
用于提交推送的代码审查称之为 “审计”.
“预推送”, 意味着审查阻止了Changes的部署, 而”提交推送”则意味着审查处于 Changes 已经或正在部署中.
预审的好处
“预推送”的预审明显的比”提交推送”的审计给力.在 Changes 提交前预审,你可以获得如下好处:
- 作者有强烈的驱动力来精心做那些小的,有着良好格式的 Changes .这些代码将会是容易理解, 注释充分, 且提供了覆盖上下文的测试用例的.
- 审查者则能在预审中真正有机会提出那些对架构或者实现有重大意义的建议.如果这些建议出现在审计中, 就很可能不会被采纳, 而且如果审计时间和代码提交时间相差的越多则越难被采纳.
- 作者有强烈的驱动力来修复问题,并能积极应对开发过程中受到的反馈意见.因为这些阻止了代码的发布.如果在审计过程中提出问题,作者处理这些问题的驱动力将明显减弱.
- 作者可以在发布前邀请审查者验证那些修复.
- 作者可以更早的跟进反馈, 并在方法或方向上获得正确的指引
- 审查者能够作出更充分的准备来支持生产过程中的 Changes, 同时也有一个熟悉以及推理代码的机会.
- 审查者能够捕获到自动测试难以检测到的问题.例如: 人类审查者可以推理出运行于小型数据集之上的自动测试容易错过的性能问题.
- Changes 之前讨论通常好过他们发生之后.
预审的理论成本是通过在流程中引入了阻止代码提交步骤降低的开发速度以及通常意义上可更好的用于开发的开发者时间. 这是不确切的, 因为这个成本实际上是很低的而且也用到了其他方面:
- Differential 是快速的而且为提交代码, 预审以及性能审查提供了一个非常轻量的过程.
- 作者可以在预审时自由的跟进他们的Changes.在适当的 change 管理下(如果 git 的本地分支), 他们甚至可以轻松的跟进依赖性的 Changes.
- 开发者应该很少的被预审阻止, 即使个别的 Change 被阻止直到通过.
- 当审查者能熟练的有效的判断出问题,整个工作流程实际是上非常轻量的.通常情况下在预审过程中修复问题比生产过程中修复问题要容易.
- 更重要的是这可以有效的识别出结构或者方法中的问题.无论你的测试套件有多好, 他不能识别缺少上下文或者错误传递的方案, 也无法识别那些坑爹的想法.
- 庞大复杂的 Changes 的预审往往也是复杂庞大, 周期性的.几乎所有大的 Changes 都可以分割成独立的便于理解和测试的小片段.预审倾向于鼓励更小系数更好的 Changes.
- 预审可以和静态分析集成, 它可以检测出(大多数情况下检测结果是正确的)如语法, 格式, 命名规范, 样式问题, 拼写错误以及一些程序错误等此类的机械故障代码. 这减少了代码预审所需要的时间, 而审查者也可以关注更加实际的错误, 而不是那些未成年儿童才犯的文体错误.
- 预审创建了一个永久的情景和意图记录这可以用来解释为什么作出这些 Changes .一般情况下这都比代码提交注释说的要清楚.这使得人们更加容易理解早期的代码, 当他出现问题时也能作出适当的调整.
审计的好处
“提交推送”没啥优势.如果你没有被上述理由说服(或者整个团队不为所动), 审计也到是提供了一些审查的好处用以减少冲突的:
- 审计几乎不需要调整现有的开发流程只要稍作培训.
- 审计是完全无阻塞, 发送的通知比预审要少.
- 即使你有预审, 审计也可能发现一些预审中遗漏的问题或者作为预审在低重要度 Changes 的补充工作.
建议
以下是 phabricator 开发者的给出的偏执建议:
- 你过你可以做预审, 那就行动起来. 对那些次要的 Changes 以审计作为预审的补充.
- 如果你不能立即启动预审, 可以尝试先建立审计流程, 然后逐步向预审迁移, 一些类型的 changes (如暂定的changes, 请求代码反馈) 是建立可以被广泛接受的预审流程的天然的敲门砖.牛X的工具套也可以让人类朝着预审流程迈出坚实的一步, 同样使得预审流程的价值更加突出.
- 如果你确实对预审没有兴趣, 那就做点审计工作. 你以后总会改变你的看法的. 代码预审, 一旦拥有, 别无所求.
参考: http://www.phabricator.com/docs/phabricator/article/User_Guide_Review_vs_Audit.html
