一个人的编程才能怎样去衡量？特别是在面试中，怎样防止“高分低能儿”、“专业做题家”、“面试造火箭”，咱们在作业中又是需求什么样的编程技能和才能，这个问题其实很值得沉思。
在很早以前的时分，面试会问你有多少代码量，便是写过多少行代码，这个标准非常的好，根本可以衡量代码水平，可是口说无凭啊，项目经历也是口说无凭，既然才能考不成，那就考智商吧。
1. 关于智商
一个智商高的人，编程的潜力非常的大，特别是大公司里边根本只在乎这个，说的很简略，可是怎样去调查智商，又是一个大难题，这就像考研，高考或许除了选拔聪明的人还需求勤勉的人，可是考研根本便是要选拔出来聪明的人，那怎样办，考数学。数学是真科学，可是对大多数作业根本没多少用途，可是就考智商来说，仍是很公正的：聪明人能学好数学，学好数学的人一定聪明。
下面来看看编程界的骚操作：谷歌发现聪明的人拿手算法，那面试就考算法啊，然后全球编程公司都仿效。可是致命一点拿手算法的人不一定聪明，聪明的人不一定喜欢搞算法，反而不聪明的人经过刷题也可以蒙混过关。或许是没有更好的办法吧，咱们都开始卷算法的时分，还的确是可以的。可是这种内卷丝毫不产生价值，由于算法作业的时分大概率不用，便是用也可以用ChatGPT瞬间生成啊，不需求自己写的，可谓“天下苦Leeetcode久已”。
2. 关于才能
先梳理下程序员日常的作业需求那些东西，首要便是参阅各种手册，技能文档，读代码了解结构，然后制定方案，进行编码完成。这其间一方面是关于技能手册的把握经历，另一方面便是代码的架构才能。这些东西看似跟代码或许不沾边，可是其都是来源于代码的，俗话说：“一切都在代码里”。从代码里边跳出来又跳进去，这种才能就好像你的组长在辅导你的时分一样，这种才能可以说便是代码review。你的组长经过review你的代码，虽然组长榜首次见，可是可以根据代码结构快速的看到你的完成逻辑，并指出技能方向和改进方面。代码review开始成为评估软件工程师的更好办法，俗话说：“行家伸伸手就知有没有”。
代码review才能日益重要的原因：
- AI生成的代码越来越多，AI才能不行前，还需求人工去鉴别。现在的AI更像是给专业的人供给资料，由于不保真，还需求专业的人进行鉴别选用。
- 通常高档职务进行的代码review多，愈加的强调与他人协作，进行辅导和反馈。
- 反映受试者是否具有全面的推理、考虑和沟通视角。
- 对代码的了解才能要求高，毕竟大多数时分咱们是在读代码、抄代码、而并非原创的去写代码。
- review的速度快，可以更快的融入现有项目，更好更快的发明生产力。
- review相关于做题，愈加的贴近于实战，直接面对团队遇到的实践挑战。
代码review的一些测验项：
- 阅览数据拜访、反常处理、输入处理等一些典型的代码，看是否能看懂，了解用法
- 有bug的代码，是否能找出并处理
- 代码一些代码进行重构，策略和办法及作用
- 找一段运行缓慢的代码，对功用进行优化
- 给一段代码的单元测验代码，看是否包含所有状况，怎样对单元测验做改进
3. 关于changelist
参阅：google.github.io/eng-practic…
咱们在提交代码的时分都有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. 关于代码检查
参阅：google.github.io/eng-practic…
代码检查应该重视如下方面：
- 规划：代码规划良好而且合适您的体系吗？
- 功用：代码的行为是否符协作者的预期？代码的行为方式对其用户有利吗？
- 杂乱性：代码可以变得更简略吗？其他开发人员将来遇到此代码时是否可以轻松了解和运用该代码？
- 测验：代码是否具有正确且规划良好的自动化测验？
- 命名：开发人员是否为变量、类、办法等挑选了明晰的称号？
- 谈论：谈论是否明晰且有用？
- 风格：代码是否遵循咱们的风格攻略？
- 文档：开发者是否也更新了相关文档？
在进行代码检查时，您应该保证：
- 代码规划得很好。
- 该功用关于代码的用户来说是有优点的。
- 任何 UI 更改都是合理且看起来不错的。
- 任何并行编程都是安全完成的。
- 该代码并不比需求的更杂乱。
- 开发人员没有完成他们将来或许需求但不知道他们现在需求的东西。
- 代码有恰当的单元测验。
- 测验是精心规划的。
- 开发人员为所有内容都运用了明晰的称号。
- 注释明晰且有用，而且首要解说为什么而不是什么。
- 代码有恰当的文档记载（通常在 g3doc 中）。
- 该代码契合咱们的风格攻略。
保证检查您被要求检查的每一行代码，检查 上下文，保证您正在改进代码健康状况，并赞扬开发人员所做的好事。
怎样写代码评审定见：
保证您一直对代码进行谈论 ， 而不是对开发人员进行谈论，坚持礼貌和尊重。
- 坏：“当并发明显没有任何优点时，为什么要在这儿运用线程？”
- 好：“这儿的并发模型增加了体系的杂乱性，但我以为没有任何实践的功用优势。由于没有功用优势，因而该代码最好是单线程而不是运用多线程。”
- 和善的对代码进行谈论
- 解说你的推理。
- 在给出明确指示与仅指出问题并让开发人员决议之间获得平衡。
- 鼓励开发人员简化代码或增加代码注释，而不是只是向您解说杂乱性。
后记：
本文并没有从细节代码上说怎样去review，这仍是靠各位在工程实践中进行。可是文中描写的一些大原则，或许能让你在跟他人评论的过程中用上一两句，那么就显的逼格层次愈加的高档，文中根本参阅的谷歌的文档做法。怎样装逼？答案便是看谷歌程序员怎样做。
“啥都懂一点，啥都不通晓，
干啥都精干，干啥啥不是，
专业入门劝退，可谓程序员杂家”。
后续会持续更新，纯干货剖析，欢迎分享给朋友，欢迎谈论交流！
