精华内容
下载资源
问答
  • 谷歌开源内部代码评审规范

    千次阅读 2019-10-08 15:33:58
    近日,谷歌开源了其内部一直在使用的代码评审规范,InfoQ 对其进行了翻译和整理,分享给广大开发者,看看谷歌工程师是如何评审代码的。 代码评审标准 代码评审的主要目的是确保代码库的整体质量随时间...

    谷歌成立于 1998 年,以搜索起家,到目前为止已经发展了 21 年。在过去的 21 年中,谷歌不断创新,开发了七款产品,拥有超过 10 亿级活跃用户,谷歌的工程师文化一直被认为是优秀且特别的。近日,谷歌开源了其内部一直在使用的代码评审规范,InfoQ 对其进行了翻译和整理,分享给广大开发者,看看谷歌工程师是如何评审代码的。

    谷歌开源内部代码评审规范

    代码评审标准

    代码评审的主要目的是确保代码库的整体质量随时间推移逐步得到提升,所有代码评审工具和过程都是为了实现这一目标而设计的。

    为了实现这个目标,必须做出一系列权衡。首先,开发人员的开发任务必须要有所进展。如果他们不提交改进的代码,代码库质量就得不到改善。此外,如果评审人员过于严格,开发人员就没有动力进行持续改进。

    评审人员的职责是确保每个 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 一直挂在那里。

    代码评审要注意哪些事情?

    设计

    代码评审中最重要的部分是 CL 的总体设计。CL 中不同代码段之间的交互是有意义的吗?这个变更应该属于代码库,还是属于某个包?它与系统的其他部分可以良好地集成吗?现在是引入这个变更的好时机吗?

    功能

    这个 CL 是否达到了开发人员的目的?开发人员的意图对代码用户来说有好处吗?代码“用户”可以是指最终用户(他们受代码变更的影响)和开发人员(将来要“使用”这些代码)。

    大多数情况下,我们希望开发人员先测试好 CL,确保它们能够正确运行。但作为评审人员,你仍然要考虑一些边缘情况,比如查找并发问题,尝试像用户一样思考问题,并找出只是通过阅读代码无法看到的错误。

    如果愿意,你也可以验证一下 CL。如果一个 CL 会影响用户,比如做出了 UI 变更,那么这是验证 CL 的好时机。如果只是看代码,很难理解一些变更将如何影响用户。对于这样的更改,如果不方便自己运行,可以让开发人员提供功能演示。

    另一个重要的考虑点是 CL 中是否存在可能导致死锁或竞态条件的并发问题。只是简单地运行代码很难发现这类问题,通常需要有人(开发人员和评审人员)仔细思考这些问题,确保不会把它们引入到系统中。

    复杂性

    CL 比实际需要的更复杂吗?从每一层面检查 CL,细到每一行代码,它们是不是太复杂了?函数是否过于复杂?类复杂吗?“太复杂”通常意味着“阅读代码的人难以很快理解它们”,也意味着“开发人员在调用或修改这些代码时可能会引入 bug”。

    过度设计是一种特殊的复杂性,开发人员把代码写得比实际需要的更通用,或者增加了系统当前不需要的功能。评审人员要警惕过度设计,鼓励开发人员只解决现在需要解决的问题,而不是将来可能需要解决的问题。未来的问题应该在它们出现之后再去解决,因为到了那个时候我们可以看到它们的实际状况和需求。

    测试

    要求开发人员进行单元测试、集成测试或端到端测试。一般来说,CL 中应该包含测试,除非这个 CL 只是为了处理紧急情况。

    确保 CL 中的测试是正确、合理和有用的。因为测试本身无法测试自己,而且我们很少会为测试编写测试,所以必须确保测试是有效的。

    如果代码出了问题,测试会失败吗?如果代码发生改动,它们会误报吗?每一个测试都有断言吗?是否按照不同的测试方法对测试进行分类?

    请记住,测试代码也是需要维护的。

    命名

    开发人员是否使用了良好的命名方式?好的命名要能够充分表达一个项(变量、类名等)是什么或者用来做什么,但又不至于让人难以阅读。

    注释

    开发人员有没有用自然语言写出清晰的注释?他们所写的注释都是必需的吗?通常,注释应该用于解释代码的用处,而不是解释它们在干什么。如果代码不够清晰,无法自解释,那就应该简化代码。当然也有一些例外(例如,正则表达式和复杂的算法,如果能够解释它们在做什么,会让阅读代码的人受益匪浅),但大多数注释都应该指出代码中不可能包含的信息,比如这些代码背后的缘由。

    CL 附带的其他注解也很重要,比如告知一个可以移除的待办事项,或者一个不要做出代码变更的建议,等等。

    注意,注释不同于类、模块或函数文档。文档的目的是为了说明代码的用途、用法和行为。

    代码风格

    谷歌为主要编程语言和大多数次要编程语言提供了代码风格指南( http://google.github.io/styleguide/ ),所以要确保 CL 遵循了适当的指南。

    如果你想对指南中没有提及的风格做出改进,可以在注释前面加上“Nit:”,让开发人员知道这是一个你认为可以改进的地方,但不是强制性的。但请不要只是基于个人偏好来阻止 CL 的提交。

    开发人员不应该将风格变更与其他变更放在一起,这样很难看出 CL 发生了哪些变化,导致合并和回滚变得更加复杂。如果开发人员想要重新格式化整个文件,让他们将重新格式化后的文件作为单独的 CL,并将功能变更作为另一个 CL。

    文档

    如果 CL 导致用户构建、测试、交互或发布代码的方式发生了变化,请确保相关的文档也得到了更新,包括 README、g3doc 页和其他生成的参考文档。如果 CL 有移除或弃用代码,请考虑一下是否也应该删除相关的文档。如果文档缺失,要向开发人员索要。

    查看每一行代码

    查看每一行代码。有些东西可以看一看,比如数据文件、生成的代码或大型数据结构,但不要只是粗略地扫一下类、函数或代码块,并假定它们都能正常运行。显然,有些代码需要仔细检查,至于是哪些代码完全取决于你,但你至少应该要理解这些代码都在做些什么。

    如果代码很复杂或者你难以快速看懂它们,导致评审速度变慢,你要让开发人员知道,并在进行进一步评审之前让他们做一些澄清。如果你看不懂这些代码,其他开发人员很可能也看不懂。因此,要求开发人员澄清代码其实也是在帮助未来的开发人员更好地理解代码。

    如果你理解代码,但又觉得没有资格做代码评审,可以确保有资格的 CL 评审人员在代码评审时考虑到了安全性、并发性、可访问性、国际化等问题。

    上下文

    代码评审工具通常只显示被修改的代码,但有时候你需要查看整个文件,确保代码变更是有意义的。例如,你可能只看到新添加了四行代码,但如果你看一下整个文件,会发现这四行代码位于一个 50 多行的方法中,这个时候需要将这个方法拆分为更小的方法。

    你需要基于整个系统来考量 CL。这个 CL 是提升了系统的代码质量,还是让整个系统变得更复杂、更不可测?不要接受导致系统代码质量退化的 CL。大多数系统都是因为累积了很多小的变更而变复杂的,所以要尽量避免小的变更带来的复杂性。

    好的一面

    如果你在 CL 中看到一些不错的东西,要让开发人员知道,特别是当他们以一种很好的方式解决了问题。代码评审通常只关注错误的东西,但其实也应该鼓励和赞赏好的代码实践。有时候,让开发人员知道他们做对了事情比让他们知道做错了事情更有价值。

    总结

    在进行代码评审时,你要确保:

    • 良好的代码设计。
    • 功能对代码用户来说是有用的。
    • UI 变更应该是合理的。
    • 并行编程是安全的。
    • 代码复杂性不要超过应有的程度。
    • 不需要实现可能会在未来出现的需求。
    • 有适当的单元测试。
    • 精心设计的测试用例。
    • 使用了清晰的命名方式。
    • 清晰而有用的代码注释,要解释“为什么”,而不是“什么”。
    • 恰如其分的代码文档化。
    • 代码要遵循风格指南。

    检查每一行代码,查看上下文,确保你正在改进代码质量,并为表现不错的开发人员点赞。

    检查 CL

    在知道了代码评审要关注哪些东西之后,如何有效地进行跨文件代码评审呢?

    • 代码变更有意义吗?它们有没有良好的描述?
    • 先看一下代码变更中最重要的部分,它整体设计得如何?
    • 按照适当的顺序检查 CL 的其余部分。

    第一步:从整体查看代码变更

    先看一下 CL 描述,看看这个 CL 做了些什么。做出这个变更有意义吗?如果这个变更是不必要的,请立即做出回复,并解释为什么不应该发生这个变更。在你拒绝这样的变更时,可以向开发人员建议他们应该做些什么。

    例如,你可以说:“看起来你在这方面做得不错,谢谢!不过,我们正打算移除这个系统,所以现在不想对它做任何修改。或许你可以重构一下另外一个类”?

    注意,评审人员在拒绝一个 CL 并提供替代建议时要做得很有礼貌。礼貌是很重要的,因为作为开发人员,我们要彼此尊重,即使可能意见不一致。

    如果有很多 CL 是你不希望出现的,就要考虑重新调整开发团队或外部贡献者的开发流程,以便在开发新的 CL 之前进行更多的沟通。提前告诉人们哪些事情不要做,这比等他们做完了这些事情再把它们扔掉或者进行彻底重写要好得多。

    第二步:检查 CL 的主要部分

    找到 CL 的主要文件。通常一个 CL 会有一个包含了主要逻辑变更的文件,也就是 CL 的主要部分。先看看这些主要部分,有助于了解整个上下文,加快代码评审速度。如果 CL 太大,以致于你无法确定哪些部分是主要的,可以询问开发人员,或者让他们把 CL 拆分成多个 CL。

    如果 CL 的主要部分存在严重的设计问题,要立即回复开发人员,即使你还没有时间检查 CL 的其余部分。这个时候检查 CL 的其余部分可能是在浪费时间,因为如果主要部分存在严重的设计问题,那么其他部分就变得无关紧要了。

    为什么要立即回复开发人员?原因有二:

    • 开发人员在发出一个 CL 之后会继续开始后续的开发工作。如果你正在评审的 CL 存在严重的设计问题,他们也需要重写后续的 CL。所以,最好赶在开发人员在有问题的设计上花费不必要的时间之前告诉他们。

    • 大的设计变更比小的变更需要更长的时间。为了让开发人员能够在截止日期之前提交代码,同时又能保持代码库的质量,要尽早让他们开始重写工作。

    第三步:按照适当的顺序检查 CL 的其余部分

    在确认整体 CL 没有严重的设计问题之后,试着按照某种逻辑顺序来检查其他文件,确保不会错过任何一个需要检查的文件。通常,在你检查完主要文件之后,按照代码评审工具显示它们的顺序来浏览每个文件就可以了。你也可以在检查主要代码之前先查看测试代码,这样可以对代码变更有一个大致的概念。

    代码评审的速度

    为什么代码评审要快速进行?

    在谷歌,我们对开发团队的整体交付速度(而不是针对个体开发人员写代码的速度)进行了优化。个体开发速度也很重要,但其重要性比不上整个团队的开发速度。

    如果代码评审的速度很慢,就会发生以下这些事情:

    • 团队的整体开发速度降低了。如果个体开发人员无法快速地对评审做出响应,可能是因为他们有其他事情要做。但是,如果每个 CL 都要等待一次又一次的评审,那么其他成员的新特性和 bug 修复就会被延迟,可能是几天、几周甚至是几个月。

    • 开发人员开始对代码评审流程提出抗议。如果评审人员要隔几天才回复一次,但每次都要求对 CL 进行重大修改,开发人员可能会觉得很沮丧。通常,他们会抱怨评审人员太过严苛。如果评审人员能够快速提供反馈,抱怨就会消失,即使他们要求做出的修改是一样的。代码评审过程的大多数抱怨实际上可以通过加快评审速度来解决。

    • 代码质量受影响。如果评审速度很慢,开发人员的压力也会随之增加,因为他们不能提交不甚完美的 CL。缓慢的评审流程还会阻碍代码清理、重构和对现有 CL 做出进一步改进。

    代码评审应该要多快?

    如果你不是在集中精力完成手头的任务,那就应该在第一时间评审代码。

    对代码评审做出响应最好不要超过一个工作日。

    如果遵循这些原则,那么一个典型的 CL 在一天内(如果需要的话)可以进行多轮评审。

    速度和中断

    有一种情况,即如果你正在集中精力完成手头的任务,比如写代码,那就不要打断自己去做代码评审。研究表明,开发人员被中断之后可能需要很长时间才能恢复到之前的状态。因此,从团队整体上看,在写代码时打断自己比让另一个开发人员等待代码评审要付出更大的代价。

    所以,对于这种情况,可以等到你手头工作可以停了再开始代码评审。可以是在完成手头的编码任务之后,午饭后,会议结束后,休息结束后等。

    快速响应

    我们所说代码评审速度指的是响应时间,而不是 CL 完成整个评审过程并提交到代码库所需的时间。理想情况下,整个评审过程也应该是很快的,但单次评审请求的响应速度比整个过程的响应速度更重要。

    有时候可能需要很长时间才能完成整个评审过程,但在整个过程中评审人员的快速响应可以极大减轻开发人员对“慢”评审的沮丧感。

    如果你太忙了,可以先向开发人员发送一个响应,让他们知道你什么时候可以开始评审,或者建议让其他可以更快做出响应的评审人员来评审代码,或者提供一些初步反馈。

    最重要的是评审人员要花足够的时间进行评审,确保代码符合标准。但不管怎样,最好响应速度还是要快一些。

    跨时区代码评审

    在进行跨时区代码评审时,试着在开发人员还在办公室的时候做出响应。如果他们已经回家了,那么最好可以确保他们在第二天回到办公室时可以看到代码评审已经完成。

    带有注解的 LGTM

    为了加快代码评审速度,对于以下两种情况,评审人员应该给出 LGTM(Look Good to Me,没有问题)或者通过,即使他们在 CL 中留下了未解决的问题:

    • 评审人员确信开发人员将会处理好评审人员给出的建议和意见。
    • 其余的改动是次要的,不一定要求开发人员完成。

    当开发人员和评审人员处于不同的时区时,最好可以使用带有注解的 LGTM,否则开发人员可能需要等上一整天才能获得“LGTM,批准”。

    大型的 CL

    如果有人给你发了一个很大的代码评审,而你不确定是否有足够时间完成评审,通常的做法是要求开发人员把 CL 拆分成几个较小的 CL。这样做通常是合理的,对评审人员来说是有好处的,即使开发人员需要做点额外的工作。

    如果一个 CL 不能拆分成更小的 CL,并且你没有足够的时间进行快速评审,至少要对 CL 的总体设计写一些注解,并发给开发人员。评审人员的目标之一是在不影响代码质量的情况下快速对开发人员做出响应,或者让他们能够快速采取进一步行动。

    持续改进代码评审

    如果你遵循了这些指导原则,并且对代码评审过程严格要求,你会发现,随着时间的推移,整个代码评审过程会变得越来越快。开发人员知道为了保证代码质量需要做些什么,并从一开始就向你发送非常棒的 CL,这样评审所需的时间就会越来越少。评审人员也学会了如何快速做出响应。但不要为了提高评审速度而牺牲代码评审标准或质量——从长远来看,这样做并不会让任何事情变得更快。

    紧急情况

    在一些紧急情况下,CL 必须非常快速地通过整个评审过程,在质量方面会有些许的放松。请参看这些“紧急情况”,看看哪些符合紧急情况标准,哪些不符合。

    评审注解

    概要

    • 礼貌。
    • 解释你的理由。
    • 给出明确的方向,指出问题,并让开发人员决定如何在两者之间做出权衡。
    • 鼓励开发人员简化代码,或者添加代码注释,而不只是让他们解释代码的复杂性。

    礼貌

    一般来说,礼貌和尊重是很重要的。一个是要确保你的评论是针对代码而不是针对开发人员。你不一定要一直这么做,但当你想说一些可能会让开发人员感到激动或有争议的话时,绝对有必要这么做。例如:

    不好的说法:“为什么你要在这个地方使用线程,这样做显然不会获得任何好处”。

    好的说法:“在这里使用并发模型增加了系统复杂性,但我看不到任何实际的性能好处,所以这段代码最好使用单线程,而不是多线程”。

    解释理由

    从上面的正面示例可以看出,这样有助于开发人员理解你为什么要给出这些建议。你并不一定总是要在评审中提供这些信息,但如果你能够为你的意图、所遵循的最佳实践或你的建议将如何改进代码质量给出更多的解释会更好。

    给予指导

    一般来说,修复 CL 是开发人员的责任,而不是评审人员的责任。你不需要为开发人员提供详细的解决方案或者为他们写代码。

    不过,这并不意味着评审人员就不应该帮助开发人员。你最好可以在指出问题和给予指导之间做出权衡。指出问题,并让开发人员做出决策,这样有助于开发人员学到东西,并让代码评审变得更容易。这样还可以产出更好的解决方案,因为开发人员比评审人员更了解代码。

    不过,有时候直接给出指令、建议或代码会更有用。代码评审的主要目的是获得尽可能好的 CL。第二个目的是提高开发人员的技能,这样以后需要的评审就会越来越少。

    接受注解

    如果你要求开发人员解释一段你不理解的代码,他们通常会去重写代码,并把代码写得更清晰。有时候在代码中添加注解也是一种恰当的做法,只要它不只是用来解释太过复杂的代码。

    不要只是把注解写在代码评审工具里,因为这对于将来要阅读代码的人来说并没有多大帮助。只有少数情况可以接受这种做法,例如,你对评审的东西不太熟悉,而开发人员的解释却是很多人所熟知的。

    代码评审回推

    有时候,开发人员会回推代码评审。他们可能不同意你的意见,或者他们抱怨你太严格了。

    谁是对的?

    如果开发人员不同意你的意见,先花点时间想一下他们是不是对的。通常,他们比你更熟悉代码,所以可能对代码的某些方面更了解。他们的论点有道理吗?从代码质量角度来看,他们的回推是有道理的吗?如果是,就让他们知道他们是对的,这个问题就解决了。

    然而,开发人员并不总是正确的。在这种情况下,评审人员要进一步解释为什么他们的建议是正确的。

    如果评审人员认为他们的建议可以改善代码质量,并认为评审所带来的代码质量改进值得开发人员做出额外的工作,那么他们就应该坚持。改善代码质量往往是由一系列的小步骤组成的。

    有时候你需要花很多时间反复解释,但要始终保持礼貌,并让开发人员知道你知道他们在说什么。

    激动的开发人员

    有时候,评审人员会认为如果他们坚持要开发人员做出改动,会让开发人员感到不安。开发人员有时候确实会感到沮丧,但这种感觉通常都很短暂,之后他们会非常感谢你帮助他们提高了代码质量。如果你在评审过程中表现得很有礼貌,开发人员一点都不会感到不安,这种担心可能是多余的。通常,令开发人员感到不安的是你写注解的方式,而不是你对代码质量的坚持。

    稍后再解决

    一种常见的回推原因是开发人员希望尽快完成任务。他们不想经过一轮又一轮的代码评审,他们说他们会在后续的 CL 中解决遗留问题,你现在让 CL 通过就可以了。一些开发人员会做得很好,他们在提交 CL 后立即就开发后续的 CL。但经验表明,开发人员开发原始 CL 的时间越长,他们进行后续修复的可能性就越小。除非开发人员在提交 CL 之后立即进行修复,否则在通过之后通常不会再去做这件事情。这并不是因为开发人员不负责任,而是因为他们有很多工作要做,而修复工作通常会被遗忘。所以,最好让开发人员马上把 CL 修复掉。

    如果 CL 引入了新的复杂性,在提交之前必须将其清理掉,除非是紧急情况。如果 CL 暴露了一些目前还无法解决的问题,开发人员需要把 bug 记录下来,并将其分配给自己,这样它就不会被遗漏。他们还可以在代码中加入 TODO 注释,指向已经记录好的 bug。

    抱怨评审太严格

    如果你之前的代码评审很放松,然后突然变得严格起来,可能会引起一些开发人员的抱怨。不过没关系,加快代码评审速度通常会让这些抱怨逐渐消失。

    有时候,这些抱怨可能需要几个月的时间才能消除,但开发人员到最后通常会看到代码评审的价值,因为他们看到了严格的代码评审有助于产出优秀的代码。有时候,抗议最大声的人甚至会成为你最坚定的支持者。

    解决冲突

    如果你遵循了上述方法,但仍然会在评审过程中遇到无法解决的冲突,请再次参阅代码评审标准,了解那些有助于解决冲突的指导原则。

    原文链接: https://google.github.io/eng-practices/review/reviewer/

     

     
    展开全文
  • 代码评审资料整理

    2013-04-18 19:10:55
    该资料介绍了代码评审的意义、评审方法及注意项
  • 代码评审是在软件开发流程中非常重要的一环,由于这个环节需要开发具有一些在写代码时涉及不到的能力,如沟通能力、判断力等,所以这也可能是最具有挑战的环节之一。一个功能的代码可能被写成N种不同的形式,这些...

     

        代码评审是在软件开发流程中非常重要的一环,由于这个环节需要开发具有一些在写代码时涉及不到的能力,如沟通能力、判断力等,所以这也可能是最具有挑战的环节之一。一个功能的代码可能被写成N种不同的形式,这些不同的形式一定程度上决定了执行效率、可维护性、可读性等方面。这些方面大部分情况下很难通过机器来识别,所以代码评审环节不可或缺。

     

        我们先来看下它的定义:代码评审也称代码复查,是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。(来自百度百科)

     

    上面定义中提到了两个比较关键的词:

    • 编码标准

    • 质量

     

        编码标准,并不只是代码是否符合团队的代码规范。代码规范的检查绝大部分是不需要人去做的,用代码规范检查工具就能很轻松的完成,比如前端里面的ESlint。这里,我认为更重要的是评审代码设计及可维护性,比如:

    • 代码逻辑间是否足够的解耦

    • 复杂逻辑是否有明确的注释

    • 可能出异常的逻辑是否有异常处理

    • ......

        还有很多其他重要的评审点,这里不对这些点做详细讲解,后面会出一篇专门讲怎么进行代码评审的文章。

     

        代码的质量直接或间接的决定了产品最终的质量。有的代码是有明显的逻辑错误,而且还是分支错误。如果测试同学漏测了这个逻辑分支,那这个bug就可能会被用户发现,对产品口碑造成影响。有的代码逻辑耦合,虽然不一定马上出bug,对当前版本无较大影响,但随着时间的推移,后面的同学就有可能改动到这块代码,高耦合的逻辑让接手的开发无从下手,就好比拆炸弹,线路错综复杂,一不小心就剪爆了,bug随之而出。

     

     

     

        所以,上面两点就是代码评审最基本的目的,保持编码标准统一与提高产品质量,从而提升整个产品的质量。

     

     

     

        但,还没结束。上面的两点,都是代码评审带来的非常直观的收益。那还可以思考下,有什么其他好处吗?

     

        在我看来,代码评审除了对产品质量有较大的好处,也对开发团队带来很多其他方面的收益。

     

    1.通过代码评审来成长

        假如你是一个菜鸟,在代码评审的过程中,你有机会看到比你厉害的人是如何实现某个功能逻辑的。你可以学习里面的设计并吸收,运用到自己的开发中。长此以往,你的代码水平就会提高。

        假如你是一个老手,你能借助你的经验,发现菜鸟代码中的不足,提出来让他们改进,甚至指导他们应该怎么写。这不仅是在帮助菜鸟提高编码水平,同时也能帮你提高自己对代码的鉴赏能力,也间接提高了你的影响力。

     

     

     

    2.提升团队的技术氛围

        代码评审中发现问题时,审核与被审核的人会讨论代码中的问题。在互相交流中,不仅能使双方达成对代码规范的共识,还逐渐形成良好的技术氛围。在上一篇谈技术氛围的文章中讲到,技术氛围就是大家在一起讨论技术,有时候会被优秀的代码所折服,有时也会为一个设计争的面红耳赤。

     

    3.技术备份

        不做代码评审,往往自己写的代码,只有自己最了解。这就会导致一个问题,假如负责某个模块的同学休假或离职了,而其他人又对这个模块不熟悉,那后面在这个模块上继续开发就会变得相当的困难和痛苦,当开发接手一个经过时间堆积起来的代码模块时,会束手无策,因为,之前对这块没有一点了解。此时必定会损耗较多的时间来熟悉这块的内容,这会严重影响一个处于快速迭代期产品的节奏。

        如果在版本迭代的过程中,持续的有代码评审这个环节,那起码同一个模块是至少有2个人了解的。这类似服务多机部署,没有人将会是整个系统的关键路径。在出现问题时,都有另一个人可以顶上。

        这是一个好事,起码,你可以放心的去度个假。

     

     

     

     

        大部分开发小哥,内心都渴望自己写的代码被其他人认可。所以当知道自己的代码会被别人评审时,开发过程中会付出更多的努力让自己的代码写的更符合规范,逻辑清晰。换个角度思考,如果你去评审一个不写注释,一个函数几百行的代码,你一定会默默的骂娘。当然,你肯定也不期望是被骂的那个,所以你会好好写。这是一个非常好的良性循环。

     

     

     

    题外话:

     

        很多时候,你拿到的代码是令人发指的,问题很多,想骂人。但请克制住自己的怒火,找出主要的问题点,委婉的讲给作者听。别炸锅了,造成两个人的冲突,得不偿失。

     

        之前听一位高人说过,代码评审应该是开发人员之间的社交活动,需避免形式化的推行让这个活动变得无趣。想想,是有那么点道理。

     

        下一篇会具体聊聊如何进行代码评审

     

    展开全文
  • 代码审查的重要性

    千次阅读 2016-06-22 11:19:52
    本文作者为 Hugo Giraudel,主要从各个角度论证了代码审查的重要性以及实现方法。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

    【编者按】本文作者为 Hugo Giraudel,主要从各个角度论证了代码审查的重要性以及实现方法。文章系国内 ITOM 管理平台 OneAPM 编译呈现。以下为正文。

    最近,笔者在Twitter上看到这样一句话:

    可悲的是,对于很多学生、自由职业者以及机构来说,代码审查似乎相当陌生。

    很明显,代码审查的重要性并不为每个人所熟知。你可以说我很天真,但是笔者确实认为所有的IT公司都离不开该过程。显然实际并非如此,真是让我大吃一惊。

    在本文中,笔者想给出关于代码审查的想法,以及为什么我认为这是代码迁移过程中非常重要的组成部分,怎样进行审查等。如果你目前不进行代码审查,或者想要做得更好,希望本文能有助于你!

    什么是代码审查?

    我们生活在维基百科的时代,所以开始之前,先引用一下其中关于代码审查的定义:

    代码审查是计算机源代码的系统性检验(有时被称为同行评审)。其目的在于找到开发初期所忽略的错误,从而提高软件的整体质量。审查的形式多种多样,如结对编程,非正式走查,正式检查等。

    顾名思义,代码审查就是审查一些代码,以确保其能够正常工作,并尽可能改善其性能。

    代码审查的方法

    正如维基百科中的定义,代码审查有多种方法。然而,目前太多的代码都存在于GitHub上,代码审查也就经常伴随着所谓的“pull request”出现。

    Pull request是一个请求,使用分布式版本控制系统(Git、SVN、Mercurial等)对代码库作出修改。它通过“牵引”原代码、写入更改,然后提交请求以便将更改合并。

    得益于GitHub友好的用户界面,这个过程变得非常简单高效,GitHub也概括了大部分Git知识需求。

    论代码审查的重要性

    为什么代码审查非常重要

    那么,既然我们可以不经过任何审查与监督,直接进行代码迁移,为什么代码审查还这么重要呢?毕竟,我们都能胜任该工作。

    从理论上说是这样。但在实践中,有很多原因可以表明代码审查的重要性。让我们来看看其中的几个。

    降低风险

    这可能是最重要的原因。有专人复核我们的工作并不是无关痛痒的,这能降低被忽视的错误所带来的风险。毕竟即使再好的开发人员也有可能一时失察。

    并且,确保没有忘记任何事情总是有必要的。举例来说,前端开发中经常会忽略适当的键盘导航,屏幕阅读器的可用性,适应国际化的灵活性,以及友好的非JavaScript行为等问题,在这里仅列出这四项。

    显著提高代码质量

    清楚点说,这不是单纯的代码标准和代码检查(至少不全是),而是使代码更高效。

    在一个团队里,每个人都有自己的背景和特长,而团队始终需要进步。因此总有人可能提出更聪明的解决方案,更合适的设计模式,或者能降低复杂性或提高性能的方法。

    使每个人都得到提高

    通过合作,每个人都可以相互学习并取得进步。提交代码者很有可能从该工作中得到反馈,并意识到可能存在的问题和需要改进的部分;而审查者也可以通过阅读他人代码学到新的东西,并找出适用于他们自己的工作方案。

    有助于熟悉项目

    当一个团队在做一个项目时,想要每个开发人员致力于应用的每个部分,这是极不可能的。有时候,会出现这种情况:在某一段时间,一个开发人员正为项目的大部分模块辛苦地工作,而另一个人则完全在做别的东西。

    因此,代码审查有助于人们了解其他人所写,但以后可能会需要自己来维护的那部分代码。它促进了代码库知识在团队中的传播,也有可能加快未来的发展。

    怎样适当地进行代码审查

    再次强调,有固定的代码审查过程非常有用,非常重要。不管用什么方法,每个团队创造的代码都应该进行代码审查。

    话虽这么说,但进行有意义的代码审查并不像看上去那么简单明了。不过,别担心,即使做得不好也不会有什么坏处,就是浪费点时间。

    最近,我的团队回顾了之前进行的代码审查。当我们意识到12个开发人员中,只有3个在做代码审查时,我们就明白有些地方出了问题。

    为了改变这种状况,我们的一位 Scrum 专家组织了一次回顾分析,以确定还可能改进的空间,以及我们将怎样改变。

    提前规划

    代码审查做得不够,为了自圆其说,最常用的借口就是,它需要时间——其他人不能或不愿意在这上面花费时间。

    我必须说,笔者并不太理解这种说法,因为我的观点是:如果一个同事直接来找我,让我帮他的忙,我就不会说“我没有时间,也不感兴趣”。反而,我会抽空来帮忙,可能不是现在,是一个小时之后——但是显然,我会花时间帮助他们。为什么呢? 因为:

    • 这就是团队的意义;

    • 他们询问我,这是因为他们看重我的意见,这就值得我去帮助他们。

    *“为什么你不做代码审查呢?”
    “我没有时间。”*

    对笔者而言,“pull request”和同事向我寻求帮助没什么不同。有时候说你没时间是可以接受的,但系统性地拒绝帮助别人,就表明你正在积极地让自己脱离团队。这种行为不友好,也不积极。所以要肯花时间提供帮助。

    为了让开发人员抽出时间,我们就开始考虑让每个程序员每天花一点时间(也许30分钟)审查代码。我们完成每天半小时的代码审查时也不会发现什么意外惊喜:这只是一天中的一部分。

    我们以前还试着大幅度降低 “pull request”包含的代码量。因为曾经的“pull request”非常多——几十个文件中有数以千计的改动。

    我们现在尽量不那么做了。通过创建较小的“pull request”,审查代码变得更加容易,反馈也更加中肯,开发人员也更愿意参与这个过程。“代码迁移量更小也更频繁”。

    结合语境

    我们发现的第二大问题是,我们通常缺乏对代码背景的理解,如果你想要提供有用的反馈,这就很有必要。离开了代码背景,我们通常也只能进行语法检查——这虽然在一定程度上也有用,但远远不够。这时候你就变成了我们所说的“人工审查器”。

    幸好,这个问题比较好解决:给pull request添加一个描述以解释你的目的,如何达到目的。这不需要一大段文字,通常短短几行足矣。将链接添加到and/or也会起作用。Liv Madsen是我们的一位开发者,她甚至增加了截屏——或者相关的截屏视频——来解释她做的东西,这令人称奇。

    论代码审查的重要性

    实际询问

    第三个问题就是我们有时干脆没有意识到需要审查什么。的确,我们每天都充斥着无数的电子邮件和通知 ——邮件太多了,因此很难保存。毕竟我们只是普通的人。

    同样,解决办法很简单:直接向别人询问需要审查的代码。这有很多方法,比如在办公室问一声,或者直接在Slack上给你团队的同事发消息。

    我们基于自己的活动在GitHub上创建了群组,当提交pull request时,总是ping一个群组。群组的成员都会收到通知,并且只要有时间就可以自由地选择如何解决。有时候,当请求特别针对某一个(或几个)人的工作时,我们就直接ping相应的开发人员。

    然后,收到ping消息的人就可以审查代码并发表评论。即使没有什么具体的事需要报告,我们也会留言——表明代码可以合并了。

    因为我们可能会不考虑已有的评论,盲目合并一些pull request,所以就建立了严格的“回复或解决”制度。当收到反馈时,要么你把问题解决,要么在回复中解释为什么不能解决。无论如何都不能留下悬而未决的评论,也当然不能将其与pull request合并。

    总结

    进行定期和高效的代码审查对于保持高质量的代码标准来说必不可少,还有利于开发者之间的知识共享,以及团队的发展。

    要求代码审查并不意味着能力弱,请求他人的帮助也并不值得尴尬,代码审查当然也没什么好羞愧的。另一方面,接受你获得的反馈,并给提交pull request的人提供建设性的(理想情况下,积极的)的评论。

    找到适合你的工作。审查代码应该在代码迁移过程中占很大比重,所以你应该在团队中适时调整,以保证对每个人都有益。

    最后祝各位能够愉快地审查代码!

    本文系 OneAPM 工程师整理呈现。OneAPM 能为您提供端到端的应用性能解决方案,我们支持所有常见的框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验,性能监控从来没有如此简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客

    本文转自 OneAPM 官方博客

    原文链接:https://www.sitepoint.com/the-importance-of-code-reviews/

    展开全文
  • 浅谈软件工程中的代码评审

    千次阅读 2018-10-14 17:23:39
    代码评审这个词相信很多做开发的同学一定不会陌生,线上故障回顾总结有代码评审和单元测试总能够被高频率的提及并作为主要的整改意见,可见代码评审对于软件工程质量保证的重要性。相对于单元测试,代码评审的普及率...

    代码评审这个词相信很多做开发的同学一定不会陌生,线上故障回顾总结有代码评审和单元测试总能够被高频率的提及并作为主要的整改意见,可见代码评审对于软件工程质量保证的重要性。相对于单元测试,代码评审的普及率是相对较少,相信主要原因是代码评审的执行难度高,灵活性大,评审的方法和规则难于标准化等原因,要做好代码评审往往也困难许多,这里除了涉及到具体的技术知识和业务知识,还需要评审双方的沟通能力,表达能力,个人态度以及团队氛围等多种个人软件技能或者团队开放度。

    什么是代码评审

    根据维基百科的定义,代码评审是软件质量保证一种活动,由一个或者多个人对一个程序的部分或者全部源代码进阅读理解。一般来说分为作者和评审者两种角色,作者方提供代码逻辑的介绍和代码,评审者则对提供的代码基于设计,功能性和非功能性等方面认知进行阅读并提出问题。常见的评审组织形式是有同行评审(Peer Review)和小组检查 (Team Inspection)两种方式。

    代码评审目的

    维基百科中提到通过代码的评审发现潜在的问题是代码评审主要的目的。这是不可否认的当时提出代码审查的初衷,但从我个人的实践中发现,分享和表达是代码评审过程最主要的收获。通过代码评审可能无法发现更多的明显的问题,但是一定可以通过评审过程学习和交流发现代码中存在的优点和缺点,让新同学了解业务,让老同学知道可能有更优的设计和用法。同时让同事们在评审中交流表达自己的观点,让同学们有更多的开口机会。
    image

    根据Google 工程团队执行代码评审活动后发现,除了捕捉bug外,还对5大无形收益。

    • 代码评审促进团队和个人开放度
    • 代码评审提升团队交付标准
    • 代码评审激励团队协作
    • 代码评审保持安全至上
    • 代码评审构建社会认可
    什么时候做代码评审

    代码评审最重要的一点是非常灵活,无固定形式,随时随地都可以发起。根据Github和Apache一些开源项目的代码评审实践,往往是将PR合并到主干时进行评审并作为是否合并到Master分支的一个准入条件。对于团队办公集中且人员比较固定的组织,可以基于commit进行评审,那么对于每次需要评审的工作不会太高,时效性也容易把握。

    如何执行代码评审
    作者 (Author)
    • 确定待评审的代码范围

    根据SamrtBear在思科的一个系统小组的研究,一个开发人员一次评审的代码在200-400之间,审查超过400行代码后效率和发现均呈下降趋势。如下图:
    image

    同时,一个小时审查的代码行数应该少于500行,超过500行后效率呈下降趋势。
    image

    • 简单的描述代码业务逻辑以及主要的业务流程
    • 开放的心态接受评审的问题或者建议
    评审者(Reviewer)
    • 准备一个检查列表
    • 了解业务逻辑和主要流程
    • 准备好一些问题,对于不确定或者不明白,尽量以问题形式跟作者沟通,而非质疑。
    • 准备一些解决方案。在提出问题时候,同时思考更好的方法或者解决方案是什么?你的方法好在什么地方?
    代码评审的关注点
    • 功能性 - 功能完整,是否严格按照产品说明书实现产品的所需的功能点
    • 可读性 - 代码易读易懂,其它人能够轻松从代码中读逻辑和设计思想,命名是一个学问。
    • 可测性 - 代码能够轻松被单元测试覆盖,一般来说无法被单元测试覆盖的代码不是一个好代码
    • 可维护性 - 代码运行期间日志输出完整,运维人员或者其它人员可以从日志中了解应用的运行逻辑和状态。
    • 性能 - 天下武功唯快不破,确保代码在可度量的数据量级下面保持一个稳定的性能表现。代码是否存在性能问题,预计峰值流量能到多少。
    • 多线程,并发和锁 - 在并发或者多线程情况下,代码执行结果是否有问题。过去几个月中我们有一个应用是以Shell的方式启动任务,每一个作业一个进程。由于这种方式带来的资源利用率较低,打算改成多个作业运行在一个进程中(容器)以节省系统资源, 上线后发在存在多处线程不安全的问题,实例变量被污染导致线上问题。
    • 安全性 目前虽然有很多的扫描工具可以帮助发现代码安全的问题,但更专业的开发人员在写代码就已经注意这个问题,避免基本的SQL注入,XSS跨域等问题。有兴趣的同学可以参考OWASP CODE REVIEW GUIDE
    代码评审中注意事项
    • 代码评审不仅是技术,也社会学。双方沟通表达能力决定代码评审的效率和有效性。评审者需要注意问题的方式或者语气,就事论事,不上升到精神和思想层面。而作者则需秉承一切问题都可探讨或有更好的方案的想法吸收理解他人的想法,即使评审提出不合适的问题,那么你让队友知道一个正确的方法仍然是团队和组织的收获。
    • 代码评审不应太过于关注代码风格,代码风格的检查完全可以通过IDE或者扫描工具SONARCube集成CheckStyle, PMD,FINDBUG实现。
    代码评审的参考书
    1. 大厂的Java编码标准,如唯品会Java编码规范阿里Java编码规范

    2. 设计模式: Design Patterns, Elements of Reusable Object-Oriented Software

    3. 代码整洁之道: clean code-代码整洁之道

    4. 高性能Java开发: Effective Java, Third Edition

    5. 重构: Refactoring_improving_the_design_of_existing_code

    6. 代码大全: code-complete-2nd-edition-v413hav.pdf

    参考文档
    关于作者

    王云 - 唯品会财务研发微胖中年男,常年关注架构设计,高性能应用设计,软件工程,团队管理等领域。

    展开全文
  • 为什么代码评审(code reviews)很重要 剧透警告:如果你喜欢合理的架构决策,而讨厌成为“关键路径”开发者("critical path" developer),你会喜欢上代码评审的。 敏捷团队是自组织的,拥有跨越团队的技能集...
  • 一次代码评审,差点过不了试用期!

    万次阅读 多人点赞 2020-09-15 09:46:38
    作者:小傅哥 ... 沉淀、分享、成长,让自己和他人都能有所收获!???? ...好的代码往往也很好看 代码是给机器运行的,但...PRD评审、研发设计评审、代码开发、代码评审以及中间一些列的提交物,直到测试完成,上线验证,开量
  • 如何敏捷地进行代码评审

    千次阅读 2017-12-05 15:28:46
    敏捷有没有代码评审? XP推荐结对编程: 结对完成了两个人的代码评审 新手和老手结对,可以让新手快速成长 软件设计和普通开发结对,可以提升开发人员的设计能力 实力相当和人结对,可以认知互补、设计互补...
  • 代码评审的另一个重要功能是,它可以教给开发者一些关于语言,框架,常用的设计原则等知识。 1.1 评审什么 当进行代码评审时,评审者应该评审: 设计:代码是否拥有良好的设计,并适用于项目整体设计。 功能:代码的...
  • 代码评审

    2018-01-26 15:29:12
    通常在大一点的企业中,会定期面对面对代码进行评审 Code Review 的意识 作为一个 Developer ,不仅要提交可工作代码(Deliver working code),更要提交 可维护的代码(Deliver maintainable code) 必要时进行...
  • 代码评审怎么做?

    千次阅读 2018-09-11 15:29:50
    Code Review 是软件开发过程中非常重要的一个环节,不过相对于单元测试,大家可能接触更少,同时,想要做好 Code Review 往往也更困难。...Code Review 翻译成中文是代码评审,具体的定义可以看 wiki。这...
  • 简介:关于代码评审(Code Review)的文章也算是汗牛充栋了,代码评审也已经是许多组织的标准化实践。不过,在许多团队在尝试代码评审实践时,却有如下的疑问: “政治正确”的代码评审活动究竟有没有达到期望的实际...
  • 三种代码评审方法 显然,您阅读代码的频率要高于编写代码的频率。 这里没有新内容。 在讨论对干净代码的需求时,经常会提出这一事实。 或者权衡不同编程语言的优点时。 我认为这两个方面的区分是不够的。 您编写...
  • 谷歌开源了一套代码评审(Code Review)规范,它是谷歌一套通用的工程实战指南,几乎涵盖了所有编程语言与各种类型的项目,这个规范代表了谷歌长期发展以来最佳实战经验的集合,谷歌表示希望开源项目或其他组织能够...
  • The Standard of Code Review (代码评审标准) 代码审查的主要目的是确保Google代码库的整体代码的健康改善。代码评审的所有工具和过程都是为此目的而设计的。 为了实现这一目标,必须平衡一系列的权衡。 首先...
  • 代码评审会议指引

    千次阅读 2014-12-13 09:06:44
    代码评审的目的 第一个目的:确保要发布质量可靠的代码,换句话说,它对于开发过程中的下个阶段是否应该提高代码的质量是个严峻的考验。代码评审能非常有效地发现所有类型的错误,包括那些由于不正确的结构引起的...
  • 代码评审-JAVA代码

    千次阅读 2016-10-23 20:02:52
    重要性 检查项 备注 命名         重要 命名规则是否与所采用的规范保持一致? 成员变量,方法参数等需要使用首字母小写,其余单词首字母大写的命名方式,禁止使用下划线(_)数字等方式命名 不要出现局部变量...
  • 代码评审这点事,元芳你怎么看

    千次阅读 2015-07-26 16:11:42
    百度百科上说:“代码评审也称代码复查,是指通过阅读代码来检查源代码与编码标准的符合以及代码质量的活动。”这篇百科的内容好像是几年前CSDN上的一篇博文,但不管他们怎么抄,代码评审大概就是这么个意思。 ...
  • 对于企业以及开发者来说,如何选择一款好的,合适的代码评审工具至关重要,今天给大家带来的是云效Codeup代码评审的智能化建设,作者:刘力华。 点击链接:https://yunqi.aliyun.com/2020/session106 ,直达9.18云栖...
  • 代码评审的一些建议

    千次阅读 2013-03-19 20:46:16
    代码审查应该被每个工程师当做工作的重要一部分。应当在24小时内给回复,这应当变成共识。感觉有问题的代码,一定要在相应的行上做出评论 (inline comments),以让作者明白问题所在。尽可能把对修
  • 代码评审--流程、工具和最佳实践

    千次阅读 2013-03-25 23:52:13
    1. 代码评审的最大好处是纯社会的,当你知道你的每一行代码都有另外一个人看,自然而然会更加卖力的表现,拿出最好的状态编码,因为每个人都有虚荣心嘛; 2. 代码评审可以及时发现一些容易发现的BUG,而不必将...
  • 代码审查的必要和最佳实践

    千次阅读 2021-05-20 15:17:56
    目录 代码审查的流程 代码审查的争议 加班要累死了,完成项目都来不及,还...识别出设计的缺陷,找到安全、性能、依赖和兼容等测试不易发现的问题。 设立团队质量标杆的最佳实践方式 代码审查工具 一些 Code Re
  • 最近项目组开会进行代码评审,发现可以对代码评审中找到的问题进行一下分类,大概可以分成以下几类问题: 1. Comment 注释没写,或者格式不对,或者毫无意义。在项目当中,注释可以大致分为如下几类: ...
  • 同行代码评审过程中的实践经验

    千次阅读 2014-10-22 10:14:51
    首先,让我们谨记为什么要做代码评审。对于任何专业的软件开发人员来说,最重要的目标之一是能够持续的提高他们的工作质量。即使你的团队里尽是优秀的程序员,你也不能将你...代码评审是达到这个目的的最重要方式之一。
  • 简介:代码评审带来的好处不言自明, 但企业业务快速发展的诉求与代码评审推动落地两者之间, 往往存在矛盾。在如今快速发展的互联网时代,数字化、智能化已经是基础能力,单纯只靠人肉审查的时代已经过去了,基于各种...
  • 记得上次折腾Review Board这个在线代码评审工具还是在一年前,那时的Review Board版本是1.0.3;这周部门的一位同事也在折腾Review Board,不过现在的版本已经升级到了1.5.1了。新版Review Board显然修正了许多旧...
  • 关于在开发人员中以交流促进步和以自动测试提高代码质量的一些想法  石骞 2016年3月17日 13124781413 现状和建议概述 目前观察到的情况是开发人员之间的技术交流较为欠缺、代码的自动化测试水平不高,这两者又会...
  • 1.代码评审的好处 提高代码质量。评审别人的代码,自己的水平也能提高 修复bug的代价最小。自己内部人指出问题,代价最小;其次是测试部门测来;最严重时来自用户反馈。 促进团队之间相互备份。评审别人的代码...
  • 在《浪潮之巅》这本书中,吴军老师描述了在Google早期的工作方式,其中有一段是这么写的:我一般会在吃完晚饭后把代码修改的清单发给克雷格做代码审核,他一般晚上10点左右会回复我,给我修改意见,详细到某一行多了...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,403
精华内容 11,361
关键字:

代码评审的重要性