`

如何高效迅速的进行CodeReview

阅读更多

前言

很多公司都要求项目做CodeReview,但很多人第一次CodeReview往往不知道该如何做,也不知道为什么去做。笔者参加过几个项目的CodeReview,发现一些共性问题:

  • 有时候参与Review的人太多了,意见太分散,Review时间拉的很长,发现问题效率低;

  • 有时候会发现一个CodeReview时间很长,参与者会觉得煎熬和浪费时间;

  • 有时候不太了解对方评审的东西,没法跟上大家的思路,影响效率;

  • 有时候走查的代码量太大了,无法做到详细走查;

  • 有时候会看到有些人无所事事、精神不集中、不发言,影响效果。

对这些问题,希望本文中的一些建议能够缓解上述问题,能使大家更快的了解CodeReview的意义和方法,有经验的人能够更加快速有效的进行CodeReview。

 

CodeReview的目标和原则

CodeReview的目的是提升代码质量,尽早发现潜在缺陷与BUG,降低修复成本,同时促进团队内部知识共享,帮助更多人更好地理解系统。

建议CodeReview的原则如下:

  • 发现代码的正确性

代码审查用意是在代码提交前找到其中的问题——你要发现的是它的正确性。在代码审查中最常犯的错误—几乎每个新手都会犯的错误是,审查者根据自己的编程习惯来评判别人的代码。

  • 不仅是在Review Code,更是在分享和学习

Code Review最重要的是讲解者分享业务流程和设计思路,参与者通过这些讲解获得这些信息,使得更多人理解这个系统,提升团队整体水平,使得团队维护代码的能力提升。

  • 高效迅速完成CodeReview

我们不能为了应付匆匆忙忙的进行一次代码审查,效率也是很重要的,如果不能保证Code Review目的实现,那么评审便是徒劳的。

 

如何高效完成CodeReview?

参与者要检查设计的合理性以及业务逻辑是否错误,检查代码可读性;讲解者要想办法分享设计、技术、经验等知识。

1.检查设计的合理性和业务逻辑的正确性:

  • 代码的设计是否符合设计要求

    • 如果存在代码和设计有出入的地方需要问询为什么要变动,因为这些变动有可能是出于开发者在真正设计代码时候的深入考虑,或者是由于一时大意出现偏差。

  • 业务逻辑是否正确

    • 业务流程是否按照详细设计的流程走,不要出现原本是先A流程后B流程而设计的时候出现先B后A,或者丢失流程。

    • 某些传入参数是否合理:判断某些接口的参数输入是否是冗余的,比如输入A字段可以满足A接口里面的所有操作,那么多输入一个B就冗余的。

    • 数据库字段的设计,数据库的设计是对实际业务的映射,我们要保证每一个字段的出现都反应实际业务并且经过合理性的验证,比如设计table1的时候A字段在table2中已经出现,并且A和B表有相应的关联,那么要注意A字段对于table1的冗余是否有合理性,如果没有合理的说服性可以去掉A,而节省对A字段的维护成本(存储空间,更新操作等)。

    • 某些判断是否合理,比如某些参数的输入金额是否可以为0的判断等等。

    • 系统交互是否合理,比如在代码设计的时候没有关注考虑系统交互的顺序而造成有些信息不能获取到;比如获取支付方式的费率信息必须要等待支付的时候才能拿到,那么获取这些信息就应该放在pay_trans的时候而不是create_trans,大多数这种问题其实都是详细设计时出现的,代码评审阶段比较少见。

    • 是否有异常处理机制,一个好的代码设计应该考虑各种异常并对相应的异常做出合理的处理,比如接口的可重入,当代码检测到有重入的这种情况,怎样去做这种异常处理使得调用方能捕捉的这些异常而进行后面的处理。

  • 关注业务可拓展性

    • 我们的业务在不断的发展,每一个项目设计都会影响后续业务的拓展,一个好的设计应该考虑到后续业务的发展,而尽量避免定制化的设计。

  • 关注使用到的数据结构、设计模式和代码性能

    • 一个好的数据结构和设计模式可以增加代码的可维护性安全性和效率等,比如我们在设计的时候要考虑到不同的场景选择什么样的数据结构,有时候我们会纠结于用map还是用hash_map,这时候我们要根据具体的情况具体分析;

    • 当我们设计代码的时候如果能用上系统提供的函数那么最好不要自己去写,比如自己实现一个链表的时候是否可以想到用系统库提供的list_head以确保链表结构的正确性;

    • 某些设计如果能套用设计模式会让设计更加美观也让阅读者更加明了;出于对系统性能的考量,我们要关注编写代码对系统的开销,包括使用的算法是否合理,以及对某些比较耗时的操作比如数据库的操作要加以关注。

2.检查代码可读性和可维护性:

  • 如果代码的可读性强,那么维护起来也就方便很多;一个好的代码规范和编码风格会节省大家对代码的理解时间,减少维护成本;虽然我们有编程规范检查工具,但有些内容检查不出来,是需要靠大家去规范的。

  • 关注代码注释:我们在编写函数和进行逻辑判断的时候最好要标注一下这个函数或者这段判断是用来做什么的;做了这种注释的好处,一来当别人阅读这段代码的时候看到你的注释以后就会根据你的思路快速理解代码,甚至不阅读直接跳过;二来防止自己由于长时间不阅读代码而忘记这段代码的用途。

  • 关注命名规范:虽然我们有自己的编码规范,但是这种规范只是限制了使用驼峰命名法还是其他命名法;而好的命名风格应该是看到变量或者函数名字就能“望文生义”,毕竟我们不能把自己写的所有代码都做注释。

  • 关注重复代码:如果出现大量的重复性代码,要考虑将这些代码抽象出公用函数,以减少代码量并增强代码可读性。

  • 关注繁琐的逻辑:如果一个简单的功能却对应大篇幅的代码,要考虑一下是不是有比较简单的实现方式,因为过于复杂的代码会给后来者的维护带来麻烦;如果没有简略的办法,一定要把注释写好。

3.分享设计、技术、知识和经验

  • 在代码审查的过程中,大家往往把关注点放在发现代码的不足上,忽略了代码评审过程中的设计思想、技术方法、业务知识的传播,我觉得这些内容也是非常重要的,也需要同时关注。

  • 评审者在自己的代码时会深入业务流程,参与这可以看到评审代码的一些算法、数据结构、设计模式甚至是系统架构等知识以及评审者在编码过程中踩过的坑;通过这些信息参与者可以提升自己的业务水平和技术能力使得整个团队的水平得到提高。

  • 参与者除了要有这种学习意识外,评审者也要想办法让参与者更加快速高效的去理解代码中传播的知识,这样能帮助提升Review速度,所以建议评审者能简单介绍一下项目的背景以及详细设计,这些信息的介绍有以下好处:

    • 首先,代码的设计是按照详细设计来执行的,但是设计者在真正code的时候会出现一些变动,这些变动要给大家一个同步;

    • 其次,参与过详细设计的人可能由于没有直接参与的code,时间长会忘记之前详细设计的流程,简单介绍之后就会让参与者想起,方便参与者的理解;

    • 第三,对于没参与详细设计的同学,在简单介绍过这些信息后,可以有个大致了解,不然整个评审过程会很煎熬;

    • 所以,如果参与者对代码的信息不理解,会造成参与者理解代码的难度,也就不能提出有建设性的意见,同时也难以学到评审中传播的知识;这一点在之前的评审中是比较容易被大家忽略的,尤其是在跨团队代码评审时,准备不足和经验不足的同学是很难理解对方在讲什么的。

  • 讲解code的时候最好是以接口功能为单位去讲解

    • 如果评审者一下子把所有的详细设计都讲解完,可能会因为信息量比较大,或者设计到一些细节问题,参与者不能有效的记住或理解也会影响评审的速度和效率;

    • 评审者可以在讲解的过程中分享一下自己踩过的坑,参与者可以随时根据自己发现的问题进行讨论。

 

如何迅速完成CodeReview?

所谓的迅速就是节省时间,只要我们尽量避免一些意义不大的事情就能节省时间,加快评审速度,要做到这点建议大家尽量不要做以下这些事情:

1.不要刻意地去寻找代码bug

  • 有些代码的逻辑是比较复杂的,如果是很容易就发现的缺陷,大多数情况下评审者自己在编码过程就会发现,那么剩下不容易发现的缺陷要发现也会花费较多的时间,这些问题可以交给测试人员去发现;

  • 如果参与者刻意去找bug会造成顾此失彼,忽略更重要的东西;当然,有些bug你可能一眼就看出来了,那提出来就再好不过了。

2.不要按照自己的编程风格去评论别人的代码

  • 有些人参与者比较自信,对自己写得代码感觉很满意,所以有时候就会根据自己熟悉的编码语言或者编码风格去评论别人的代码;

  • 作为参与者,只要觉得评审者的代码符合命名要求和设计要求就可以了,但假如评审者的代码缺陷很明显,可以提出带大家进行讨论。

3.不要带着抨击和质疑别人能力的心态去进行代码评审

  • 有时候参与者可能心情不好,或者感觉对方是新人就忍不住会抨击对方的代码,这样会比较容易在模棱两可的问题上浪费时间;

  • 参与者可能认为A方法好,评审者可能认为B方法也不坏,这样就会造成没有必要的争论而浪费时间。

4.不要在不确定的问题上争来争去

  • 大家在讨论的时候如果某些问题讨论一段时间以后仍然没有结论,或者需要第三方确认或者评审者不能马上理解参与者提出的意见时,不要花太多时间讨论这些问题;

  • 把这些问题先记录下来,等会议结束后评审者可以与参与者进行线下讨论,同时将这些问题根据自己的理解进行解决,之后给大家一个反馈即可,这样可以节省很多时间。

5.不要听不进别人的意见

  • 有些评审者比较固执,不愿意接受大家的意见,会造成一些不必要的争端和讨论,浪费时间;

  • 当然,有时候参与者的意见不见得是最好的,作为评审者将其作为一个参照的方向和视角,如果存在争论,这些建议也可以做成会议记录,评审者私下和建议提出者讨论以后给大家一个结论。

6.参与者最好不要自己都没想明白就提意见

  • 如果参与者自己没有想明白的事情就去提意见,那么评审者反问的时候会浪费大家的时间;

  • 参与者可以先将自己的想法大致记下来,自己想清楚了之后再提给评审者也是节省时间的办法。

7.评审前最好先通过代码静态检查工具检测

  • 一般规范性的问题都可以通过静态检测工具发现,借助工具是最省事,也是效率最高的,还可以避免大家都评审时提出很多规范性问题,而遗漏了业务逻辑、设计合理性等问题。

     

写在最后

希望我们都能够有效而迅速进行CoderReview,一方面提升代码质量本身,另一方面也可以创造一个良好的学习氛围互相支持提升团队的整体代码水平.

 

分享到:
评论

相关推荐

    极狐:2023中国企业研发高效能白皮书-Code Review篇.pdf

    为了解决这些问题,企业需要引入更高效的Code Review实践。这包括使用自动化工具来辅助Code Review,确保所有代码提交前都经过审查;建立强制性的Code Review流程,防止代码未经充分审查就被合并;以及利用数据支撑...

    OWASP Code Review Guide

    - **安全代码审查准备**:介绍进行安全代码审查前需要做的准备工作,包括对开发环境的理解、熟悉应用架构等。 - **SDLC中的安全代码审查**:解释如何将安全代码审查融入到软件开发生命周期(SDLC)的不同阶段。 - **...

    Code Review 使用说明1

    1. **CodeReview工具的作用**: - 代码审查工具的主要目标是帮助减少缺陷记录和汇总的时间,让责任人能快速定位问题。 - 工具可生成类似于PC-LINT检查的报告,便于点击直接定位错误位置。 - 支持任务责任人修改...

    基于Gitlab的代码审查流程(Code-Review)方案

    Git是一种先进的分布式版本控制系统,由林纳斯·托瓦兹开发,旨在取代较为传统的版本控制系统,如SVN和Mercurial...同时,利用GitLab-CI进行持续集成,可以确保每一次代码变更后快速得到反馈,以保持代码库的健康状态。

    Best Practise for Peer Code Review

    ### 同行代码审查最佳实践 #### 概述 代码审查是软件开发过程中不可或缺的一环,它能够帮助团队发现潜在的缺陷、提高代码质量...在未来,随着软件开发领域的发展和技术的进步,同行代码审查将会变得更加高效和普及。

    CodeReview:CodeReview是一个Git GUI工具,用于执行以Python3和Qt5编写的代码审查(Diff Viewer)。

    **使用CodeReview进行代码审查** 1. **安装与配置**:首先,用户需要安装Python3和Qt5环境,然后下载并安装CodeReview。根据项目需求,可能还需要配置Git环境。 2. **连接Git仓库**:通过CodeReview,用户可以连接...

    Source Insight—宏.zip

    "Source Insight—宏.zip" 文件包含了多种宏,如 Codereview 相关的宏,帮助开发者实现更高效的代码审查。 ** Codereview 宏** 代码审查是软件开发过程中的关键环节,用于检查代码质量、发现潜在问题和提升团队...

    VSCode代码查看工具

    同时,"Peek Definition" 和 "Go to Definition" 功能能快速定位到函数或变量的定义位置,"Find and Replace" 功能则帮助用户高效地搜索和替换代码。 SourceInsight是一款专业的源代码查看和分析工具,以其强大的...

    完整的华为sourceInsight 宏

    4. **CodeReview.em**:这可能是用于代码审查的宏,可能包含批注、注释、代码对比等工具,帮助团队成员进行协作和代码质量控制。附带的使用文档将指导用户如何有效地利用这个宏进行代码审查流程。 【标签】中的"SI...

    secr_indent:堆栈交换代码检查自动将您的文件缩进四个空格,因此您可以轻松地将它们发布到http:codereview.stackexchange.com

    `CodeReview` 要求提交的代码具有清晰的格式,通常使用四个空格进行缩进,以便于阅读和理解。 `secr_indent` 工具的主要功能是自动将代码文件的缩进调整为四个空格。这样,用户无需手动编辑每个文件,就可以快速地...

    最全的Source Insight宏文件-华为-NetEyeutils

    3. **CodeReview宏**:`CodeReview.em`可能是用于代码审查的宏,它可能包含了一些特定的代码检查规则和提示,帮助团队成员遵循统一的编码规范,提高代码质量,降低维护难度。 4. **文档资源**:`...

    Source Insight - 高效脚本修改版

    2. **Code Review 使用说明.doc**:文档中可能详细介绍了如何利用Source Insight进行代码审查的过程,包括如何使用脚本来辅助审查,如何标记问题,以及如何跟踪代码修改,这对于团队协作和代码质量控制非常重要。...

    pb-code-review:Node.js REST API的代码审查

    在本文中,我们将深入探讨"pb-code-review"项目,这是一个针对使用Node.js构建的REST API进行代码审查的实践案例。REST(Representational State Transfer)是一种软件架构风格,常用于构建Web服务,而Node.js则是一...

    Gitlab 代码 review 插件

    Gitlab 代码 review 插件是开发者们在进行代码审核时的一个强大工具,它专为内网环境下的 Gitlab 平台设计。该插件旨在优化源码浏览体验,提高团队协作效率,确保代码质量。在本文中,我们将深入探讨 Gitlab 代码 ...

    Git-2.28.0-64-bit.lzh

    规范的 Code Review 流程结合内置强大的静态代码自动扫描工具,可灵活接入编译、测试结果,提供更全面的评审信息 安全、稳定、快速 稳定运行七余年、服务 500 万+用户,深厚的技术沉淀,安全性能久经考验,给你安全...

    Source Insight 3宏配置

    **Source Insight 3 宏配置详解** Source Insight 3 是一...正确理解和使用chnchar.em、quicker.em 和 CodeReview.em等宏配置文件,可以帮助开发者在华为的项目中实现更高效的工作流程,同时保证代码质量和团队协作。

    discourse-code-review:这允许将提交和拉取请求作为主题导入到Discourse中并进行审查

    Discourse是一款强大的社区平台,而"discourse-code-review"插件正是它的一个重要扩展,旨在将Git的提交和拉取请求无缝集成到Discourse论坛中,以便团队成员可以对代码进行讨论和审查。本文将深入探讨这个插件的功能...

    Source Insight辅助软件

    Source Insight作为一款高效的代码审查工具,可以帮助开发者在Code Review阶段更加深入地理解和评估代码。其特性包括: - **代码高亮显示**:Source Insight可以对不同类型的编程语句进行颜色标记,便于快速识别和...

    算法面试通关40讲完整课件 02-如何高效学习数据结构与算法

    即时反馈可以帮助你立即发现错误并改正,无论是主动寻求高人指点,如查看GitHub上的优秀代码,还是参与第一视角直播的编程活动,或是被动接受他人(如导师或同事)的code review,都能帮助你快速提升。 在面试时,...

Global site tag (gtag.js) - Google Analytics