在 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

这样做有几个问题:

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

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

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

这位同学犯了两个错误:

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

2. 糟糕的命名

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

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

结合上下文,合适的写法是:triggerHuoshanEvent()

3. 依赖 JSON.parse()

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

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

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

所以正确的写法,应该使用字符串匹配或者正则。字符串操作都是 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 工作,我们的产品会把设计稿自动转换成代码,期望大大提升前端的开发效率,如果你对这个产品感兴趣,欢迎联系我,或直接试用。


欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

%d 博主赞过: