目录
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 并用新系统替换它。” 不过，您不必将描述的其余部分写成祈使句。
第一行应该是简短、重点突出的摘要，而描述的其余部分应填写详细信息，并包括读者全面理解变更列表所需的任何补充信息。它可能包括对正在解决的问题的简要描述，以及为什么这是最好的方法。如果该方法有任何缺点，应该指出。如果相关，请包括背景信息，例如错误编号、基准测试结果和设计文档的链接。
3.2 关于CL的大小
这里的大小就是一次上库修改的功能的多少，尽可能的一次上库，也就是一个CL只描述一个最小的功能。对于大的CL包括几项，最好可以做拆分上库。小CL的好处：
-
审稿比较快。 对于审阅者来说，花 5 分钟时间多次审阅小型 CL 比留出 30 分钟时间审阅一个大型 CL 更容易。
-
审查得更彻底。 随着巨大的变化，审稿人和作者往往会因为大量的详细评论来回变化而感到沮丧——有时甚至会遗漏或丢弃重要的观点。
-
引入错误的可能性较小。 由于您所做的更改较少，因此您和您的审阅者可以更轻松地有效地推断 CL 的影响并查看是否引入了错误。
-
如果被拒绝，就会减少浪费的工作。 如果你写了一个巨大的 CL，然后你的审稿人说总体方向是错误的，那么你就浪费了很多工作。
-
更容易合并。 处理大型 CL 需要很长时间，因此合并时会出现很多冲突，并且必须频繁合并。
-
更容易做好设计。 完善小变更的设计和代码运行状况比完善大变更的所有细节要容易得多。
-
减少对评论的阻碍。 发送整体更改的独立部分允许您在等待当前 CL 审核时继续编码。
-
回滚更简单。 大型 CL 更有可能会涉及在初始 CL 提交和回滚 CL 之间更新的文件，从而使回滚变得复杂（中间 CL 可能也需要回滚）。
3.3 处理审稿人的意见
审查的目标是维持我们的代码库和产品的质量。当审阅者对您的代码提出批评时，请将其视为他们试图帮助您、代码库和公司，而不是对您或您的能力的人身攻击。
[礼貌和尊重]始终应放在首位。如果您不同意审阅者的观点，请找到合作的方法：要求澄清，讨论优点/缺点，并解释为什么您的做事方法对代码库、用户和/或 公司 更好。
如果您无法亲自或通过视频通话与他们交谈，请向他们发送私人电子邮件。以友善的方式向他们解释你不喜欢什么以及你希望他们采取不同的做法。
通过给代码添加注释来让审稿人明白代码的含义。
解决冲突的第一步应该始终是尝试与审稿人达成共识。如果您无法达成共识，请参阅公司的代码规范。
4. 关于代码审查
参考：https://google.github.io/eng-practices/review/reviewer/
代码审查应该关注如下方面：
-
设计：代码设计良好并且适合您的系统吗？
-
功能：代码的行为是否符合作者的预期？代码的行为方式对其用户有利吗？
-
复杂性：代码可以变得更简单吗？其他开发人员将来遇到此代码时是否能够轻松理解和使用该代码？
-
测试：代码是否具有正确且设计良好的自动化测试？
-
命名：开发人员是否为变量、类、方法等选择了清晰的名称？
-
评论：评论是否清晰且有用？
-
风格：代码是否遵循我们的 风格指南？
-
文档：开发者是否也更新了相关文档？
在进行代码审查时，您应该确保：
-
代码设计得很好。
-
该功能对于代码的用户来说是有好处的。
-
任何 UI 更改都是合理且看起来不错的。
-
任何并行编程都是安全完成的。
-
该代码并不比需要的更复杂。
-
开发人员没有实现他们将来可能需要但不知道他们现在需要的东西。
-
代码有适当的单元测试。
-
测试是精心设计的。
-
开发人员为所有内容都使用了清晰的名称。
-
注释清晰且有用，并且主要解释为什么而不是什么。
-
代码有适当的文档记录（通常在 g3doc 中）。
-
该代码符合我们的风格指南。
确保检查您被要求检查的每一行代码，查看 上下文，确保您正在改善代码健康状况，并赞扬开发人员所做的好事。
如何写代码评审意见：
确保您始终对代码进行评论 ， 而不是对开发人员进行评论，保持礼貌和尊重。
坏：“当并发显然没有任何好处时，为什么要在这里使用线程？”
好：“这里的并发模型增加了系统的复杂性，但我认为没有任何实际的性能优势。由于没有性能优势，因此该代码最好是单线程而不是使用多线程。”
-
和善的对代码进行评论
-
解释你的推理。
-
在给出明确指示与仅指出问题并让开发人员决定之间取得平衡。
-
鼓励开发人员简化代码或添加代码注释，而不是仅仅向您解释复杂性。
后记：
本文并没有从细节代码上说怎么去review，这还是靠各位在工程实践中进行。但是文中描写的一些大原则，或许能让你在跟别人讨论的过程中用上一两句，那么就显的逼格层次更加的高级，文中基本参考的谷歌的文档做法。怎么装逼？答案就是看谷歌程序员怎么做。
