这周周会上,有同事说:
以前他的 PR 被 approved 就直接合;现在他会等上一两天,期待我来 review。晚上耍手机时如果突然一阵爆响就说明我 reviewing,他就爬起来好好看我的评论然后作出修改,学到很多东西。
被承认当然很爽、很骄傲。于是我想起这个系列,该再更一篇了。本文选材自七月的 Code Review 经验,趁热先分享一波。更早的 Code Review 过两天再往前翻翻看能否整理出来。
关于 Code Review 的介绍和经验,欢迎大家回顾:在 Code.fun 做 Code Review,本文我就不重复了。
0. 不应该使用独立 <script src="...">
![](https://blog.meathill.com/wp-content/uploads/2022/08/image.png)
在这个需求中,我们要使用火山引擎统计用户行为,某同事就直接在模版里添加了 <script src="...">
导入初始化 JS。这段 JS 非常之短,只是帮火山引擎初始化执行环境,但是为了保证执行状态,它既不能 async
也不能 defer
。
这样做有几个问题:
<script>
会阻塞后面的 HTML 渲染和 JS 执行;- 这段 JS 虽然短,但是它的下载时间不会短:
- 浏览器要解析 DNS,
- 然后文件服务器要找到文件
- 文件服务器甚至没有 http2
正确的做法是把它直接塞到现在 JS 里,只增加几十个字节而已。
1. mounted
钩子添加的事件处理函数没有清理;直接使用 window.onblur
![](https://blog.meathill.com/wp-content/uploads/2022/08/image-1.png)
这位同学犯了两个错误:
- 他在
mounted
钩子里添加了事件处理函数,但是并没有在destroyed
钩子里清理。这可能导致内存泄漏,也可能导致奇怪的表现。 - 他直接将处理函数绑在
window
上,如果其它库、其它代码使用了同样的事件,就会导致冲突。
2. 糟糕的命名
![](https://blog.meathill.com/wp-content/uploads/2022/08/image-3.png)
这里这位同学犯了两个错误:
event
是名词,不应该用做函数名。函数名应该是动词、动宾短语、动副短语,表达一个动作。event
是个非常非常通用的单词,用作全局函数太容易和其它全局对象起冲突或起混淆,应该加长。
结合上下文,合适的写法是:triggerHuoshanEvent()
。
3. 依赖 JSON.parse()
![](https://blog.meathill.com/wp-content/uploads/2022/08/image-4.png)
我们需要记录一个小数据:sourceType
,这个小数据被封装在一堆很大的 JSON 里面。这位同学直接拿 JSON.parse()
解码,然后打点。这样做当然可行,但是效率上非常之浪费。
大家千万不要小看 JSON.parse()
,它其实有很多细节:
- JSON 数据格式非常之严格,换言之,绝大对数情况下,必须把所有字符串都分析完才能结束
- 这个过程中,会构建大量对象
- 之后不再使用,这些对象又要被逐个回收
所以正确的写法,应该使用字符串匹配或者正则。字符串操作都是 O(1)
,而且会在匹配到结果后立即返回,所以性能优秀非常多。
(其实吧,这位同学的正则也有些一言难尽,不过今天先不展开。)
4. TypeScript 的数据转换
![](https://blog.meathill.com/wp-content/uploads/2022/08/image-5.png)
使用 TypeScript 之后,我们需要声明函数的返回值类型。对于一些比较通用的返回值,比如截图中的 mongoose lean()
,就要进行类型声明转换,后面的代码才知道取到的值是什么类型。这里大家要记住,无论是浏览器还是 node,TS 都要经历编译之后,变成 JS 再被执行。
所以 TS 阶段的类型转换不会出现在最终执行的代码里,也不会影响效率。但是截图中属于不同的情况,它会留下一个 .then()
,并增加一个微任务,不是我们想要的结果。
5. TS 的枚举值可以适当调整
![](https://blog.meathill.com/wp-content/uploads/2022/08/image-6.png)
TypeScript 提供 enum
关键字,用来声明枚举值,可以大大提升开发效率,降低出错概率。枚举的值可以手动指定,也可以省略,省略后 TS 会自动帮我们从 0 开始递增。上面就是典型的使用场景,列举若干设计软件,最后是 Other
(其它),可以做成单选多选放在表单里。
这段代码的问题在于,设计软件很多,我们列出来的肯定有疏漏;即使没有,将来也会发布更多设计软件。比如有天,我们自己做了设计软件,叫 design.fun,那么该放到哪里呢?放到 Other
前面,它的值就会跟 Other
冲突;放到后面,又会使得数据看起来很奇怪。
此时只要给 Other
一个大点的值,拉开差距,就可以解决这个问题:
export enum DesignSoftware {
Photoshop,
XD,
JsDesign,
Other = 100, // 再大点也行,不过 100 应该够我们用了
}
6. 组件名称和根节点样式应包含不少于两个单词
![](https://blog.meathill.com/wp-content/uploads/2022/08/image-7.png)
这个其实是 Vue 官方的风格建议。原因很简单,一个单词,无论作为组件名称还是根节点样式名,都太容易和其它组件重复,也会影响 IDE 里快速跳转的效率,所以尽量多写几个单词,反正编译过程可以自动优化。
总结
时间过的真快,距离上次分享 Code Review 经验已经过去四个月了,我在 Code.fun 也是半年多工龄的老员工了。经过半年多的努力,我厂的产品完整了很多,但也很难称得上完善。希望这次分享的内容对大家有用,也希望大家多来试用我们的产品。
如果诸位读者老爷对软件质量管理、软件开发效率、Code Review 有什么想问的、想说的,敬请在评论区与我互动。
我现在在 code.fun 工作,我们的产品会把设计稿自动转换成代码,期望大大提升前端的开发效率,如果你对这个产品感兴趣,欢迎联系我,或直接试用。
发表回复