编程杂谈-代码review

1. 关于智商

2. 关于能力

3. 关于changelist

3.1 关于CL内容编写

3.2 关于CL的大小

3.3 处理审稿人的意见

4. 关于代码审查

一个人的编程能力怎么去衡量？特别是在面试中，怎么避免“高分低能儿”、“专业做题家”、“面试造火箭”，我们在工作中又是需要什么样的编程技术和能力，这个问题其实很值得深思。

在很早以前的时候，面试会问你有多少代码量，就是写过多少行代码，这个标准非常的好，基本可以衡量代码水平，但是口说无凭啊，项目经验也是口说无凭，既然能力考不成，那就考智商吧。

1. 关于智商

一个智商高的人，编程的潜力非常的大，特别是大公司里面基本只在乎这个，说的很简单，但是怎么去考察智商，又是一个大难题，这就像考研，高考可能除了选拔聪明的人还需要勤奋的人，但是考研基本就是要选拔出来聪明的人，那怎么办，考数学。数学是真科学，但是对大多数工作基本没多少用处，但是就考智商来说，还是很公平的：聪明人能学好数学，学好数学的人一定聪明。

下面来看看编程界的骚操作：谷歌发现聪明的人擅长算法，那面试就考算法啊，然后全球编程公司都效仿。但是致命一点擅长算法的人不一定聪明，聪明的人不一定喜欢搞算法，反而不聪明的人通过刷题也可以蒙混过关。可能是没有更好的方法吧，大家都开始卷算法的时候，还的确是可以的。但是这种内卷丝毫不产生价值，因为算法工作的时候大概率不用，就是用也可以用ChatGPT瞬间生成啊，不需要自己写的，可谓“天下苦Leeetcode久已”。

2. 关于能力

先梳理下程序员日常的工作需要那些东西，首先就是参考各种手册，技术文档，读代码了解框架，然后制定方案，进行编码实现。这其中一方面是对于技术手册的掌握经验，另一方面就是代码的架构能力。这些东西看似跟代码可能不沾边，但是其都是来源于代码的，俗话说：“一切都在代码里”。从代码里面跳出来又跳进去，这种能力就好像你的组长在指导你的时候一样，这种能力可以说就是代码review。你的组长通过review你的代码，虽然组长第一次见，但是能够根据代码框架快速的看到你的实现逻辑，并指出技术方向和改进方面。代码review开始成为评估软件工程师的更好方法，俗话说：“行家伸伸手就知有没有”。

代码review能力日益重要的原因：

AI生成的代码越来越多，AI能力不够前，还需要人工去甄别。目前的AI更像是给专业的人提供素材，由于不保真，还需要专业的人进行甄别选用。

通常高级职务进行的代码review多，更加的强调与他人协作，进行指导和反馈。

反映受试者是否具备全面的推理、思考和沟通视角。

对代码的理解能力要求高，毕竟大多数时候我们是在读代码、抄代码、而并非原创的去写代码。

review的速度快，可以更快的融入现有项目，更好更快的创造生产力。

review相对于做题，更加的贴近于实战，直接面对团队遇到的实际挑战。

代码review的一些测试项：

阅读数据访问、异常处理、输入处理等一些典型的代码，看是否能看懂，理解用法

有bug的代码，是否能找出并解决

代码一些代码进行重构，策略和方法及效果

找一段运行缓慢的代码，对性能进行优化

给一段代码的单元测试代码，看是否涵盖所有情况，如何对单元测试做改进

3. 关于changelist

参考：https://google.github.io/eng-practices/review/developer/

我们在提交代码的时候都有commit message，这里用CL代表changelist，就是描述是关于正在进行哪些更改以及为何进行更改的公共记录。它将成为我们版本控制历史中永久的一部分，并且多年来可能会被除您的审阅者之外的数百人阅读。一个模板如下：

rpc: remove size limit on RPC server message freelist.

Servers like FizzBuzz have very large messages and would benefit from reuse. Make the freelist larger, and add a goroutine that frees the freelist entries slowly over time, so that idle servers eventually release all freelist entries.

标题行：使用祈使句总结，第一个单词首字母大写，行末不加标点
请记住标题行(title)和正文行(body)之间要有个空行
正文行：解释做了什么(what)和为什么这么做(why)，而不是详细描述如何做的

3.1 关于CL内容编写

CL 描述的第一行应该是 CL 正在执行的 具体操作的简短摘要，后跟一个空行。这是版本控制历史摘要中出现的内容，因此它应该提供足够的信息，以便将来的代码搜索者不必阅读您的 CL 或其整个描述来了解您的 CL 实际做了什么或它与其他 CL 有何不同。也就是说，第一行应该是独立的，以便读者可以更快地浏览代码历史记录。

尽量保持你的第一句话简短、重点突出、切中要点。对读者来说，清晰度和实用性应该是最重要的。

按照传统，CL 描述的第一行是一个完整的句子，写起来就好像它是一个命令（祈使句）。例如，说“删除FizzBuzz RPC 并将其替换为新系统。” 而不是“删除FizzBuzz RPC 并用新系统替换它。” 不过，您不必将描述的其余部分写成祈使句。

第一行应该是简短、重点突出的摘要，而描述的其余部分应填写详细信息，并包括读者全面理解变更列表所需的任何补充信息。它可能包括对正在解决的问题的简要描述，以及为什么这是最好的方法。如果该方法有任何缺点，应该指出。如果相关，请包括背景信息，例如错误编号、基准测试结果和设计文档的链接。