代码评审[1]
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
8. 确保你有良好的编码规范作为参考。
审核者遵循的依据应当是组织的编码规范。编码规范是一份被开发人员普遍认可的协议，用于编写优质的代码。 如果要讨论一项并不在代码规范中的代码，你首先要做的工作是建立相关的代码规范。你应该不断地询问自己是 否在Βιβλιοθήκη Baidu论编码规范中的事项。
9. 条条大路通罗马。
尽管开发者使用的方法与你想象的大相径庭，但不一定是错的。审核代码的目标是代码质量。如果达到了目标并 遵循了标准，这就是你想要的。
10. 不要草草地进行代码审核，但需要及时的。
你的同伴正在等你审核！
11. 一次审核200-400行代码。
代码审查结果的指定严重程度
代码中发现的问题的严重程度应该如下所示。审查者必须首先聚焦高级严重程度的问题，然后是中级严重程度的 问题，最后是低级严重程度的问题。
1. 命名规则和代码风格=低级 2. 控制结构或逻辑问题=中级 3. 冗余问题=高级 4. 性能问题=高级 5. 安全问题=高级 6. 可测量性问题=高级 7. 功能性问题=高级 8. 错误处理=高级 9. 可重用性问题=中级
给审查者的提示
1. 批评代码而不是人。
体贴开发者而不是代码。尽可能的使用正面、积极的，并且有利于提高代码质量的评价。评价要与项目标准、开 发守则、性能提升等因素相关。
2. 尊重了解程度不如你的人，并保持耐心。
非技术人员在面对开发人员时，通常认为恃才傲物的比较牛逼，自卑的比较烂。不要用愤怒与焦躁来增强这样的 陈规旧习。
9.不要做"房间里的人"。
不要成为在黑暗处 编码只为买可乐的人。房间里的人和外界失去了联系，看不见外面，并且失控，他没有 开放 、协作的工作环境。
10.请注意审查会议不是解决问题的会议。
11.有助于维护编码标准。
提供要添加到编码标准中的东西，这些事我们讨论时编码标准中没有的东西。挑战之一，开发人员已经 组织比较 麻烦的代码审查工作 ，他们往往不知道接下来的问题将从哪里来。如果你把每个问题的文档编写标准，下次你的 代码审查你可以 用清单检查它 。它还会帮到你巩固你已经掌握的概念，让您更不容易错过反馈的机会 。
5.无论你知道的"karate"有多么的多，其他人也总是会知道的更多。
如果你问，这样的人员可以教你一些新举措。寻求和接受别人的意见，特别是当你觉得不需要的时候。
6.未经咨询讨论，不重写代码。
”重写代码“和”修改代码“只是一步之遥，知道差异、追求在代码审查的框架内 的风格变化，不要一个人孤独 的奋战 。
3. 真正的权威来源于学识，而不是地位。
学识造就权威、权威带来尊重。
4. 注意！审核代码的会议并不意味着解决问题的会议。
5. 使用疑问句而不是肯定句。
肯定句是刺耳的。“在这里，你并没有遵循标准”，这样的话语就是一种攻击，无论你是否有意而为之。“是什 么原因促使你使用现在的方法？”会得到更多的信息。很显然，这样的问题无法以一种讽刺或是傲慢的语气来表 述；但这样做是正确的，如此的对话会让开发人员开始思考，继而寻找更好的方法。
对开发人员的提示
1.最初的评审者应该是作者自己。 2.为自己的评审的代码更趋于关注的东西创建清单。 这些清单中有些是很容易收集整理的。它应该遵循编码标准文档的大纲，因为这是你的评审清单，即便是有问题 ，你可以抓住你很难做的东西，并且跳过你认为很简单的东西。按照你列出来的清单往下测试你的代码，并修改
你发现的问题。这样你不仅仅是减少了团队其他人发现的问题，而且也减少了评审会议的时间，大家都会非常高 兴能够使用很短的时间开评审会议。
3.你和你的代码不等同。
记得整个评审的目的是为了发现问题，并且问题是一定会被发现的。有人发现了你的问题，千万不要介意啊。
4.要理解并接受你所犯的错误。
评审的目的是尽早的发现问题，避免将问题带到以后的产品中去。幸运的是，除了在JPL我们几个开发rocket guidance software，我们的行业很少有致命的错误，所以我们可以，我们应该学会笑，然后继续。
6. 避免使用“为什么”。
尽管很难避免，但如此而为能够充分地改善气氛。正如肯定句刺耳一样，“为什么”也如同一把尖刀。大多数的 “为什么”能够经过变过而被省略，并达到激动人心的效果。例如，“你为什么没有遵循标准？”->”出于何处 原因在这里对标准做了一些变化？”
7. 记得要赞美。
审核代码的目的不仅仅是告诉开发人员如果提高，同样也要告诉他们做得好。人类的本性就是想要被认可，不要 仅仅体现出我们的过错。因为开发是一项创造性的工作，开发人员用”心“在写代码，所以这更需要赞美，即使 更多的批判。
6.大家对代码有一个平均的理解，这有助于提高团队成员的互换性，特别当某个成员无法继续工作的时候就显得尤 为重要。
7.从不同的角度看问题。“另外一双眼睛”增加了客观性。这个原因也是把开发和测试团队分开的原因，同行评审 代码发现问题需要提供给他们一定的距离（译者注：这个距离可以使他们和代码的作者从不同的角度看问题）。
8.骄傲/奖励。对他编码能力的认可对许多程序员来说，是一个显著的奖励。
9.团队凝聚力。一起工作可以让团队成员变得更加紧密。它还可以让因为写代码而造成的隔离得到一个短暂的释放 。
代码审查者所关注的地方主要有以下几点： 通用的单元测试 注释和编码规范 错误处理 资源泄漏 线程安全 控制结构 性能 功能 安全
代码审查
代码评审就是源代码的系统性审核（也叫同业互查），目的是找到并且修复在开发最初阶段被忽视掉的一些问题 ，以此来改进软件质量，同时提高程序员的编码能力。
代码评审为什么重要呢？
代码审查的主要目标有： 1.尽早的发现和修复代码中的缺陷。 2.以更好的共享和理解代码作为团队成员相互学习的基础。 3.有助于保持设计和实现的一致性。 4.帮助发现大家容易犯的共同错误，从而减少团队的返工。 5.构建投资者对执行过程中技术质量的信心。
7.世界上唯一不变的就是变化。
敞开心扉 ，并微笑着接受它。 留心对 您的需求、平台或工具都作为新的挑战 的 每一个变化，不至于最后严重到 不可收拾的地步 。
8.为你的信念而战，但从容地接受失败。
要明白，有时候你的想法会被推翻，即使你被证明是正确的，不被报复或者数落，"我告诉过你了"这句话至少在 好几次 以上，并且不让你离开的想法滋生。
审核者遵循的依据应当是组织的编码规范。编码规范是一份被开发人员普遍认可的协议，用于编写优质的代码。 如果要讨论一项并不在代码规范中的代码，你首先要做的工作是建立相关的代码规范。你应该不断地询问自己是 否在Βιβλιοθήκη Baidu论编码规范中的事项。
9. 条条大路通罗马。
尽管开发者使用的方法与你想象的大相径庭，但不一定是错的。审核代码的目标是代码质量。如果达到了目标并 遵循了标准，这就是你想要的。
10. 不要草草地进行代码审核，但需要及时的。
你的同伴正在等你审核！
11. 一次审核200-400行代码。
代码审查结果的指定严重程度
代码中发现的问题的严重程度应该如下所示。审查者必须首先聚焦高级严重程度的问题，然后是中级严重程度的 问题，最后是低级严重程度的问题。
1. 命名规则和代码风格=低级 2. 控制结构或逻辑问题=中级 3. 冗余问题=高级 4. 性能问题=高级 5. 安全问题=高级 6. 可测量性问题=高级 7. 功能性问题=高级 8. 错误处理=高级 9. 可重用性问题=中级
给审查者的提示
1. 批评代码而不是人。
体贴开发者而不是代码。尽可能的使用正面、积极的，并且有利于提高代码质量的评价。评价要与项目标准、开 发守则、性能提升等因素相关。
2. 尊重了解程度不如你的人，并保持耐心。
非技术人员在面对开发人员时，通常认为恃才傲物的比较牛逼，自卑的比较烂。不要用愤怒与焦躁来增强这样的 陈规旧习。
9.不要做"房间里的人"。
不要成为在黑暗处 编码只为买可乐的人。房间里的人和外界失去了联系，看不见外面，并且失控，他没有 开放 、协作的工作环境。
10.请注意审查会议不是解决问题的会议。
11.有助于维护编码标准。
提供要添加到编码标准中的东西，这些事我们讨论时编码标准中没有的东西。挑战之一，开发人员已经 组织比较 麻烦的代码审查工作 ，他们往往不知道接下来的问题将从哪里来。如果你把每个问题的文档编写标准，下次你的 代码审查你可以 用清单检查它 。它还会帮到你巩固你已经掌握的概念，让您更不容易错过反馈的机会 。
5.无论你知道的"karate"有多么的多，其他人也总是会知道的更多。
如果你问，这样的人员可以教你一些新举措。寻求和接受别人的意见，特别是当你觉得不需要的时候。
6.未经咨询讨论，不重写代码。
”重写代码“和”修改代码“只是一步之遥，知道差异、追求在代码审查的框架内 的风格变化，不要一个人孤独 的奋战 。
3. 真正的权威来源于学识，而不是地位。
学识造就权威、权威带来尊重。
4. 注意！审核代码的会议并不意味着解决问题的会议。
5. 使用疑问句而不是肯定句。
肯定句是刺耳的。“在这里，你并没有遵循标准”，这样的话语就是一种攻击，无论你是否有意而为之。“是什 么原因促使你使用现在的方法？”会得到更多的信息。很显然，这样的问题无法以一种讽刺或是傲慢的语气来表 述；但这样做是正确的，如此的对话会让开发人员开始思考，继而寻找更好的方法。
对开发人员的提示
1.最初的评审者应该是作者自己。 2.为自己的评审的代码更趋于关注的东西创建清单。 这些清单中有些是很容易收集整理的。它应该遵循编码标准文档的大纲，因为这是你的评审清单，即便是有问题 ，你可以抓住你很难做的东西，并且跳过你认为很简单的东西。按照你列出来的清单往下测试你的代码，并修改
你发现的问题。这样你不仅仅是减少了团队其他人发现的问题，而且也减少了评审会议的时间，大家都会非常高 兴能够使用很短的时间开评审会议。
3.你和你的代码不等同。
记得整个评审的目的是为了发现问题，并且问题是一定会被发现的。有人发现了你的问题，千万不要介意啊。
4.要理解并接受你所犯的错误。
评审的目的是尽早的发现问题，避免将问题带到以后的产品中去。幸运的是，除了在JPL我们几个开发rocket guidance software，我们的行业很少有致命的错误，所以我们可以，我们应该学会笑，然后继续。
6. 避免使用“为什么”。
尽管很难避免，但如此而为能够充分地改善气氛。正如肯定句刺耳一样，“为什么”也如同一把尖刀。大多数的 “为什么”能够经过变过而被省略，并达到激动人心的效果。例如，“你为什么没有遵循标准？”->”出于何处 原因在这里对标准做了一些变化？”
7. 记得要赞美。
审核代码的目的不仅仅是告诉开发人员如果提高，同样也要告诉他们做得好。人类的本性就是想要被认可，不要 仅仅体现出我们的过错。因为开发是一项创造性的工作，开发人员用”心“在写代码，所以这更需要赞美，即使 更多的批判。
6.大家对代码有一个平均的理解，这有助于提高团队成员的互换性，特别当某个成员无法继续工作的时候就显得尤 为重要。
7.从不同的角度看问题。“另外一双眼睛”增加了客观性。这个原因也是把开发和测试团队分开的原因，同行评审 代码发现问题需要提供给他们一定的距离（译者注：这个距离可以使他们和代码的作者从不同的角度看问题）。
8.骄傲/奖励。对他编码能力的认可对许多程序员来说，是一个显著的奖励。
9.团队凝聚力。一起工作可以让团队成员变得更加紧密。它还可以让因为写代码而造成的隔离得到一个短暂的释放 。
代码审查者所关注的地方主要有以下几点： 通用的单元测试 注释和编码规范 错误处理 资源泄漏 线程安全 控制结构 性能 功能 安全
代码审查
代码评审就是源代码的系统性审核（也叫同业互查），目的是找到并且修复在开发最初阶段被忽视掉的一些问题 ，以此来改进软件质量，同时提高程序员的编码能力。
代码评审为什么重要呢？
代码审查的主要目标有： 1.尽早的发现和修复代码中的缺陷。 2.以更好的共享和理解代码作为团队成员相互学习的基础。 3.有助于保持设计和实现的一致性。 4.帮助发现大家容易犯的共同错误，从而减少团队的返工。 5.构建投资者对执行过程中技术质量的信心。
7.世界上唯一不变的就是变化。
敞开心扉 ，并微笑着接受它。 留心对 您的需求、平台或工具都作为新的挑战 的 每一个变化，不至于最后严重到 不可收拾的地步 。
8.为你的信念而战，但从容地接受失败。
要明白，有时候你的想法会被推翻，即使你被证明是正确的，不被报复或者数落，"我告诉过你了"这句话至少在 好几次 以上，并且不让你离开的想法滋生。