怎样在你的团队做 Code Review ?

Posted 2022-05-20 禅与计算机程序设计艺术

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

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

引子

---

KISS（keep 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 的步骤

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