怎样在你的团队做 Code Review ?

怎样才是满怀仁爱地工作呢?那就是满怀热情地建造;满怀温情地播种耕耘;仿佛你所爱的人要来。那就是把你心灵的气息灌输到你所制作的一切之中去。雕刻大理石,在石头里寻找自己的灵魂。(纪伯伦)

在现实中积聚新活力是一件伟大的事情。(Vincent van Gogh)

f1ec8a6b437af8a63f8b61c31821745b.png

引子


KISSkeep it simple, stupid),意思是“保持简单和笨拙”(UNIX 哲学); Do one thing and do it well.

Doug McIlroy(UNIX 管道的发明人、UNIX 传统的奠基人之一) 认为 UNIX 的哲学是这样的:

  • Write programs that do one thing and do it well.

一次只做一件事,并能把这件事做好。

  • Write programs to work together.

互相协作(调用)。

  • Write programs to handle text streams, because that is a universal interface.

写处理文件流的程序。因为这(处理文件流)是一个通用接口。

Talk is cheap,show me the code.

Code Review 是一种开发文化,而不仅仅是一种制度.

把Code Review 作为开发流程的必选项后,不代表Code Review这件事就可以执行的很好,因为Code Review 的执行,很大部分程度上依赖于审查者的认真审查,以及被审查者的积极配合,两者缺一不可!

如果仅仅只是当作一个流程制度,那么就可能会流于形式。最终结果就是看起来有Code Review,但没有人认真审查,随便看下就通过了,或者发现问题也不愿意修改。

真要把Code Review这件事做好,必须让Code Review变成团队的一种文化,开发人员从心底接受这件事,并认真执行这件事。

要形成这样的文化,不那么容易,也没有想象的那么难,比如这些方面可以参考:

  • 首先,得让开发人员认识到Code Review这件事为他人、为团队、为个人都能带来的好处

  • 然后,得要有几个人做好表率作用,榜样的力量很重要

  • 还有,对于管理者来说,你激励什么,往往就会得到什么

  • 最后,像写自动化测试一样,把Code Review要作为开发任务的一部分,给审查者和被审查者都留出专门的时间去做这件事,不能光想着马儿跑得快又舍不得给马儿吃草

如何形成这样的文化,有心的话,还有很多方法可以尝试。只有真正让大家都认同和践行,才可能去做好Code Review这件事。

知行合一

提升认知,端正态度,向内探求.

要为自己的代码而自豪,但是不要觉得自己的代码是完美的.只有不断地去完善,不断地寻找问题,发现问题,然后解决问题---臻于至善.

磨练灵魂,提升心志

磨练灵魂,提升心志,这就是我为什么要工作(Coding)。工作(Coding)是人生最珍贵最重要最有价值的行为,生命中的困难和挫折正是我人生的起点,也正是我最大的幸运。(稻盛和夫)

痛苦的根源往往在于欲望超过了能力。因而韬盛和夫认为,佛所说欲望、恼怒、愚痴这“三毒”最好的解药便是在工作中“精进”。

令稻盛和夫动容的一个回忆是听木匠讲:

“树木里宿着生命,工作时必须倾听这生命发出的呼声 ——在使用千年树龄的木料时 ,我们工作的精湛必须经得起千年日月的考验 。”

大音若此,工作之中有神明。

无论我们在做什么,手中的工作即是塑造自我的法门,无他。

参考:https://blog.csdn.net/universsky2015/article/details/83593437

Happy Coding

写代码时,要使自己专注,认真,进入心流状态,然后,做到快乐 Coding.

CR目的

  1. 发现代码缺陷,提高代码质量,

  1. 统一团队代码规范

  1. 保证设计合理性

  1. 促进工程师日常代码交流和人员的成长

CR时机: 提测之前

开发并自测结束之后,提测之前,可与联调并行

Bad Code ?

在 Code Review 时, 需要有对 bad code 进行简单判断的能力

除了要了解一流代码的特性之外,在 Code Review 时,需要有对 bad code 进行简单判断的能力。通常 bad code 有以下特点:

①5 分钟内不能看懂的代码。

不能快速看懂的代码,一定是有问题的代码,可以先抛回给编写代码人员进行修正。一般一个函数的操作不能超过 6 个 step,如果超过这个数量,则需要重新调整编码逻辑。

②需要思考才能看懂的代码。

好的代码阅读时基本不用动脑子,甚至看注释就能看懂。

③需要来回翻屏才能看懂的代码。

好的代码,经常在一屏内就是一个完整的逻辑。

④没有空行或注释的代码。

Good Code? 一流代码

一流代码有以下特性:

①高效性;

鲁棒性

③简洁;

④简短;

⑤可共享;

⑥可测试;

⑦可移植;

⑧可监控;

⑨可运维;

⑩可扩展。

将以上十条标准进行总结精简,可归纳为:

①代码的正确和性能;

②代码的可读和可维护性;

③代码的可运维和可运行;

④代码的可共享和可重用;

在 Code Review 时,综合考虑以上一流代码的特性,可以快速提升代码质量、提升编写代码的能力等。

为什要CodeReview?

提高代码质量

①提高代码质量可以提高代码的可读性。

②提高代码质量可以提高代码的复用性和参考性。

③提高代码质量可以减少 bug 出现的风险。

④提高代码质量可以减少后期补丁的风险。

⑤提高代码质量可以降低代码失控的风险。

⑥提高代码质量可以降低项目重构和升级的麻烦。

提高写代码的能力

①代码能力如果停滞不前,对于个人而言,将导致职业危机。

②代码能力如果停滞不前,对于团队而言,将意味着团队没有成长。

Code Review 是一个非常重要的提升代码质量和代码能力的手段。无论是从个人发展角度,还是团队发展角度,我们都需要重视 Code Review。

Code Review 是提升代码质量的最好方法

强化 Code Review 是提升代码质量的第一选择。

在代码开发过程中,我们越早发现问题、定位问题,在修复问题时付出的成本越小。

大约有 50%以上的 bug,都是在做 Code Review 时发现的。前期做好 Code Review,后期将会减少反复修改等不必要的复工。

Code Review 能够在团队内传递知识

从知识传递的角度看,Code Review 是极为重要的。

做好 Code Review,能够帮助团队传递知识、沟通交流、互相学习,能够提升学习能力、提升编写代码能力、提升代码质量、提升工作效率、降低项目风险。

另外,基于 codebase 可以使我们了解项目全局,培养系统的思考方式。

Code Review 是辅导怎么写代码的最好方法

我们要意识到,做 Code Review 可以学习到别人的经验,同时也可以向别人传递我们的经验。

如果我们想辅导别人,最好的办法就是让对方先写一段代码,我们对他的代码进行 Code Review。在辅导他人的过程中,我们可以快速地发现问题,从而帮助改进。

做好 Code Review可以增加公司对最顶级开发者的吸引力

工作中是否有 Code Review 对于公司或团队来说非常重要。不但对于公司或团队内的人员有所提升,而且能够吸引出色的开发者加入开发团队。

Code Review是摒弃个人英雄主义的作坊式开发模式的有效手段

在一个成熟的公司里,所有的架构设计、实现,都应该是一个团队的产出。尽管这个过程可能会有某个人来主导,但应该是经过整个团队共同智慧的结晶。

如果一个人默默的写代码提交,不经过团队的Review,这样的代码蕴含的是一个人的智慧。代码的质量完全依赖于这个人的技术水平。这就会导致代码质量层次不齐。如果经过团队多人Review,打磨,则代码蕴含的是整个团队的智慧,可以保证代码按照团队中的最高水准输出。

如何做好 Code Review?

在 Code Review 中要有一个好的态度

要做到以下几点

(1)对所有检查的代码逻辑要做到“完全看懂”,对于审核的代码,熟悉程度要做到“如数家珍”。如果在审核代码后,对代码的逻辑和背后的原因仍然很模糊,则是一个失败的 Code Review。

(2)好代码的标准,不仅仅是“可以运行通过”,在正确性、可读性、可重用性、可运维性等方面上,都需要综合考虑。

(3)建立 Code Review 和写代码一样重要的意识。即: ①Code Review 和写代码一样,也有产出,即产出更高质量的代码。② 审核代码在很多情况下比写代码还要辛苦,需要理解和找出问题等。

(4)以提升代码质量为最终目标。

(5)要投入足够的时间和精力。

①审核代码花费的时间经常和写代码一样多,有时甚至比写代码的时间更多,要有时间意识。

②要有责任意识。如果出现 bug,不仅仅是写代码人员的职责,也不仅仅是 QA 的职责,代码审核者也需要承担相当大的责任。

在做Code Review时,你需要注意以下:

  • 代码设计良好。

  • 代码功能对用户有用。

  • 任何UI改动应当是深思熟虑过而且看起来不错的。

  • 保证线程安全。

  • 代码没有增加不必要的复杂性。

  • 开发者没有写有些将来需要但现在不知道是否需要的东西。

  • 代码有适当的单元测试。

  • 测试逻辑设计良好。

  • 开发者使用了清晰明了的命名。

  • 注释清晰明了实用,通常解释清楚了为什么这么做,而不是做了啥。

  • 代码有相应完善的文档。

  • 代码风格符合规范。

确保你review了要求你看的每一行代码,确保你正在提升代码质量,并且为开发者做的提升点赞。

在 Code Review 时,发现不会用段落、不会写注释的代码,肯定不是好的程序员写的代码,可以直接打回给编写代码人员进行修正。

在 Code Review 中可能发现的问题?

→ 代码 bug;

→ 业务逻辑实现错误;

→ 拼写错误;

→ 未优化的代码;

→ 不必要的复杂代码;

→ 已经实现过的代码,又重复实现;

→ 注释不全;

→ case 没有覆盖全等等问题。

→ ...

Code Review 的注意事项

①在必要时,review 的双方做面对面的沟通。

面对面沟通并不是单指当面沟通,还包括云共享、电话、视频沟通等。在沟通时,对于背景、关键点等应进行说明,便于 reviewer 的理解。在必要时,应提供设计文档。

②对于关键模块,应该建立 owner 制度。

所有提交的代码,必须由 owner 做最终确认。由 owner 掌握全局,并建立明确的责任关系。

③检查中发现的问题,要一追到底。

④要注意细节。对每一行提交的代码,都要进行检查。

⑤Code Review 的方式,要小步快跑。每次提交 review 的代码量不要太多,降低复杂度。在特殊情况时,比如一个新模块的构建,最好逐步完成,通过多次进行提交。

⑥要为 Code Review 预留出足够的时间。Code Review VS Coding 的时间,有时可能达到 1:1。在这里需要考虑到有时会做大的修改,科学地规划工作量,尽量避免出现时间倒排。

⑦注意每天 review 代码的数量不宜过多。

Code Review 的步骤

0a9be47abca66bd99d41df8f5fbe2d25.png

Code Review 的步骤为以下几点:

Step1:先看系统全貌

不深究细节,浏览系统全貌,理清模块划分的逻辑、模块间的关系、如何构成的整个系统等。

Step2:进入模块级别

同样不深究细节,浏览模块内的全貌,判断模块切分是否合理,理清模块内的逻辑,明确关键数据、关键的类和函数等。

Step3:理清类、函数内部的逻辑。

Step4:进入细节。

比如 Layout、命名等。

What Do Code Reviewers Look For?

https://github.com/google/eng-practices/blob/master/review/index.md

Code reviews should look at:

  • Design: Is the code well-designed and appropriate for your system?

  • Functionality: Does the code behave as the author likely intended? Is the way the code behaves good for its users?

  • Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?

  • Tests: Does the code have correct and well-designed automated tests?

  • Naming: Did the developer choose clear names for variables, classes, methods, etc.?

  • Comments: Are the comments clear and useful?

  • Style: Does the code follow our style guides?

  • Documentation: Did the developer also update relevant documentation?

人为因素

除了代码上的问题,在 Code Review 过程中还会有一些人为因素,例如:

QA 人员

好的 QA 人员不仅仅会发现系统中的 bug,还会质疑或提出产品需求,挑战或优化系统架构和实现方式。

②Code Reviewer

好的代码审核人员不仅仅指出代码表面的问题,还会检查系统需求分析的质量、接口或函数定义的合理性、模块划分的合理性、系统关键机制的合理性等。

如何成为一个好的 Reviewer

在做Code Review时,你需要注意:

  • 代码设计良好。

  • 代码功能对用户有用。

  • 任何UI改动应当是深思熟虑过而且看起来不错的。

  • 保证线程安全。

  • 代码没有增加不必要的复杂性。

  • 开发者没有写有些将来需要但现在不知道是否需要的东西。

  • 代码有适当的单元测试。

  • 测试逻辑设计良好。

  • 开发者使用了清晰明了的命名。

  • 注释清晰明了实用,通常解释清楚了为什么这么做,而不是做了啥。

  • 代码有相应完善的文档。

  • 代码风格符合规范。

确保你review了要求你看的每一行代码,确保你正在提升代码质量,并且为开发者做的提升点赞。

代码审核的质量,和审核者的代码能力直接相关。代码审核的质量差,反映的是审核者的代码水平。如果作为一个代码审核员不会写代码,就要承认真相,并且要不断提高自己的代码能力。


学习资料推荐

在这里推荐一些学习资料帮助大家进行学习。

《代码整洁之道》, 细节之处的效率,完美和简单。

《重构》,代码坏味道和相应代码的最佳实践。

计算机程序的构造和解释,这本书也很经典,是 MIT 的计算机科学系的教材。这本书中主要证实了很多程序是怎么构造出来的,以及程序的本质是什么。整本书主要是使用 Scheme/Lisp 语言,从数据抽象、过程抽象、迭代、高阶函数等编程和控制系统复杂性的思想,到数据结构和算法,到编译器 / 解释器、编程语言设计。

深入理解计算机系统,原书名为《Computer Systems A Programmer’s Perspective》。不过,这本书叫做《程序员所需要了解的计算机知识》更为合适。本书的最大优点是为程序员描述计算机系统的实现细节,帮助其在大脑中构造一个层次型的计算机系统。从最底层的数据在内存中的表示到流水线指令的构成,到虚拟存储器,到编译系统,到动态加载库,到最后的用户态应用。通过掌握程序是如何映射到系统上,以及程序是如何执行的,你能够更好地理解程序的行为为什么是这样的,以及效率低下是如何造成的。

《Effective Go》:  https://github.com/gqcn/effective-go-zh-en

Google Engineering Practices Documentation: https://github.com/google/eng-practices

参考资料

https://github.com/google/eng-practices

评论 12 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

禅与计算机程序设计艺术

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值