发布于 2015-12-05 11:08:35 | 238 次阅读 | 评论: 0 | 来源: 网络整理
我们发现清晰,干净,小的,独立的,增量更改更容易得到彻底代码审查 ,更容易得到认可。在代码提交审核前，这里有一些参考建议:
1.使用前面讨论的:如果总体设计需要改变，会使审核者惊讶，这最有可能导致努力白费。所以在发送审核请求前，尽量在同一页面中联系审核者。
2.考虑如何终止你的分支:在独立需要审核的分支中，你有做任何改动吗？我们通过使用 support/post-reviews.py ,这使得易于创建基于提交的“链”。这和互动rebasing( git rebase -i )以分开提交相似。
3.提供上下文的变化情况:明确的动机变化的审查请求,会使审核者不用猜测。强烈建议把JIRA问题与您的审核加到上下文中。
4.遵守代码的风格。
5.在发表前，对自我更改进行回顾:方法是从审稿人的角度来看,如果没有上下文，找出改变的动机容易吗?它符合上下文的代码风格吗?有不必要的变化吗?你做了任何测试吗?
1.做高阶回顾之前先做低阶回顾:你进入任何底层细节的代码前考虑全局。如,你明白改变动机?为什么作者选择特定的解决方案?会感觉有更多不必要的复杂地方吗?如果是有,花时间考虑如果有更简单的方法问题,或者是否可以减少工作的范围。这些都应该先得到解决，然后再做一个逐行深入代码评审,后者是受很多评论反复面对改变了整体的方法。
2.有耐心、有思考和尊重感:当提供(a)反馈评论和(b)评论的反馈(要有耐心、有思考和尊重感)。实践 ego-less programming ,这并不是一场拳击比赛!审核的先决条件，是承认编程很难!应该给审稿人质疑审稿人的好处,即使他们不能表达得很好。审核应该准备预测所有的评论者关切和思考为什么他们决定做一些特定的方式(尤其是如果它偏离标准代码库)。另一方面,审稿人不应该使用“编程是困难的”这一事实作为匆忙的反馈。评论者应该投入时间和精力试图解释他们的担忧的清晰和具体的情况。这个过程是双向的!
3.解决问题之前:我们倾向于给出一个“‘ship it ”,即使我们认为有些问题需要纠正。有时一个特定的问题需要更多的讨论,有时我们会通过IM或IRC或邮件讨论，去加快解决时间。这是很重要的,然而,我们公开的通过这些方式去找讨论的问题。但是会涉及其他想参与但没有邀请到的人。
a. 如果评论者和提交者有问题解决一个特定的“对抗性”问题，然后双方应该考虑邀请另一个评论者参与沟通。我们致力于建立高质量代码,我们应该影响另外的人也这样做。
b. 当一个问题被提交者定位是“已抛弃”状态时,我们期望是必须有一个声音，说明为什么它是被抛弃了。无理由的抛弃是不被鼓励的。
c.如果一个问题被标记为“解决”,我们期望是新旧的不同比照已经更新，(或多或少)参照审核者的评论。如果有重大变化,在issue上的回复评论是我们欣赏的作法。4.直率要求更多的反馈:随时自由的更新评论，令你欣喜又发愁是,在很多情况下，模棱两可的审核者评审时回“就绪”状态，所以，当审核者准备好时。 提交者应该随时与他们通过电子邮件沟通
5.提交者等待“ship it ”:我们经常使用原始的开发人员，或当前的“管理者”，作为一些特定的代码审查者，再添加一些别人的反馈来作参考。值得一提的是,我们经常直接接触另一个关于一个特定的变化/特性之前就开始编码。小的环境通过很长的线化实现审核流程。
6.周密思考，给出"ship it "的审核者:理解审查需要投入大量的时间和注意力:
a.你将会为理解和支持的代码给出“ship it ”
b.你将有责任为高质量的代码给“ship it ”。