Code Review Item

▶︎ 对于代码格式规范，100%严格执行，眼中容不得一点沙。

▶︎ 文件绝不能超过 800 行，超过一定要思考怎么拆文件。工程思维，就在于拆文件的时候积累。

▶︎ 函数对决不能超过 80 行，超过一定要思考怎么拆函数，思考函数分组，层次。工程思维，就在于拆文件的时候积累。

▶︎ 代码嵌套层次不能超过 4 层，超过了就得改。多想想能不能 early return。工程思维，就在于拆文件的时候积累。

▶︎ 从目录、package、文件、struct、function 一层层下来 ，信息一定不能出现冗余。比如 file.FileProperty 这种定义。只有每个“定语”只出现在一个位置，才为“做好逻辑、定义分组/分层”提供了可能性。

▶︎ 多用多级目录来组织代码所承载的信息，即使某一些中间目录只有一个子目录。

▶︎ 随着代码的扩展，老的代码违反了一些设计原则，应该立即原地局部重构，维持住代码质量不滑坡。比如：拆文件、拆函数、用 Session 来保存一个复杂的流程型函数的所有信息、重新调整目录结构。

▶︎ 基于上一点考虑，我们应该尽量让项目的代码有一定的组织、层次关系。我个人的当前实践是除了特别通用的代码，都放在一个 git 里。特别通用、修改少的代码，逐渐独立出 git，作为子 git 连接到当前项目 git，让 Golang 的 Refactor 特性、各种 Refactor 工具能帮助我们快速、安全局部重构。

▶︎ 自己的项目代码，应该有一个内生的层级和逻辑关系。flat 平铺展开是非常不利于代码复用的。怎么复用、怎么组织复用，肯定会变成“人生难题”。

▶︎ 如果被 review 的代码虽然简短，但是你看了一眼却发现不咋懂，那就一定有问题。自己看不出来，就找高级别的同学交流。这是你与他人共同 review 代码、共同成长的宝贵时刻。

▶︎ 日志要少打，要打日志就要把关键索引信息带上，必要的日志必须打。

▶︎ 有疑问就立即问，不要怕问错，让代码作者给出解释，不要怕问出低级问题。

▶︎ 不要说“建议”，提问题就直接提，有错误就得改！

▶︎ 请积极使用 trpc。总是要和老板站在一起！只有和老板达成的对于代码质量建设的共识，才能在团队里更好地做好代码质量建设。

▶︎ 消灭重复！消灭重复！消灭重复！