什么是CodeReview？
当一个开发人员完成一个功能开发工作后，另一个开发人员会查看代码并思考以下问题：
·代码中是否有明显的逻辑错误？
· 查看单测覆盖要求，是否所有case都已完全覆盖？
· 新代码是否符合现有的编程规范？
为什么CodeReview很重要
1. CodeReview共享知识
所有开发团队的核心任务都是提高团队灵活性：合理高效分配工作并由所有团队成员执行。CodeReview让开发人员接触到新的想法和技术，会编写质量越来越高的代码。
2. CodeReview助于做出更好的评审
评审是一项团队练习，随着产品知识在团队中的传播，团队会做出更好的评审。随着新功能添加到现有代码中，原始开发人员可以提供良好的反馈和评审。任何CodeReviewer也会暴露代码库某模块的复杂性、已知问题和需要关注点。
3. CodeReview指导新工程师快速成长
敏捷的一个特殊方面是，当新成员加入团队时，经验丰富的工程师需要快速指导新成员上路。CodeReview有助于促进有关代码库的对话。通常，团队在CodeReview期间会发现代码中隐藏了知识。CodeReview还有助于确保新见解与现有知识相结合。
CodeReview清单
1) 功能需求
代码是否满足所有要求？要求指出是否有任何遗漏。
2) 对现有代码的影响
此更改是否有任何影响：有时系统中的一个更改可能会导致其他上游和下游系统出现错误，并且很可能会出现一个新的错误开发商或者任何正在编写代码的人可能无法使用该依赖项？这通常与项目中的经验直接相关，我发现你对系统及其环境了解得越多，就能更好地解决这个问题。
3)并发
代码是线程安全的吗？如果使用共享资源，它是否已正确同步？它是否没有任何死锁或活锁？
4)可读性和维护性
代码是否可读？还是对于一个新人来说太复杂了？因为代码会保留很长时间，你需要多次阅读。另一个重要方面是维护，因为大多数软件90%的时间花在维护上，只有 10% 的时间花在开发上，它首先应该是可维护和灵活的。你可以验证代码是否可配置，查找任何硬编码，找出在不久的将来要更改的内容等。
5)编码风格一致性
这是你可以在代码中自动实现可读性的最好的东西。由于许多开发人员参与项目并且他们有自己的编码风格，因此形成一个编码标准并在精神上遵循它符合每个人的最佳利益。例如，使用函数 initialize() 和其他人使用 init() 进行相同类型的操作并不好，保持代码一致，它会看起来更好，阅读更好。
6)性能
如果你正在为高频交易系统开发大容量低延迟电子交易平台，该平台力求微秒延迟，这就要求你仔细监控哪些代码在启动时执行，哪些代码在循环中多次执行。
7) 错误和异常处理
代码是否能够处理错误输入和异常？
8)简单
总是看看是否有任何简单而优雅的替代品可用，至少考虑一下并尝试一下。很多时候想到的第一个解决方案并不是最好的解决方案，所以再考虑一下是值得的。
9)重用现有代码
看看是否可以通过使用现有代码来实现功能，这样做的好处是你使用的是经过试验和测试的代码，这减少了QA测试时间，也让你更有信心引入新库会引入新的依赖项。
10)单元测试
检查是否编写了足够多的 JUnit 测试用例并覆盖足够百分比的新代码。永远不要让你在没有 Junit 测试的情况下通过代码，因为开发人员经常以时间紧迫为借口不开发单测case，但需要相信你值得编写它。
CodeReview最佳实践
1. CodeReview动机
执行CodeReview以提高代码质量会对团队和公司文化产生积极影响。例如：
提交者的动机是一组评审者将检查变更请求：提交者倾向于清理未完成的部分，合并 TODO，并总体上改进提交，同行的认可是许多程序员的骄傲。
共享知识可以通过多种方式帮助开发团队：
- CodeReview 将添加/更改/删除的功能明确传达给团队成员，团队成员随后可以在已完成的工作的基础上进行开发。
- CodeReview有助于提高整个组织的质量标准。
- CodeReviewer有助于改进或巩固变更的编程技术或代码库知识；
- 积极的互动和沟通加强了团队成员之间的纽带。
代码库中的一致性使代码更易于阅读和理解，有助于防止错误，并促进开发人员和迁移开发人员之间的协作。
对于具有外部视角的批判性CodeReviewer而言，意外错误（例如，拼写错误）以及结构性错误（例如，僵尸代码、逻辑或算法错误、性能或架构问题）通常更容易发现。研究发现，即使是简短和非正式的CodeReview也会对代码质量和错误频率产生重大影响。
2. CodeReview时间
CodeReview应该在CI自动静态检查成功完成之后，但在代码合并到master分支之前进行。
3. 准备代码
为了不浪费审稿人的时间和动力，提交易于审稿的CodeReview是参与者的责任：
· 范围和规模。变更应该有一个狭窄的、定义明确的、自包含的范围，它们应该详尽地涵盖。例如，更改可能会实现新功能或修复错误。较短的更改优于较长的更改。
· 仅提交完整的、自我review（通过diff）和自我测试的CodeReview。为了节省评审的时间，运行测试套件，并确保它们通过所有自测/单元测试和代码质量检查。
· 昂贵的人工review时间应该花在程序逻辑上，而不是代码风格、语法或格式的争论上。我们更喜欢使用自动化工具解决这些问题，例如Checkstyle，TSLint等等。
4.寻找CodeReviewer
提交者通常会推荐一名或两名熟悉代码库的评审者。通常，其中一位评审员是项目负责人，项目所有者应考虑订阅他们的项目，以便获得新 CodeReview 的通知。三方以上的CodeReview通常是徒劳的，甚至适得其反，因为不同的评审者可能会提出相互矛盾的更改。
5. 执行CodeReview
CodeReview是不同团队成员之间的同步点，有可能阻碍进度。因此，CodeReview需要及时，并且团队成员和领导需要了解时间投入并相应地确定评审时间的优先级。如果你认为你无法及时完成评审，请立即告知提交者，以便他们找到其他人。作为评审者，你有责任执行编码标准并保持质量标准。评审代码与其说是一门科学，不如说是一门艺术。学习它的唯一方法就是去做；有经验的评审者应该考虑让其他经验不足的评审者参与他们的评审，并让他们先进行评审。这里列出了评审者在CodeReview中应该注意的事项：
目的
这段代码是否达到了作者的目的？每个更改都应该有一个特定的原因（新功能、重构、错误修复等）。提交的代码是否真的达到了这个目的？
问问题。函数和类的存在是有原因的，当评审者不清楚原因时，这可能表明代码需要重写或用注释或测试支持。
想想你会如何解决这个问题。你的代码是否处理了边界情况？代码是否还能做到更短/更容易/更简洁/更快/更安全但功能相同？你是否发现了当前代码未捕获的某些潜在异常？
部分重复的代码通常表示可以提取更抽象或更通用的功能块，然后在不同的上下文中重用。
考虑库或现有的产品代码。当有人重新实现现有功能时，通常只是因为他们不知道它已经存在。有时，代码或功能是可以复用的，例如，为了避免依赖性。在这种情况下，代码注释可以阐明意图，引入的功能是否已由现有库提供？
更改是否遵循标准模式？已建立的代码库通常表现出围绕命名约定、程序逻辑分解、数据类型定义等的模式。通常希望根据现有模式实现更改。
更改是否添加了编译时或运行时依赖项（尤其是子项目之间）？我们希望保持我们的产品松散耦合，尽可能少的依赖。应仔细评审对依赖项和构建系统的更改。
易读性和风格
想想你的阅读体验。你是否在合理的时间内掌握了这些概念？流程是否健全，变量和方法名称是否易于遵循？你是否能够跟踪多个文件或函数？你是否因命名不一致而感到厌烦？
代码是否遵循编码指南和代码风格？代码在风格、API 约定等方面是否与项目一致？
这段代码有 TODO 吗？TODO 只是堆积在代码中，随着时间的推移变得陈旧。让作者在 GitHub Issues 或 JIRA 上提交工单，并将问题编号附加到 TODO，提议的代码更改不应包含注释掉的代码。
可维护性
此 CodeReview 是否会带来破坏测试代码、暂存堆栈或集成的风险？这些通常不会作为预提交/合并检查的一部分进行检查，但是让它们失败对每个人来说都是痛苦的。
此更改是否会破坏向后兼容性？如果是这样，此时可以合并更改还是应该将其推送到以后的版本中？中断可以包括数据库或架构更改、公共 API 更改、用户工作流更改等。
这段代码需要集成测试吗？有时，单独使用单元测试无法充分测试代码，尤其是在代码与外部系统或配置交互的情况下。
留下关于代码级文档、评论和提交消息的反馈。冗余注释使代码混乱，而简洁的提交消息使未来的贡献者感到困惑。
外部文档更新了吗？如果你的项目维护 README、CHANGELOG 或其他文档，是否已更新以反映更改？过时的文档可能比没有文档更令人困惑，并且将来修复它成本更高。
不要忘记赞美简洁/可读/高效/优雅的代码。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
