精华内容
下载资源
问答
  • 代码review

    2015-07-08 10:37:24
    对于代码review个人也有些小小的看法:  1.首先我觉得我们所有开发人员要弄明白 现在Code Review 的目的 ,凡事不弄明白目的,无法做好完成一件事情,个人觉得有以下一些目的:  a)可以在项目早期就能够发现...

    对于代码review个人也有些小小的看法: 
    1.首先我觉得我们所有开发人员要弄明白 现在Code Review 的目的 ,凡事不弄明白目的,无法做好完成一件事情,个人觉得有以下一些目的: 
    a)可以在项目早期就能够发现代码中的BUG ,提测后可以尽快的释放开发资源;
    b)同时可以达到知识共享 ,避免我们所有开发人员犯一些很常见,很普通低级的错误 ;
    c)保证项目组人员的良好沟通 ,项目的代码更容易维护 
    大家还有希望补充上

    2.Code Review 很容易变得没有意义或是流于形式,进入 Code Review 个人觉得以下几点肯定得弄明确: 
    a) 我们是否理解了 Code Review 的概念和 Code Review 将做什么,这点都不明白,做法可能就会是应付了事。 
    b) 我们的代码是否已经正确的 build , build 的目的使得代码已经不存在基本语法错误 ,我们总不希望review人员浪费在检查连编译都通不过的代码上吧。 
    c) 我们 Review 人员是否理解了代码 ,做复查的人员需要对该代码有一个基本的了解,其本功能是什么,具体的业务是怎样的,这样才能采取针对性的检查

    3 .具体检查点 
    1 完整性检查 
    代码是否完全实现了设计文档中提出的功能需求 
    代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型

    2一致性检查 
    代码的逻辑是否符合设计文档 
    代码中使用的格式、符号、结构等风格是否保持一致 
    3正确性检查
    代码是否符合制定的标准 
    所有的变量都被正确定义和使用 
    所有的注释都是准确的 
    4 可修改性检查
           代码涉及到的常量是否易于修改 ( 如使用配置、定义为类常量、使用专门的常量类等 )

    5可预测性检查
           代码是否具有定义良好的语法和语义 
           代码是否无意中陷入了死循环 
           代码是否是否避免了无穷递归

    6健壮性检查 
           代码是否采取措施避免运行时错误(什么空指针异常等,有很多是程序里面处理了,但打印日志时没有判断,不知道大家有没有犯过这样的错误哟)

    7可理解性检查
           注释是否足够清晰的描述每个子程序 ,对于没用的代码注释是否删除
           是否使用到不明确或不必要的复杂代码,它们是否被清楚的注释 
           使用一些统一的格式化技巧(如缩进、空白等)用来增强代码的清晰度 
           是否在定义命名规则时采用了便于记忆,反映类型等方法 
          循环嵌套是否太长太深?
    8可验证性检查 
           代码中的实现技术是否便于测试 
    具体的杨帅同学也整理的很多很多,希望我们讨论会上所有人员能达成一个共识,慢慢去完善!

    最后抛出一个问题,希望大家抛砖
    Review中,我们发现开发人员代码的一些非逻辑问题(辟如:不符合面象接口编程的思想等,只是个举例,嘿嘿),不修改也行,因为逻辑是OK的,如果修改的话可能又要花上一些时间,此时项目的进度方面将无法保证,该如何去做?

    展开全文
  • 代码Review

    千次阅读 2012-12-03 11:23:19
    1.首先我觉得我们所有开发人员要弄明白 现在Code Review 的目的 ,凡事不弄明白目的,无法做好完成一件事情,个人觉得有以下一些目的: a)可以在项目早期就能够发现代码中的BUG ,提测后可以尽快的释放开发资源...
    1.首先我觉得我们所有开发人员要弄明白 现在Code Review 的目的 ,凡事不弄明白目的,无法做好完成一件事情,个人觉得有以下一些目的:
    
    a)可以在项目早期就能够发现代码中的BUG ,提测后可以尽快的释放开发资源;
    b)同时可以达到知识共享 ,避免我们所有开发人员犯一些很常见,很普通低级的错误 ;
    c)保证项目组人员的良好沟通 ,项目的代码更容易维护
    大家还有希望补充上

    2.Code Review 很容易变得没有意义或是流于形式,进入 Code Review 个人觉得以下几点肯定得弄明确:
    a) 我们是否理解了 Code Review 的概念和 Code Review 将做什么,这点都不明白,做法可能就会是应付了事。
    b) 我们的代码是否已经正确的 build , build 的目的使得代码已经不存在基本语法错误 ,我们总不希望review人员浪费在检查连编译都通不过的代码上吧。
    c) 我们 Review 人员是否理解了代码 ,做复查的人员需要对该代码有一个基本的了解,其本功能是什么,具体的业务是怎样的,这样才能采取针对性的检查

    3 .具体检查点
    1 完整性检查
    代码是否完全实现了设计文档中提出的功能需求
    代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型

    2一致性检查
    代码的逻辑是否符合设计文档
    代码中使用的格式、符号、结构等风格是否保持一致
    3正确性检查
    代码是否符合制定的标准
    所有的变量都被正确定义和使用
    所有的注释都是准确的
    4 可修改性检查
           代码涉及到的常量是否易于修改 ( 如使用配置、定义为类常量、使用专门的常量类等 )

    5可预测性检查
           代码是否具有定义良好的语法和语义
           代码是否无意中陷入了死循环
           代码是否是否避免了无穷递归

    6健壮性检查
           代码是否采取措施避免运行时错误(什么空指针异常等,有很多是程序里面处理了,但打印日志时没有判断,不知道大家有没有犯过这样的错误哟)

    7可理解性检查
           注释是否足够清晰的描述每个子程序 ,对于没用的代码注释是否删除
           是否使用到不明确或不必要的复杂代码,它们是否被清楚的注释
           使用一些统一的格式化技巧(如缩进、空白等)用来增强代码的清晰度
           是否在定义命名规则时采用了便于记忆,反映类型等方法
          循环嵌套是否太长太深?
    8可验证性检查
           代码中的实现技术是否便于测试
    具体的杨帅同学也整理的很多很多,希望我们讨论会上所有人员能达成一个共识,慢慢去完善!

    展开全文
  • jupiter代码review工具

    2017-07-31 18:24:57
    jupiter代码review工具
  • Gitlab 代码 review 插件

    2019-04-01 23:43:26
    Gitlab 代码 review 插件,用于浏览内网 Gitlab 源码,通过 chrome 加载即可使用
  • 代码review指南

    2013-05-20 16:06:53
    代码review的好处很多人都知道,但是如何有效的进行代码review呢?看了这个教程,希望对你有所启发。
  • 代码Review 文档

    2015-04-17 10:14:02
    代码Review 文档,从网上摘抄下来的,个人感觉很有用,在开发中应该值得提倡
  • JAVA代码Review

    千次阅读 2018-03-28 11:08:45
    什么是代码Review? 代码review是指在软件开发过程中,通过对源代码进行系统性检查来确认代码实现的质量保证机制 为什么不做代码Review? ​业务需求大,工作时间紧张 项目小,协作的人少,没必要 为什么要做...

     

     

    什么是代码Review?

    代码review是指在软件开发过程中,通过对源代码进行系统性检查来确认代码实现的质量保证机制

    为什么不做代码Review?

    • ​业务需求大,工作时间紧张
    • 项目小,协作的人少,没必要

    为什么要做代码Review?

    • 提高代码质量,提升自身水平
    • 及早发现潜在缺陷与BUG,降低事故成本
    • 促进团队内部知识共享,提高团队整体水平
    • 保证项目组人员的良好沟通
    • 避免开发人员犯一些很常见,很普通的错误

    总而言之目的是查找系统缺陷,保证软件总体质量和提高开发者自身水平,使项目代码更加容易维护。

    代码Review的好处

    1. 在代码提交之前如果有很多双眼睛盯着看可以发现bug,这是代码审查最广为人知的好处。(人们的确可以在代码审查中发现bug,但是这些bug大部分都是显而易见的小bug,开发者分分钟可以发现,而那些真正需要花时间发现的bug通常是在代码审查中发现的)

    2. 代码审查最大的好处是纯社会性的。(如果你编程的时候知道你的同事将要看你的代码,你的编程方式会不一样,你的代码会写的更整洁,注释更加清楚,组织得更好。因为你知道其他人会看你的代码,他们的意见是你需要关注的。如果没有审查,你虽然知道人们最后会去看你的代码,但是那样不会给你一种紧迫感,也不会给你同样的个人评判的感觉。)

    3. 还有一个更大的好处就是代码审查可以传播知识。(在很多开发小组里,每个人都负责某一个核心组件,专注于自己的这一块,只要其他同事的模块不会破坏自己的代码就不会去关注,这种模式导致一个模块只有一个人熟悉对应的代码,如果一个人请教或者离职,其他人对他负责的模块将一无所知。如果采用代码审查,那么至少有两个人熟悉代码-作者和审查者。审查者知道的代码不如作者多,但是他们都熟悉代码的设计和结构,这意义重大)

    Code Review的前提

    1. 重视代码review 
      (Code Review人员是否理解了Code Review的概念和Code Review将做什么如果做Code Review的人员不能理解Code Review对项目成败和代码质量的重要程度,他们的做法可能就会是应付了事。)

    2. 代码是否已经正确的build,build的目的使得代码已 经不存在基本语法错误 
      (我们总不希望高级开发人员或是主管将时间浪费在检查连编译都通不过的代码上吧。 )

    3. 代码执行时功能是否正确 
      (Code Review人员也不负责检查代码的功能是否正确,也就是说,需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。 )

    4. 开发人员是否对代码做了单元测试 
      (这一点也是为了保证Code Review前一些语法和功能问题已经得到解决,Code Review人员可以将精力集中在代码的质量上。 )

    Code Review需要注意什么?

    1. 完整性检查(Completeness)

      • 代码是否完全实现了设计文档中提出的功能需求
      • 代码是否已按照设计文档进行了集成和Debug
      • 代码是否已创建了需要的数据库,包括正确的初始化数据
      • 代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
    2. 一致性检查(Consistency)

      • 代码的逻辑是否符合设计文档
      • 代码中使用的格式、符号、结构等风格是否保持一致
    3. 正确性检查(Correctness)

      • 所有的变量都被正确定义和使用
      • 所有的注释都是准确的
      • 所有的程序调用都使用了正确的参数个数
    4. 可修改性检查(Modifiability)

      • 代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
      • 代码是否只有一个出口和一个入口(严重的异常处理除外)
    5. 健壮性检查(Robustness)

    6. 可理解性检查(Understandability)

      • 注释是否足够清晰的描述每个子程序
      • 是否使用到不明确或不必要的复杂代码,它们是否被清楚的注释
      • 使用一些统一的格式化技巧(如缩进、空白等)用来增强代码的清晰度
      • 是否在定义命名规则时采用了便于记忆,反映类型等方法
      • 每个变量都定义了合法的取值范围
      • 代码中的算法是否符合开发文档中描述的数学模型
    7. 可验证性检查(Verifiability)

      • 代码中的实现技术是否便于测试

    Code Review经验检查项

    1、 编码规范方面检查项 
    2、面向对象设计方面检查项 
    - 类设计和抽象是否合适 
    - 是否符合面向接口编程的思想 
    - 是否采用合适的设计模式

    3、性能方面检查项 
    - 对hashtable,vector等集合类数据结构的选择和设置是否合适 
    - 有无滥用String对象的现象 
    - 是否采用通用的线程池、对象池模块等cache技术以提高性能 
    - I/O方面是否使用了合适的类或采用良好的方法以提高性能(如减少序列化,使用buffer类封装流等) 
    - 同步方法的使用是否得当,是否过度使用

    4、数据库处理方面 
    - 数据库资源是否正常关闭和释放 
    - 数据库访问模块是否正确封装,便于管理和提高性能 
    - 是否采用合适的事务隔离级别 
    - 资源泄漏处理方面检查项 cursor

    5、通讯方面检查项 
    - socket通讯是否存在长期阻塞问题

    6、重复代码 
    7、其他 
    - 日志是否正常输出和控制 
    - 配置信息如何获得,是否有硬编码

    怎么更有效的做Code Review

    1. 一次评审量要低于 200–400 行代码缺陷密度 就是每 1000 行代码之中所发现的错误(bug)数 
      这里写图片描述

    2. 每小时低于 300–500 LOC 检查率的目标 
      这里写图片描述

    3. 花足够的时间进行适当缓慢的评审,但是不要超过 60-90 分钟 
      但反过来说,评审代码所花的时间不得低于五分钟,就算代码只有一行也是如此。通常来说,单行的代码也会影响到整个的系统,所以花上五分钟时间去检查更改可能造成的结果是值得的

    4. 确定在评审开始之前代码开发者已经注释源代码了 
      这里写图片描述

    5. 使用检查表,因为它能极大地影响代码开发者和评审者的结果 
      另外一个有用的概念就是 个人检查表 。每个人一般都会犯 15-20 个错误(bug)。如果您注意到了一些典型的错误(bug),那么您就可以开发自己的个人检查表

    6. 确认缺陷得到了修复

    展开全文
  • 如何有效地进行代码 Review

    万次阅读 2020-10-26 18:37:42
    为什么要做代码 Review 为什么要代码 Review,相信每个人心中都有比较一致的答案,Google 搜索一下也能找到一大堆的文章。这里简单总结几点: 1)提高代码质量 这是代码 Review 的初衷,也是代码 Review 最直接的...

    为什么要做代码 Review

    为什么要代码 Review,相信每个人心中都有比较一致的答案,Google 搜索一下也能找到一大堆的文章。这里简单总结几点:

    1)提高代码质量

    这是代码 Review 的初衷,也是代码 Review 最直接的价值。Reviewers 根据各自的经验,思考方式,看问题的角度给代码提出各种可能的改进意见,从而形成更好的代码以及产品质量。

    我们知道产品问题越晚提出解决它的代价就越大,参与进去的人、要走的流程都会越来越多。代码 Review 可以说是早期解决问题最有效的途径之一了,在代码 Review 中解决掉哪怕一个小问题都能避免后续一堆的麻烦事。

    2)形成团队统一的高质量标准

    有效的代码 Review 最终会在团队范围内建立起统一的质量标准,并且会随着团队成员的互相学习和促进形成更高的标准。参与者会在代码 Review 的过程中基于具体问题从不同角度提出改进意见,并最终做出当前最佳的选择并形成共识。随着代码 Review 的有效进行,团队成员会有意识地关注代码质量,从而形成越来越高的事实上的质量标准。

    3)个人快速成长

    通过有效的代码 Review,Author 和 Reviewer 都将获得成长,在 Review 过程中参与人就具体的问题展开深入的讨论,无论是怎么写出整洁的代码、怎么更好地更全面地思考问题、怎么最佳地解决问题,参与人都可以互相取长补短,互相提高。通过具体代码实现进行的讨论往往是最深入和有效的,代码 Review 是开发者提高代码能力最重要的途径之一。

    有的人认为代码 Review 就是 Reviewer 帮助查找代码中的 Bug,其实代码 Review 不应该是一个单向的过程,而应该是个双向交流的过程,Reviewer 帮助 Author 提出代码改进意见的同时,也是向优秀的 Author 学习的过程。我们都知道提高代码能力一个有效的途径是阅读优秀的项目代码,但是阅读项目代码有着不小的难度,这也是大部分人没有去执行的原因,而 Review 资深同事的代码,我们在阅读代码的同时能够直接进行有效的沟通,这是一个快速有效的学习途径,尤其对开发经验还不算丰富的开发者而言。

    如何做好代码 Review

    2.1. 什么时候发起 Review

    在代码 Review 上,Author 需要意识到:Reviewer 的时间是昂贵的。因此在正式邀请 Reviewer 发起代码 Review 前,Author 有几项需要注意的点,这些都能提高代码 Review 的效率,节省 Reviewer 的时间。

    2.1.1. MR (Merge Request)

    也称为 PR(Pull Request), MR 是我们进行代码 Review 的地方,它记录着代码的具体改动,参与者具体的讨论过程。好的 MR 应该做到以下几点:

    • 单一:一个 MR 应该只解决一个单一的问题,无论是修复一个 bug,还是实现一个新 feature。Author 应该避免一个 MR 包含不同意图的代码改动。单一的 MR 能帮助 Reviewer 快速地了解代码改动的动机,能有针对性地进行 Review。
    • 短小:MR 应该尽量地小,比如一个 feature 引入了较多的改动,需要考虑是否可以拆成独立的几块实现,分开提 MR,比如接口定义、接口实现、逻辑对接等拆分开。
    • 详细: 这里说的详细是指 MR 应该尽可能地详细描述它的背景和动机,可以是在 MR 的描述中详细体现,也可以是连接到具体 issue 或 tapd 单中。需要达到的目的是,其他人翻开一个 MR 能知道当时做这个改动的背景以及动机。

    2.1.2. Commit Message

    之前翻看了不少现存的项目代码,看到不少的 Commit Message 写得比较简单,例如一连串的 “update”, “fix”,从这些 Commit Message 中完全看不出做了什么改动,想想如果之后想要定位之前的某个改动,该从哪里下手。

    目前 Commit Message 规范比较常见的有 Angular 团队的规范,并由此衍生出了 Conventional Commits Specification,可以参照此 Specification 约定 Commit Message 格式规范。

    <type>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>
    

    大体分三行:

    • 【标题行】 必填, 描述主要修改类型和内容。
    • 【主题内容】 描述为什么修改, 做了什么样的修改, 以及这么做的思路等等。
    • 【页脚注释】 放 Breaking Changes 或 Closed Issues

    其中 type 是 Commit 的类型,可以有以下取值:

    • feat:新特性
    • fix:修改 bug
    • refactor:代码重构
    • docs:文档更新
    • style:代码格式修改
    • test:测试用例修改
    • chore:其他修改, 比如构建流程, 依赖管理

    其中 scope 表示的是 Commit 影响的范围,比如 ui,utils,build 等,是一个可选内容。

    其中 subject 是 Commit 的概述,body 是 Commit 的具体内容。

    例如:

    fix: correct minor typos in codesee the issue for details on typos fixed.Refs #133
    

    Commit Message 可以在 git 中配置模板,这样可以在 vim 中展示出模板,另外可有工具帮助我们生成和约束 Commit Message,例如 commitizen/cz-cli,这里不再具体说明。

    2.1.3. CI 通过

    CI(Continuous Integration),持续集成可以帮助我们自动发现很多代码中的基本问题,在合适的静态代码检查(lint)配置和良好的单元测试覆盖下,CI 可以有效地提高代码的质量。很多人都低估了静态代码检查的能力,实际上现在常见语言的静态代码检查已经能帮助发现不少的 bug 和隐患。对于 Go 语言,可以配置 golangci-lint 来做代码检查,单元测试根据实际情况可以制定相应的标准,比如覆盖率 60%,其中关键的代码逻辑尽量全面覆盖。

    提交代码 Review 前需要确保 CI 执行通过,这也是为了节省 Reviewer 的时间,能够通过自动化解决的事情,尽量不要让 Reviewer 来做,而 Reviewer 发现 CI 未过的 MR 也可以要求 Author 先解决 CI 问题。

    2.1.4. Self-Review

    我们一般代码 Review 都是找他人来进行 Review,其实负责任的 Author 在邀请他人来代码 Review 前也需要自己简单 Review 一遍,即 Self-Review。

    Self-Review 的目的包括:

    • 发现那些明显的疏忽,如代码 debug 过程中留下的不必要的痕迹,比如 fmt.Println(…),不小心注释掉的代码。
    • 之前被 Reviewer 多次提出过的问题。
    • Commits 是否正常,在多人协作的情况下 MR 中否带入了不相关的 Commit。
    • Commit Message 是否合适。

    Self-Review 是一个非常快速的过程,从我个人的经验,一般 1-2 分钟即可完成,所以推荐大家养成 Self-Review 的习惯。

    2.2. 该找谁来 Review

    从目的出发,可以从以下几方面考虑 Reviewer:

    • 提高代码质量。所以首先应该找和代码改动紧密相关的研发人员参与 Review,比如一起开发某个功能,某个项目,或者一起参与了方案设计讨论并给出了有价值意见的研发。
    • 获取意见。找有相关经验的资深研发帮忙 Review,比如 Java 语言资深的研发、写过相同或类似系统/功能的研发。
    • 形成共识。如果涉及到不同团队或模块间的接口改动,或其他会影响其他人的改动,可以邀请相关团队或模块的接口人参与 Review,以对改动形成共识。
    • 质量把关。对于重要的代码库,可能会执行比较严格的质量把控,如果设置了必须的 Reviewer,这些 Reviewer 也会参与进来。
    • 变动告知。很多情况下一个代码库可能只有一个人维护,如果做了些比较特殊的变动,其他人很难发现。因此在做一些重要的但是理解起来不那么直接的地方的时候,最好告知一下相关的研发,以便他们能大概知道发生了什么。

    2.3. 都 Review 些什么

    经常会有 Reviewer 拿到 MR 不知道该 Review 些什么,其实无论你参与对应项目的深入如何,都可以对代码进行 Review,也鼓励不同人从不同的深度、角度去帮助 Review。代码 Review 没有固定的形式,它更像是一门艺术,唯一的提高办法就是实际参与进去。

    Review 的时候可以从以下几个方面入手:

    1)简单的 Review

    在 CI 通过的情况下,最简单的 Review 方式可能只需要这样:

    Reviewer:在实际环境中都验证过了吗?
    Author:当然验证过了
    Reviewer:LGTM

    这是一种提醒式的 Review。确认一句:是否在环境中验证过了,或者进一步把能想到的重要的验收点提出来确认一遍。即使是这种最简单的 Review 实际上也是有价值的,我们很难保证所有研发都会在提 MR 前实际在环境中验证自己所做的修改,也很难保证单元测试、e2e 测试能 Cover 住所有的情况,Reviewer 基本上也不可能都自己去环境上跑一遍。让 Author 去确认实际上就是提醒 Author 去确保改动至少是真实有效的,尤其是对一些已发布版本的 Bugfix,一定要提醒实际自测通过。

    类似的提醒还包括:相关的文档(外部的)是否相应更新了、这个改动是否会有兼容性的问题、性能是否有影响。他们的本质就是提醒 Author 自己去思考他们可能遗漏的问题。

    2)常规的 Review

    代码 Review 一般都会从代码风格、变量命名、语法统一处入手,当然这些应该更多的借助于 CI 等自动化手段来保证,但是在相关流程还不是很完善的前提下还是有必要进行关注。

    此外代码可读性、代码健壮性、代码可扩展性都是 Review 时关注的点。每一个关注的点都依赖于 Reviewer 的实际经验,这里只简单举几个例子:

    { 代码可读性 }

    代码是写给人看的,因为没有不需要维护的代码,无论是 Author 自己后续维护代码,还是他人接手代码,能快速地理解代码逻辑是非常必要的。

    代码 Review 的时候可以关注以下几点:

    • 变量、方法的命名是否合适,是否真实反映了他们的目的,这方面网上可以找到不少的资料说明。
    • 实现的逻辑是否已有现成的库可以替代。如果有成熟的库可以使用,尽量不要自己去实现,因为可能会引入不必要的 bug。从我个人的角度,简洁(大白话就是代码少)是可读性一个很重要的指标。
    • 关于注释。代码注释不求多,而在于有效,以前也经历过代码注释要求至少达到 30% 以上的年代,现在看来过多依赖注释其实是对代码质量的不自信,好的代码应该尽量做到自解释。在实际过程中偶尔能看到代码逻辑实际已经清晰明了,但是用语句不怎么通的英文注释了一通,最后反而是看懂了代码才能理解注释到底说了啥。因此 Review 的时候,不必要的注释可以建议去掉。
    • 不好理解的地方要有恰当的注释。代码中如果有特殊处理、特殊的常量、或者不符合一般用法的逻辑需要特别注释说明一下。
    • 代码的组织。良好的代码应该有较好的封装以及层级,使得代码看起来清晰明了,比如 DAO 层、Service 层。

    { 代码健壮性 }

    • 代码的改动是否会影响其他功能。
    • 用户参数是否做和细致的校验。
    • 有没有 Panic 的可能(针对 Go 的说法)。
    • 是否会破坏 API 的兼容性。

    { 可扩展性 }

    当前的实现方式是否能兼容以后类似的扩展需求。比如在新增接口、API 或者调整参数以解决某一问题上,可以考虑是否后续会有其他类似情况发生。举几个例子:

    • 假设我们需要定义一个 API 接口去获取一个用户的某些信息,例如联系方式等,我们定义的 API 就不能只返回这些信息,而是应该把用户相关的信息都返回。
    • 假设我要定义一个参数,虽然当前定义成单个元素即可满足,例如 string, int,但是以后是否会涉及到多个元素的场景,是否定义成 []stirng, []int 是更优的。

    这里只是举了有限的一些例子,在实际 Review 过程中,Reviewer 可以根据自身的经验从各个角度提出优化的意见。一般需要重点看看:

    • 你看不懂或疑惑的地方。
    • 打破你常规的地方。
    • 复杂的地方。

    2.4. 如何进行

    Review 过程中鼓励 Reviewer 大胆 Comment,有不理解的地方,或者觉得不合适的地方都直接表达出来,Author 对 MR 的 每个 Comment 也要做出反馈,无论是展开讨论还是简单的给个 OK 都是有效的反馈。

    Review 的过程可以是:

    • Author 在各项确认工作完成后,发起 Review,如果比较急,可以给重要的 Reviewer 发消息请求帮忙 Review。
    • Reviewer 看到 MR 后应该先确认 MR 的背景和目的,如果不清楚也无法从 MR 中获取该信息,最好直接和 Author 沟通。
    • Reviewer 直接在 MR 上提出自己的建议或者问题。
    • Author 对每个 Comment 进行反馈,并展开必要的讨论。
    • 复杂的话题可以采用线下讨论以提高沟通效率。
    • Author 处理完了所有的 Comment,也修改了代码后,需要在 MR 里 @ 一下相关 Reviewer 告知所有优化已经提交,如果时间比较急也可以直接和 Reviewer 沟通。
    • Reviewer 确认没问题,给 MR 进行 Approve,一般简单的回复是 LGTM(Lood Good To Me),也可以对 Author 的工作进行赞赏,比如 “God Job” 等。
    • Approve 后 MR 由谁来合并这个看自己选择。
    • 如果 Reviewer 提供了很多有用的建议帮助优化代码,Author 也可以礼貌性地感谢一下 Reviewer。

    2.5. 关于 Comment

    代码 Review 很大程度上就是给代码挑毛病,而且一般预期挑的越多越好,但代码是 Author 写的,很多情况下或多或少会对 Author 造成不适。所以在 Comment 的时候需要尽量注意措辞,尤其是一些主观的东西,一般以建议的方式给出。当然对于原则性的问题,是要坚守质量标准的,甚至可以直接 Deny 掉 MR。

    另外,参与者也不要吝啬你的溢美之词,无论是 Author 还是 Reviewer,在 Review 中发现了好的地方或好的建议,请给予对方以肯定和赞美,这样有助于 Review 有效的进行。

    2.6. 参与者该抱着怎样的心态

    2.6.1. Author

    首先需要明确一点,是 Author 自己对代码的质量负责,因此应当怀着感恩的心去看待坚持认真帮你 Review 代码的 Reviewer,因为并不是所有你加的 Reviewer 都有时间和精力来帮你提高代码质量。

    也正式因为 Author 是自己代码的 owner,所以不要依赖于 Reviewer 去帮你守代码质量的大门,像 “代码 Review 的时候你怎么就没看出来”,“这不是你建议我这么做的吗” 这样的话千万别说。Reviewer 只是帮你提高代码质量,因此我们该做的工作都要去做,比如细致的 Reviewer 可能某些情况下直接提出了代码优化的建议,Comment 时贴上了优化的代码片段,Author 不能直接假设它一定是能正常工作的,而应该对它进行完整的验证。

    对 Reviewer 给出的 Comment,不要有抵触的情绪,对你觉得不合理的建议,可以委婉地进行拒绝,或者详细说明自己的看法以及这么做的原因。有时候一个你觉得不合理的建议可能代表一个新的思考角度,也可能代表 Reviewer 自身代码能力上的不足,无论是哪个,无论最终是 Author 还是 Reviewer 得到了提高,都应该是好事。

    2.6.2. Reviewer

    Review 代码既是帮助提高代码质量的过程,也是 Reviewer 提高自己代码能力和沟通能力的过程。因此应该在 Review 的同时保持一个学习者的心态,既要发现对方代码中的缺陷,也要努力去发现代码中的亮点。切记单纯以挑毛病的心态去 Review 代码。

    有不少 Reviewer 在写 Comment 的时候会犹豫,担心自己提出的问题或建议比较“蠢”,因此犹犹豫豫下看完了代码抱着一堆疑虑最终啥也没留下。其实在代码 Review 的时候大可不必有什么心里负担,有什么疑惑的、不清楚的地方或者有什么自己的想法,可以直接提出来,有时候一个简单的 Comment 就可能会激起 Author 和你的 Comment 毫不相干的新思路。再者你即使没帮 Author 提高代码,让 Author 帮你提高思考不也是建不错的事情吗。

    Reviewer 也不需要去关注自己的“产出”,并不是一定要提出一堆问题才是好的代码 Review,Author 代码写得很棒也是很正常的,如果从你的角度觉得代码没问题,大胆给个 LGTM 甚至是 Approve。

    如果大家对java架构相关感兴趣,可以关注下面公众号,会持续更新java基础面试题, netty, spring boot,spring cloud等系列文章,一系列干货随时送达, 超神之路从此展开, BTAJ不再是梦想!

    架构殿堂

    展开全文
  • 代码review.ppt

    2013-03-06 10:53:36
    了解代码review做的ppt,可以帮助人理解代码review的概念
  • 代码Review那些事

    万次阅读 2016-04-27 20:18:19
    代码Review那些事
  • 如何进行代码review

    千次阅读 2019-03-25 16:36:27
    代码review是质量保证(QA)的手段之一,但不是用来替代测试的,特别是自测。 一个软件项目的质量定义并不是代码review的职责,换句话说,良好的质量定义是代码review发挥效果的必要前提。 代码review到底要review...
  • 如何进行代码REVIEW

    千次阅读 2019-01-12 11:53:17
    一、代码REVIEW的利与弊 软件工程中,最后都落实在代码的实现上,软件要运行的没有问题,除了软件架构和系统设计设计到位,代码实现也是至关重要的一部分,再好的设计如果软件代码实现有问题,软件也不能跑起来。 ...
  • 代码Review的规范

    2011-07-21 13:41:45
    详细讲述了如何进行代码Review以及代码Review中需要关注的事项
  • 提供一个很好的代码Review工具。可以设置4个级别,可以对优秀代码进行学习,还可以对有问题的代码进行复查。
  • 熟知代码review那些事

    2021-01-06 13:54:13
    什么是代码Review? 代码review是指在软件开发过程中,通过对源代码进行系统性检查来确认代码实现的质量保证机制,即是code review(CR) 为什么不做代码Review? ​业务需求大,工作时间紧张 项目小,协作的人少...
  • 代码review那些事

    2018-02-28 11:52:24
    代码review是指在软件开发过程中,通过对源代码进行系统性检查来确认代码实现的质量保证机制为什么不做代码Review?​业务需求大,工作时间紧张项目小,协作的人少,没必要为什么要做代码Review?提高代码质量,提升...
  • 代码Review工具

    2017-11-23 15:57:00
    今天发现一个非常好的代码Review工具,Rietveld。Python就用的它。是开源的。http://code.google.com/p/rietveld/ 它是用Python实现的,可以架设在Google App Engine上的应用程序。 特点: 1、它可以根据patch,...
  • Java项目开发代码Review常见问题实例
  • 代码review注意事项

    2017-03-01 11:02:15
    极限编程里提到结对编程和代码Review,凡是稍微懂编程的人看了都会赞成。这也体现了代码Review的重要性和必要性。但是,在实际的执行过程中,代码Review往往很难得到很好的执行。主要原因可能包含以下几点: (1)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,051
精华内容 2,820
关键字:

代码review