【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
简介：谷歌成立于 1998 年，以搜索起家，到目前为止已经发展了 21 年。在过去的 21 年中，谷歌不断创新，开发了七款产品，拥有超过 10 亿级活跃用户，谷歌的工程师文化一直被认为是优秀且特别的。近日，谷歌开源了其内部一直在使用的代码评审规范，看看谷歌工程师是如何评审代码的。
代码评审标准
代码评审的主要目的是确保代码库的整体质量随时间推移逐步得到提升，所有代码评审工具和过程都是为了实现这一目标而设计的。
为了实现这个目标，必须做出一系列权衡。首先，开发人员的开发任务必须要有所进展。如果他们不提交改进的代码，代码库质量就得不到改善。此外，如果评审人员过于严格，开发人员就没有动力进行持续改进。
评审人员的职责是确保每个 CL（变更列表）的质量，保证代码库整体质量不会随着时间的推移而下降。这是一项艰巨的任务，因为代码库整体质量常常会随着每次提交代码质量的小幅下降而退化，特别是有时候开发团队时间很紧，并认为必须走捷径才能完成交付任务。
评审人员要对他们评审的代码负起责任，确保代码库保持一致性和可维护性。
以下是可在代码评审中使用的准则：
一般来说，如果 CL 达到可以提升系统整体代码质量的程度，就可以让它们通过了，即使它们可能还不完美。
这是所有代码评审准则的最高原则。
当然，也有例外的时候。例如，如果 CL 中包含了系统不需要的功能，那么即使代码写得很好，评审人员也可以拒绝让它们通过。
这个世界上没有“完美”的代码，只有更好的代码。评审人员不应该要求开发人员对 CL 中的每一个微小部分都进行细致入微的打磨，而应该在满足需求和变更重要性之间做出权衡。评审人员不应该追求完美，而应该追求持续改进。如果一个 CL 能够从整体上提高系统的可维护性、可读性和可理解性，那它就不应该仅仅因为它不够“完美”而被延迟几天甚至几周。
评审人员应该提供建议，告诉开发人员哪些方面可以做得更好。但如果这些建议不是很重要，可以在前面加上像“Nit:”这样的前缀，让开发人员知道这只是一个改进建议，他们也可以选择忽略。
指导
代码评审的一个作用是向开发人员传授知识，比如关于一门语言、一个框架或一般软件设计原则的知识。分享知识是提升系统代码质量的一个组成部分。但要注意，如果你的建议纯粹是带有教育性质的，并且对于满足本文所描述的标准来说并不是那么重要，那么请在前面加上“Nit:”，或者以其他方式告诉开发人员，他们并不一定要在 CL 中解决这些问题。
原则
- 客观的技术和数据比个人意见和偏好更重要。
- 在代码风格方面，可以参考谷歌风格指南（http://google.github.io/styleguide）。任何没有在这个风格指南中出现的东西（比如空格等）都属于个人偏好。代码风格应该与原有代码保持一致，如果之前没有规定代码风格，可以使用代码提交者的代码风格。
- 软件设计从来就不只风格问题，也不只是个人偏好问题。它们建立在一些基本原则之上，所以我们应该基于这些原则做出权衡，而不只是基于个人偏好。有时候，一个问题有多种解决方案，如果开发人员能够证明（通过数据或基于可靠的工程原理）几种解决方案是同样有效的，那么评审人员应该接受开发人员的选择，否则就应该基于软件设计标准原则做出决定。
- 如果没有其他适用的原则，评审人员可以要求开发人员与当前代码库保持一致，只要不破坏系统的整体代码质量。
解决冲突
在代码评审过程中出现冲突时，开发人员和评审人员首先要尝试根据本文、CL 作者指南（https://google.github.io/eng-practices/review/developer/）和评审人员指南（https://google.github.io/eng-practices/review/reviewer/）达成一致意见。
如果很难达成一致意见，评审人员和开发人员可以进行面对面会议或者视频会议，而不是只是试图通过代码评审评论板来解决冲突。
如果还不能解决问题，那么就要考虑把问题升级，进行更广泛的团队讨论。让团队负责人参与进来，请求代码维护人员作出决定，或请求工程经理提供帮助。不要因为开发人员和评审人员无法达成一致意见就让 CL 一直挂在那里。
代码评审要注意哪些事情？
阅读原文看了解代码评审内容：https://developer.aliyun.com/article/740790?utm_content=g_1000096647
来源：oschina
链接：https://my.oschina.net/u/4270418/blog/3148149