网站建设详细步骤,艺术字体在线设计免费版,跨境电商怎么做shopee,网页设计 教程网站理论上讲#xff0c;Code Review 对开发人员来说是件好事。它能帮助我们#xff1a;
提高我们代码的可读性尽早发现漏洞和安全问题提供一个安全网络#xff0c;以确保所有任务都得到充分完成
但现实是#xff0c;code review 对于所有相关人员来说通常是一种不舒服的体验…理论上讲Code Review 对开发人员来说是件好事。它能帮助我们
提高我们代码的可读性尽早发现漏洞和安全问题提供一个安全网络以确保所有任务都得到充分完成
但现实是code review 对于所有相关人员来说通常是一种不舒服的体验导致评审具有对抗性、无效甚至根本没有评审。
下面是一个快速指南帮助创建一个有效的 code review 过程。
我们为什么要进行 Code Review
在进行 code review 评审流程时首先要回答的问题是我们 code review 的目的是什么当你问这个问题时你很快会发现有很多理由进行 code review 。甚至可能会发现团队中的每个人对为什么要 code review 都有不同的看法。
发现漏洞检查潜在的性能或安全问题确保代码可读验证功能是否满足要求确保设计合理分享已实现的功能和更新设计的知识检查代码是否符合标准……或者其他几百个原因
如果团队中的每个人都有不同的“为什么”那么他们会在代码中寻找不同的东西。这可能导致一些反模式
code review 需要很长时间因为每个审查者都会发现一套需要解决的问题审查者变得沮丧因为每次审查都会根据谁审查它而提出不同类型的问题审查员和代码作者之间可以进行乒乓球式的审查因为每次新的迭代都会暴露出不同的问题
为代码审查设定一个单一的目标可以确保参与审查的每一个人无论是代码作者还是审查者都了解审查的原因并能集中精力确保他们的建议符合这一原因。
我们在寻找什么
只有当我们理解了为什么要进行评审时我们才能找出评审过程中我们想要寻找的东西。正如我们之前已经看到的那样在评审过程中可能会有许多不同的事情需要我们去寻找我们需要缩小范围关注我们真正关心的事情。
例如如果我们已经决定了代码审查的主要目的是确保代码的可读性和可理解性那么我们将花费更少的时间来担心已经实现的设计并更多地关注我们是否理解这些方法以及功能是否处于有意义的位置。这个特定选择的副作用是有了更可读的代码更容易发现错误或不正确的逻辑。更简单的代码通常也具有更好的性能。
我们应该尽可能地自动化所以人工代码审查员永远不应该担心以下问题
格式和风格检查测试覆盖率性能是否满足特定要求常见的安全问题
事实上人工审查员应该关注的内容可能非常简单——代码“可用”吗它是否
可读可维护可扩展
这些都是无法自动化的检查。从长远来看这些是开发人员最关心的代码功能。
然而开发人员并不是唯一重要的人最终代码需要完成一项工作。我们的业务关心的是代码是否按照预期完成了工作是否有自动化的测试或一组测试来证明这一点
最后它是否满足所谓的非功能性需求考虑到监管要求例如审计或用户需求如文档等事项非常重要。
谁参与Code Review
有了明确的目的和一套在评审中要查找的内容我们就更容易决定哪些人应该参与评审。我们需要决定
谁负责审查代码
很容易认为应该是一位或几位资深或经验丰富的开发人员。但如果关注点是确保代码易于理解那么初级开发人员可能是最适合审查的人——如果一位没有经验的开发人员都能理解代码中的情况那么对每个人来说理解起来可能就很容易了。如果审查的重点是分享知识那么你可能会希望每个人都审查代码。对于其他目的的审查你可能有一组评审人员每次审查时从中随机选择几位。
谁负责审核签字
如果我们有多于一个的评审员那么了解谁最终负责表示评审完成是很重要的。这可能是一个人一组特定的人一定比例的评审员特定代码区域的指定专家或者评审甚至可以被单个否决停止。在高度信任的团队中代码作者可能是决定何时反馈足够且代码已更新以充分反映所提出担忧的人。
谁来解决意见分歧
评审可能有多于一个的评审者。如果不同的评审者给出了相互冲突的建议作者应该如何解决是由作者本人决定吗还是有一个领导或专家可以仲裁并决定最佳方案了解在代码评审过程中如何解决冲突是非常重要的。
Code Review 的时机
“时机”包含两个重要的组成部分
我们什么时候开始 Code Review
传统的代码审查发生在所有代码完成且准备投入生产时。通常在审查完成之前代码不会被合并到主干/主分支例如拉取请求模型。但这并不是唯一的方法。如果代码审查是为了分享知识那么审查可以在代码合并后进行或者代码可以直接提交到主分支。如果代码审查是一个增量审查目的是帮助改进代码设计那么审查将在实现过程中进行。一旦我们明白了为什么要进行审查我们在寻找什么以及谁参与我们就可以更容易地决定何时是进行审查的最佳时机。
什么时候完成 Code Review
不明白何时完成审查是导致审查工作无限期拖延的主要因素。没有什么比永无止境的审查更让人沮丧的了开发者感觉他们一直在做同一件事但产品仍然没有进入生产环节。决定何时完成审查的指南将取决于参与审查的人员和审查进行的时间
通过知识共享评审每个人都有机会查看代码然后可以签字确认。通过网关评审通常会有指定的单个高级人员守门人在解决所有问题后表示完成。
其他类型的评审可能需要一套标准评审完成前需要通过这些标准。例如
所有评论已通过代码中的修复解决所有评论要么导致代码更改要么导致问题跟踪器中的票据例如为新功能或设计更改创建票据为即将推出的功能票据添加额外信息或创建技术债务票据所有标记为阻止器的评论都已以某种方式解决而未来需要观察或学习的评论则不需要“修复”
我们在哪里评论
代码审核不一定要在代码审核工具中进行。结对编程是代码审核的一种形式。审核可以只是将同事拉过来与他们一起浏览你的代码。审核可能通过查看分支并在文档、电子邮件或聊天频道中发表评论来完成。或者代码审核可能通过 github pull 请求或代码审核软件来进行。
总结
进行代码审查时需要考虑很多事情如果每次审查我们都担心所有这些事情那么任何代码都无法通过审查过程。对我们来说实施有效的代码审查过程的最佳方法是考虑
我们为什么要进行审查有了明确的目的审查人员的工作就更容易了代码作者也不会对审查过程感到意外。我们在寻找什么当我们有了目标我们就可以在审查代码时创建一套更集中的需要检查的事项谁参与了谁负责审查谁负责解决意见冲突谁最终决定代码是否可以使用我们什么时候审查什么时候审查完成在编写代码的过程中审查可以迭代发生也可以在过程结束时进行。如果我们没有明确的指导代码最终可以使用那么审查可能会无限期地进行下去。我们在哪里审查代码审查不需要特定的工具审查可以像让同事在办公桌前浏览我们的代码一样简单。
一旦这些问题得到回答我们就应该能够创建一个对团队有利的代码审查过程。请记住审查的目标是将代码投入生产而不是证明我们有多聪明。
