在 Code.fun 做 Code Review（二）

这周周会上，有同事说：

以前他的 PR 被 approved 就直接合；现在他会等上一两天，期待我来 review。晚上耍手机时如果突然一阵爆响就说明我 reviewing，他就爬起来好好看我的评论然后作出修改，学到很多东西。

被承认当然很爽、很骄傲。于是我想起这个系列，该再更一篇了。本文选材自七月的 Code Review 经验，趁热先分享一波。更早的 Code Review 过两天再往前翻翻看能否整理出来。

关于 Code Review 的介绍和经验，欢迎大家回顾：在 Code.fun 做 Code Review，本文我就不重复了。

0. 不应该使用独立 `<script src="...">`

在这个需求中，我们要使用火山引擎统计用户行为，某同事就直接在模版里添加了 <script src="..."> 导入初始化 JS。这段 JS 非常之短，只是帮火山引擎初始化执行环境，但是为了保证执行状态，它既不能 async 也不能 defer。

这样做有几个问题：

<script> 会阻塞后面的 HTML 渲染和 JS 执行；
这段 JS 虽然短，但是它的下载时间不会短：
1. 浏览器要解析 DNS，
2. 然后文件服务器要找到文件
3. 文件服务器甚至没有 http2

正确的做法是把它直接塞到现在 JS 里，只增加几十个字节而已。

1. `mounted` 钩子添加的事件处理函数没有清理；直接使用 `window.onblur`

这位同学犯了两个错误：

他在 mounted 钩子里添加了事件处理函数，但是并没有在 destroyed 钩子里清理。这可能导致内存泄漏，也可能导致奇怪的表现。
他直接将处理函数绑在 window 上，如果其它库、其它代码使用了同样的事件，就会导致冲突。

2. 糟糕的命名

这里这位同学犯了两个错误：

event 是名词，不应该用做函数名。函数名应该是动词、动宾短语、动副短语，表达一个动作。
event 是个非常非常通用的单词，用作全局函数太容易和其它全局对象起冲突或起混淆，应该加长。

结合上下文，合适的写法是：triggerHuoshanEvent()。

3. 依赖 `JSON.parse()`

我们需要记录一个小数据：sourceType，这个小数据被封装在一堆很大的 JSON 里面。这位同学直接拿 JSON.parse() 解码，然后打点。这样做当然可行，但是效率上非常之浪费。

大家千万不要小看 JSON.parse()，它其实有很多细节：

JSON 数据格式非常之严格，换言之，绝大对数情况下，必须把所有字符串都分析完才能结束
这个过程中，会构建大量对象
之后不再使用，这些对象又要被逐个回收

所以正确的写法，应该使用字符串匹配或者正则。字符串操作都是 O(1)，而且会在匹配到结果后立即返回，所以性能优秀非常多。

（其实吧，这位同学的正则也有些一言难尽，不过今天先不展开。）

4. TypeScript 的数据转换

使用 TypeScript 之后，我们需要声明函数的返回值类型。对于一些比较通用的返回值，比如截图中的 mongoose lean()，就要进行类型声明转换，后面的代码才知道取到的值是什么类型。这里大家要记住，无论是浏览器还是 node，TS 都要经历编译之后，变成 JS 再被执行。

所以 TS 阶段的类型转换不会出现在最终执行的代码里，也不会影响效率。但是截图中属于不同的情况，它会留下一个 .then() ，并增加一个微任务，不是我们想要的结果。

5. TS 的枚举值可以适当调整

TypeScript 提供 enum 关键字，用来声明枚举值，可以大大提升开发效率，降低出错概率。枚举的值可以手动指定，也可以省略，省略后 TS 会自动帮我们从 0 开始递增。上面就是典型的使用场景，列举若干设计软件，最后是 Other（其它），可以做成单选多选放在表单里。

这段代码的问题在于，设计软件很多，我们列出来的肯定有疏漏；即使没有，将来也会发布更多设计软件。比如有天，我们自己做了设计软件，叫 design.fun，那么该放到哪里呢？放到 Other 前面，它的值就会跟 Other 冲突；放到后面，又会使得数据看起来很奇怪。

此时只要给 Other 一个大点的值，拉开差距，就可以解决这个问题：

export enum DesignSoftware {
  Photoshop,
  XD,
  JsDesign,
  Other = 100, // 再大点也行，不过 100 应该够我们用了
}

6. 组件名称和根节点样式应包含不少于两个单词

这个其实是 Vue 官方的风格建议。原因很简单，一个单词，无论作为组件名称还是根节点样式名，都太容易和其它组件重复，也会影响 IDE 里快速跳转的效率，所以尽量多写几个单词，反正编译过程可以自动优化。

总结

时间过的真快，距离上次分享 Code Review 经验已经过去四个月了，我在 Code.fun 也是半年多工龄的老员工了。经过半年多的努力，我厂的产品完整了很多，但也很难称得上完善。希望这次分享的内容对大家有用，也希望大家多来试用我们的产品。

如果诸位读者老爷对软件质量管理、软件开发效率、Code Review 有什么想问的、想说的，敬请在评论区与我互动。

我现在在 code.fun 工作，我们的产品会把设计稿自动转换成代码，期望大大提升前端的开发效率，如果你对这个产品感兴趣，欢迎联系我，或直接试用。