探索JavaScript到TypeScript的转换:实践出真知

发表时间: 2022-07-27 10:36

TypeScript 在这几年的需求呈现指数级增长的趋势,越来越多的开源项目开始使用 TypeScript 进行重构。那 TypeScript 究竟好不好,好在哪里?什么样的重构方法和流程最高效?出于对这些问题的好奇,我们找到了陈芸老师。她是 FreeWheel 核心研发团队的高级软件工程师,负责前端开发工作。


同时陈芸老师也是已经上线的 QCon+ 案例研习社「TypeScript 在中大型项目中的落地实践」专题的讲师,因此我们带着对 TypeScript 相关的疑惑和好奇对陈芸老师进行了采访,让我们一起来看看老师的思考吧。

InfoQ:你最近在负责什么样的工作呢?


陈芸:我在组内主要负责前端相关的一些工作,包括产品的开发、前端技术探索、公共组件的开发等等。最近在做几个项目,有公司产品的前端大改版,也有公司内部的前端流程优化工具开发,还参与一些工程师自我驱动的项目。

InfoQ:你在使用 TypeScript 的过程中,有遇到什么印象深刻的困难吗?


陈芸:使用 TypeScript 的过程总体来说还是挺顺利的,得到的效果要比预想好得多。当然,困难肯定还是有的。


比如在对已有 JavaScript 项目 TypeScript 化的过程中,当我们发现有编译错误时,需要判断是逻辑本身的 bug 还是类型定义有问题,这样的 bug 往往是不会使页面直接出错的,而是数据展示不符合预期,需要对业务逻辑有足够的了解以及对类型定义有足够的自信才能快速定位问题。


再比如,我们做 JavaScript 迁移的项目是一个多团队参与的大项目,无法一步到位,且每个模块的迁移标准和方式都不同,代码检查的标准也不相同,所以我们给各个模块都配置了 tsconfig,各自 include 各自的模块路径,公共库则需要符合各个配置要求。于此同时,还未完成迁移的 JavaScript 代码也不能受到影响,这个配置体系是非常复杂的。


还有关于提升编译效率的问题,我们知道 TypeScript compile 的耗时比较大,一方面我们把 TypeScript compile 作为单独的进程进行类型检查,不阻塞主进程的打包过程;另一方面为了保证类型检查的效果,我们在把 TypeScript compile 作为 lint 的一部分,也就是说每一次代码提交都会跑一遍 tsc, 当项目已经发展到非常大型时,如果每次都对全部文件进行 compile,则会使得 lint 的时长越来越长,所以我们在这里做了一个优化,把每次修改的文件用脚本放到 tsconfig 的 include 中,动态生成一个临时的 tsconfig,这样 compile 的过程只会针对提交的有修改的文件,这就加速了 lint 的过程。

InfoQ:你们团队在选择 TypeScript 时,是基于什么考虑呢?


陈芸:我们的出发点其实很简单,就是为了提高代码质量,从而提高产品质量,像我们 ToB 的公司,一个小的前端 bug 就可能会影响到很多客户,从而给公司造成巨大的损失,所以产品的质量是重中之重。除此之外,由于我们的产品业务逻辑非常复杂,我们也希望代码能够有更好的可读性以及更易于维护。

InfoQ:你认为从 JavaScript 迁移到 TypeScript 有哪些更加高效的方法?


陈芸:说到效率,首先选择一个合适的编辑器绝对会大大提高效率,比如对 TypeScript 原生支持的 VS Code。然后,可以参考一些成熟的 TypeScript 项目的配置方案,类型定义公约等,站在巨人的肩膀上。


我们的项目由于是一个开发中的项目,为了兼顾产品的原有开发进度,我们选择了对项目进行逐个文件迁移的方式,这里值得说的一点是文件迁移的顺序。当时我们对项目做迁移时是从底层公共库入手,再到数据交互模块,最后是上层业务组件,这样的迁移顺序理论上是一个比较好的顺序,但也会有一些问题,比如如果负责迁移的人对原来的项目实现不是特别熟悉的话,对底层公共库的类型定义往往会有偏差,当我们做上层业务组件的迁移时,经常需要反复修改底层公共库的类型定义,这造成了许多额外的花销。如果条件允许,比较好的方式是由最熟悉某块代码的人(比如原作者本人)来做那部分的代码迁移。


最后一点,从项目决定 TypeScript 化开始,所有新提交的代码要求都是 TypeScript 的,否则项目将很难彻底完成 TypeScript 化的过程。

InfoQ:TypeScript 已然成为前端新宠,那你认为什么情况下不适合使用 TypeScript 呢?


陈芸:如果从项目规模上出发,我其实觉得都是适合的,即使是个人的小型项目,有类型约束也会使代码更加健壮。当然如果存在这样的客观情况,项目时间紧且团队成员中的大多数还没有对 TypeScript 有足够了解,我认为这个时候使用 TypeScript 是有风险的。另一种情况,目前的 JavaScript 项目非常成熟,且可预计的将来不会有大量的功能迭代,个人觉得也没有必要非要重写来做 TypeScript 化,这相当于把一个大型项目重新开发一遍,当然这不是最大的难题,最大的难题是还必须和原项目的所有业务逻辑保持一致。

InfoQ:最后,你想对其他正在使用或者想要使用 TypeScript 的小伙伴说些什么呢?


陈芸:首先,我肯定是支持小伙伴们使用 TypeScript 的,尤其是新项目,无论大小,都可以尝试一下,没有试过是很难感受到它带来的好处的,当它实实在在地帮助大家提升了开发效率,提前发现了隐藏的 bug 时,我相信就很难再回到 JavaScript 了。


前端的新技术日新月异,一方面我们需要及时了解前端资讯,比如定期看看 JS Weekly、CSS Weekly 这样的订阅;另一方面,我们最好能对自己感兴趣的技术做一些尝试,看看有没有一些日常工作中的痛点是这些新技术能帮助解决的,这样既可以得到自我提升,又可以帮助到实际的工作。

嘉宾简介


陈芸 FreeWheel 核心业务团队高级软件工程师


就职于 FreeWheel 核心业务团队,主要负责前端开发工作,对前端前沿技术非常热衷,致力于提升产品质量,优化用户体验。前豆瓣全栈开发工程师,对 ToB,ToC 的项目都有深刻的理解。