静态测试之代码评审的一些建议

　　Facebook产品经理王准的一些建议：

　　作为审查者，一定要读懂diff;所有被接受的diff必须是在读懂的前提下。做审查者的人要有“将来如果这些代码线上出问题，我要帮助支持”的心理准备。

　　代码审查应该被每个工程师当做工作的重要一部分。

　　应当在24小时内给回复，这应当变成共识。

　　感觉有问题的代码，一定要在相应的行上做出评论 (inline comments)，以让作者明白问题所在。

　　尽可能把对修改的所有意见一次性给出，减少来来回回的次数。比较复杂的建议审查者主动找代码作者来进行线下沟通，达成一致。

　　一般的diff，来回次数不宜超过3次;如果超过3次，想想看，是不是diff 太大，太复杂了。

　　thoughtbot公司的代码评审准则：

　　接受这样的现实：很多编程上的主张都是一种个人观点。应该讨论它们的利与弊，提出你的倾向观点，迅速地达成一种解决方案。

　　提问，而不是命令。(“把这个变量改成:user_id，你觉得如何?”)

　　请求给予说明。(“我不明白。你能解释一下吗?”)

　　避免代码的归属之争。(“我的”，“不是我的”，“你的”)

　　避免使用一些会被认为是有关人身特征的词语。(“笨蛋”，“愚蠢”)要把所有人都看作是有魅力的、聪明的、善意的。

　　要明确。要记着并不是每个人都能理解你的意图。

　　要谦虚。(“我不能确定——我们来分析一下。”)

　　不要用夸张修辞语。(“总是”，“从不”，“永远”，“毫无…”)

　　不要讽刺。

　　展现真实的你。如果你不是幽默型的人，不喜欢使用一些表情符号或动画gif图，不要勉强。如果你是这种人，请自信的发挥。

　　如果有太多的“我不理解”或“另一种方案：”的评论，请专门针对这个人进行交流。可以把你们线下的交流总结成一个帖子附在后面。

　　对审查者的建议表示感激。(“谢谢提醒。我会把它改正。”)

　　理解审查是对事不对人。审查的是你的代码，而不是你。

　　解释为什么代码写成这样。(“因为xxx原因我才写成这样。如果我把这个类/文件/方法/变量改个名会更清晰些吗?”)

　　整理所作的改动，在以后的迭代中重构它们。

　　在做修改的版本上注明代码审查的链接。

　　push提交要基于最早的一轮反馈，并形成一个独立的分支。等这个分支上的任务完全完成了再合并。这让审查者能够根据早先的反馈找到你的单独的更新。

　　努力站在审查者的立场上理解。

　　争取回复每个评论。

　　直到最后一个人退出登录后再合并分支。

　　直到持续集成测试(TDDium, TravisCI,等)告诉你这个分支的测试套件通过后再合并分支。

原文转自：http://blog.csdn.net/lenxer/article/details/8693558