前言：读万字详文告诉你如何做 Code Review！ 有感，特此记录。

为什么要做 code review

代码变坏的根源

我们在审查代码时，总是会出现坏代码，在文章中举例了一些例子：

• 重复的代码
  写代码我们比拼的不是行数，发现有些方法，重复用到一段逻辑，这段逻辑如果不抽取出来成为一个方法，未来的修改就成了一个必须多点全部修改的大坑，稍有不慎，容易遗漏。重复代码在提交行数上，似乎挺壮观的。但是对后期运维来说是个隐患。
• 早期有效的决策不再有效
  完成一个接口不应该只是考虑实现功能，而应该考虑这个接口是否可以扩展，如何进行扩展为不断变化的需求提供预留。
• 过早的优化
  在还没弄清楚需求未来的变化的走向的时候，你的优化不仅可能导致你无法很好地实现新的需求，而且你对优化的预期的猜测有可能还是错的，导致实际上你除了把代码变复杂以外什么都没得到。
• 对合理性没有苛求
  对代码合理的进行严格规范要求，是一个优质的代码的基础。
• 总是面向对象/总喜欢封装
  不要胡乱的进行没有设计的封装，这会对团队协作有很大的破坏，在一个坏的设计下进行迭代，如同地基没有打好，楼只会越建造越趋近崩塌。
• 根本没有设计
  设计是很重要的，你肯定不可以知道个需求就没有计划的埋头瞎干，这对后续的迭代是毁灭性的。

必须形而上的思考

model 设计

一开始面对业务领域，应该思考自己的模型边界，把可能要做的能力都拿进来思考，构建一个 model，设计一套通用的 store 层接口，基于通用接口的逻辑代码。当产品不断发展，就是不停往模型里填内容，而不是推翻重来。model 设计，是我们形而上思考问题的一个方面，我们想要获得这种能力，首先要去看前人的思考，站在前人的肩膀上，再用上自己的通识能力，去进一步思考，这样，我们才可以更好的具备model 拆解/抽象/构建的能力。

常见原则

• KISS 原则：Keep It Simple Stuped
  KISS 原则是指产品的设计越简单越好，任何没有必要的复杂都是需要避免的。简单不是容易做到的，需要大家在不断的时间和 code review 过程中去积累思考，pk 中触发思考，交流中总结思考，才能做得愈发地好，接近’大道至简’。
• 组合原则: 设计时考虑拼接组合
  设计功能时尽可能地将其组件化，工具化，形成一个可插拔的插件，这样减少重复率也提高了我们复用和扩展性。
• 吝啬原则: 除非确无它法, 不要编写庞大的程序
  代价是代码越多，越难维护，难调整。对于代码，要吝啬。能把系统做小，就不要做大。review 时，就应该最关注核心 struct 定义，构建起一个完备的模型，核心 interface，明确抽象 model 对外部的依赖，明确抽象 model 对外提供的能力。其他代码，就是要用最简单、平平无奇的代码实现模型内部细节。
• 透明性原则: 设计要可见，以便审查和调试
  对用户而言，良好的文档有助于提高可显性；对程序员而言，良好的变量和函数名有助于提高可显性。作为程序员至少要理解自己调用的函数/复用的代码大概是怎么实现的。而，为了保证大家能对自己代码能做到有控制力，所有人写的函数，就必须具备很高的透明性。而不是写一些看了一阵看不明白的函数/代码，结果被迫使用你代码的人，直接放弃了对掌控力的追取，甚至放弃复用你的代码，另起炉灶，走向了’制造重复代码’的深渊。
• 通俗原则: 接口设计避免标新立异
  设计程序过于标新立异的话，对程序的破坏性，简直无法想象。
• 缄默原则: 如果一个程序没什么好说的，就沉默
  不要乱打印log，乱七八糟一大排的日志只会影响排查问题，真的需要打印log时，把必要信息给全，让其容易理解，否则一个不知道代表着什么的log还不如不打了呢。我们将用户的注意力视为有限的宝贵资源，程序员自己的注意力也是一样的。
• 补救原则: 出现异常时，马上退出并给出足够错误信息
  对于程序错误 ，我们就必须要严格做到在问题最早出现的位置就把必要的信息搜集起来，高调地告知开发和维护者“我出现异常了，请立即修复我！”

如何实践code review

• 对于代码格式规范，100%严格执行，严重容不得一点沙。
• 文件绝不能超过 800 行，超过，一定要思考怎么拆文件。工程思维，就在于拆文件的时候积累。
• 函数对决不能超过 80 行，超过，一定要思考怎么拆函数，思考函数分组，层次。工程思维，就在于拆文件的时候积累。
• 代码嵌套层次不能超过 4 层，超过了就得改。多想想能不能 early return。工程思维，就在于拆文件的时候积累。
• 从目录、package、文件、struct、function 一层层下来 ，信息一定不能出现冗余。比如 file.FileProperty 这种定义。只有每个’定语’只出现在一个位置，才为’做好逻辑、定义分组/分层’提供了可能性。
• 多用多级目录来组织代码所承载的信息，即使某一些中间目录只有一个子目录。
• 随着代码的扩展，老的代码违反了一些设计原则，应该立即原地局部重构，维持住代码质量不滑坡。比如:拆文件；拆函数；用 Session 来保存一个复杂的流程型函数的所有信息；重新调整目录结构。
• 基于上一点考虑，我们应该尽量让项目的代码有一定的组织、层次关系。我个人的当前实践是除了特别通用的代码，都放在一个 git 里。特别通用、修改少的代码，逐渐独立出 git，作为子 git 连接到当前项目 git，让 goland 的 Refactor 特性、各种 Refactor 工具能帮助我们快速、安全局部重构。
• 自己的项目代码，应该有一个内生的层级和逻辑关系。flat 平铺展开是非常不利于代码复用的。怎么复用、怎么组织复用，肯定会变成’人生难题’。T4-T7 的同学根本无力解决这种难题。
• 如果被 review 的代码虽然简短，但是你看了一眼却发现不咋懂，那就一定有问题。自己看不出来，就找高级别的同学交流。这是你和别 review 代码的同学成长的时刻。
• 日志要少打。要打日志就要把关键索引信息带上。必要的日志必须打。
• 有疑问就立即问，不要怕问错。让代码作者给出解释。不要怕问出极低问题。
• 不要说’建议’，提问题，就是刚，你 pk 不过我，就得改！
• 请积极使用 trpc。总是要和老板站在一起！只有和老板达成的对于代码质量建设的共识，才能在团队里更好地做好代码质量建设。
• 消灭重复！消灭重复！消灭重复！

总结