AboutFE
AboutFE copied to clipboard
Published
20 hours ago •
CodingMeUp
CodingMeUp
37、Typescipt相关
TS 是什么，解决了什么问题，为什么要用TS
TypeScript = Type + Script（标准JS）。我们从TS的官方网站上就能看到定义：TypeScript is a typed superset of JavaScript that compiles to plain JavaScript。TypeScript是一个编译到纯JS的有类型定义的JS超集。
目标：生命周期较长（常常持续几年）的复杂SPA应用，保障开发效率的同时提升代码的可维护性和线上运行时质量
- 从开发效率上看，虽然需要多写一些类型定义代码，但TS在VSCode、WebStorm等IDE下可以做到智能提示，智能感知bug，同时我们项目常用的一些第三方类库框架都有TS类型声明，我们也可以给那些没有TS类型声明的稳定模块写声明文件，如我们的前端KOP框架(目前还是蚂蚁内部框架，类比dva)，这在团队协作项目中可以提升整体的开发效率。
- 从可维护性上看，长期迭代维护的项目开发和维护的成员会有很多，团队成员水平会有差异，而软件具有熵的特质，长期迭代维护的项目总会遇到可维护性逐渐降低的问题，有了强类型约束和静态检查，以及智能IDE的帮助下，可以降低软件腐化的速度，提升可维护性，且在重构时，强类型和静态类型检查会帮上大忙，甚至有了类型定义，会不经意间增加重构的频率（更安全、放心）。
- 从线上运行时质量上看，我们现在的SPA项目的很多bug都是由于一些调用方和被调用方（如组件模块间的协作、接口或函数的调用）的数据格式不匹配引起的，由于TS有编译期的静态检查，让我们的bug尽可能消灭在编译器，加上IDE有智能纠错，编码时就能提前感知bug的存在，我们的线上运行时质量会更为稳定可控。
TS和JS对比
| 成本点 | ES | TS | 说明 |
|---|---|---|---|
| 学习和踩坑成本 | ※※※※※ | ※※※ | 虽然是JS超集，但还是要学习TS本身及面向对象基础知识，开发环境搭建、使用中的问题和坑也需要自己趟，好在TS社区比较成熟，网上沉淀的资料很多 |
| 整体代码量 | ※※※※※ | ※※※※ | TS代码增加比较完善的类型定义的话整体代码量比原生ES多5%~10%左右 |
| 原生JS（标准ES、浏览器端、服务器端） | ※※※ | ※※※※※ | IDE内置了详尽的类型声明，可以智能提示方法和参数说明，提升了效率 |
| 依赖外部库（React、Lodash、Antd） | ※※※ | ※※※※※ | 有TS类型声明库，IDE智能提示和分析，效率提升 |
| 内部公共库、模块 | ※※※ | ※※※※ | 团队内部自行编写类型定义文件，有一定工作量，但开发效率可以有一些提升，逐步完善类型定义后，效率进一步提升 |
| 团队协作效率 | ※※ | ※※※※※ | 对系统配置、外部接口、内部模块做类型定义后，实例对象属性就不能随意改了，每个被调用方负责自己的对外类型展现（可以理解为形状），调用者只需关心被调用方的类型，不需关心内部细节 |
| 代码可维护性 | ※※ | ※※※※ | 由于团队成员水平差异，和软件的熵的特质，长期迭代维护的项目总会遇到可维护性的问题，有了强类型约束和静态检查，以及智能IDE的帮助下，可以降低软件腐化的速度，提升可维护性，且在重构时，强类型和静态类型检查会帮上大忙，甚至有了类型定义，会不经意间增加重构的频率 |
| 运行时稳定性 | ※※ | ※※※※ | 由于TS有静态类型检查，很多bug都会被消灭在上线前 |
小结
从上面的对比中可以看到，使用大家都熟悉的ES作为开发语言只在学习和踩坑成本以及整体代码量上占优，如果只是短期项目，那用ES无可厚非，但我们的项目生命周期持续好几年，是持续迭代升级的，目前TS社区已经比较成熟，学习资料也很多，而且TS带来的是内部协作开发效率、可维护性、稳定性的提升，所以从长远来看这个代价是值得付出的。而且各种类型声明定义文件的存在，是可以提升开发效率的；而且静态类型检查可以减少bug数量和排查bug的难度，变相也提升了效率，而且使整个项目相对变得更为稳定可控。