我踩过了 TypeScript 的坑，只想告诉你快来

　　嘉宾 ｜ 许侃

　　编辑 ｜ 贾亚宁

　　用过 TypeScript 的开发者往往都会不约而同地直呼“真香”，但是我们也无法忽略 TypeScript 诸如学习曲线较陡和开发成本较高等阻碍。因此如何高效地使用和掌握 TypeScript，使其在中大型的项目中发挥最好的作用一直是大家讨论的热点话题。

　　本次我们邀请了 FreeWheel 的 Tech Lead 许侃老师，请他来分享对于 TypeScript 的应用和思考，同时许侃也是已经上线的 QCon+ 案例研习社「TypeScript 在中大型项目中的落地实践」专题的出品人，如果你对专题内容感兴趣，欢迎点击观看：https://time.geekbang.org/qconplus/album/72

　　TypeScript 适用场景

　　许侃：从我们组的切换体验来看，TypeScript 主要是在大规模协作中保证了代码质量，很多错误可以在本地开发环境中被及时发现。因此对于 TypeScript 的适用场景，我个人觉得：对于 3 人以上的团队如果有一个公共项目需要协作开发，那么选择 TypeScript 利大于弊，付出一定的类型定义成本和团队学习成本，可以长久地降低维护成本和提升代码质量。

　　另一种比较合适的场景则是团队内部的公共包，一来公共包的业务场景相对稳定，因此固定下来接口等类型定义相对来说不会有什么争议；二来通过暴露清晰的类型定义可以帮助调用方降低适配成本。

　　不适合的场景则因人而异，比如有人会觉得任何项目都应该用类型约束的 TypeScript 来撰写，有人则觉得 JavaScript 已经足够完成一些小型任务，不必非得“杀鸡用牛刀”。我的建议是：根据场景来选。如果时间紧、任务重，先上 JavaScript 一定是更合适的选择，类型欠缺之类的“债务”完全可以后面再去弥补。另一种就是小项目，代码少且意图足够清晰，搭配合适的单元测试一样可以保证高质量。

　　这里想谈一个比较现实的问题。很多 TypeScript 的拥趸者经常对 TypeScript 本身的上手成本避而不谈，这对于 TypeScript 的发展并不是一个好的事情。任何一项技术都是有其优缺点的，TypeScript 本身的上手成本恰恰是很多团队迟迟下不了决心的门槛。这个时候需要的是尽可能用一些可重复的实践经历来告诉还没采用的人——这条路的坑我们已经蹚过了，如果你们有意向，欢迎来试试。这也是当初我作为出品人做 TypeScript 案例研习社的初心之一，只有能落地的实践，才经得起时间的考验。

　　使用 TypeScript 重构

　　许侃：重构这件事本身其实业界也有很多讨论，推荐大家去阅读软件行业巨擘 Martin Fowler 老爷子的《重构》。首先作者鼎鼎大名自不必说，其次这次第二版使用的样例语言正是 JavaScript，对于前端工程师而言阅读体验会更为友好。

　　‍关于使用 TypeScript 去做重构，我们团队积累的实际经验分享一下：

　　在开始逐步向 TypeScript 迁移的过程中，要格外注意每次重构后的自动化测试结果：

　　一方面花一定时间去补充自动化测试提升代码覆盖率，另一方面用这些测试结果来验证重构没有对业务造成非预期的影响；

　　这里需要提一下：FreeWheel 是一家 ToB 的公司，任何一点业务代码的改动都比较敏感，需要大量的自动化测试来保证不会影响已有产品的功能。历史上积累的大量测试案例给了团队很大信心进行重构，也最大程度地规避了重构带来的风险。

　　把公共部分的代码优先抽出来进行 TypeScript 化，这部分的界限足够清晰，接口定义很容易确定下来。然后通过给公共代码撰写单元测试来保证多种业务的使用场景都能得到覆盖。

　　业务需求优先，避免同一时期在同一块代码里添加新业务和进行代码重构。这算是一种控制变量的思路，也是降低重构风险的一个好办法。从团队领导的角度而言，分配任务的时候就需要明确分清楚这块；从实际代码提交的成员角度来说，就需要把手头的提交至少明确地分成两次独立的提交——第一次完成业务需求和完善测试，第二次再用 TypeScript 去重构。

　　其他的细节部分，可以参考 TypeScript 案例研习社中陈芸老师分享的内容（https://time.geekbang.org/qconplus/detail/100091377），从两个不同的案例方向进行了详细介绍，相信能给你带来更大的启发。

　　老项目继续用 JavaScript 重构

　　许侃：代码迁移在我们团队内还有另一种表现形式——产品层面的变更。这也引发了我们团队内部继续使用 JavaScript 重构还是迁移到 TypeScript 的讨论。

　　产品层面的变更，主要是指随着时间迁移，产品面临几大变化——需要更换统一的前端 UI（组件行为层面和前端展示效果层面）；需要调整一些产品功能来更好地服务客户需求（下线一些已有功能和增强一些已知功能）。对于一些老的项目，我们还是采用了迁移到更新的 JavaScript 版本的思路。主要是：

　　先把需要迁移的代码独立到一个仓库里，避免对原始仓库的干扰。为了保留代码提交历史，可以考虑 git filter-branch 等命令来做一个通用脚本；

　　其次通过自动化工具对整体代码进行一次改写，尽量升级到最新的语法。这里面复杂的情况可以用到 AST 工具，简单的则可以通过 magic-string 等 JavaScript 库写脚本来进行直接替换；

　　然后搭配上最新的 prettier、eslint、husky 等配置，让团队成员不需要操心代码风格，同时尽可能让社区通行的工程实践能在项目里落地；

　　最后要做好 CI 脚本的检查，有些同事可能会绕过 eslint 等检查，需要让 CI 站好“最后一班岗”，尽可能把问题在代码合并前得到暴露和解决。

　　TypeScript 无意取代 JavaScript

　　许侃：从趋势而言，TypeScript 的路一定会越来越宽，但是并不能完全超过或取代 JavaScript。

　　TypeScript 在前端中大型项目协作上的优势，目前确实没有对手，这意味着这块的基本盘只会越来越稳固，同时逐步侵占目前尚未迁移到 TypeScript 的项目的空间。但正如前面所言，JavaScript 永远是第一选择，只有能活下来的项目才有机会去考虑偿还“类型债务”。另一方面，选用 TypeScript 所希望达到的较高项目质量、较低文档维护成本等愿景，前端社区一样有着其他的选择，前端社区极度繁荣和活跃，作为开发者选择让自己最高效的工具即可，不必拘泥于 TypeScript。

　　另外想聊个题外话，最近 TypeScript 团队在 TC39 提出了一个将类型标注应用到现在的 JavaScript 代码的提案。大意是引入一种新的语法，会被 JavaScript 运行时忽略，但是 TypeScript、Flow 等 JavaScript 的超集或方言可以利用这个来继续提供类型检查等能力，但是免去了开发过程中的构建过程。提案本身刚刚进入了 Stage 1 阶段，未来可期。可以看出 TypeScript 团队一直在思考如何更好地服务 JavaScript 构筑起来的世界（而不是取代），所以就让 TypeScript 的归 TypeScript，JavaScript 的归 JavaScript 吧。

　　团队 Leader 在推广 TypeScript 重构中的角色

　　许侃：团队 Leader 其实可以做的事情很多，从我的个人经验总结来看，主要是以下三部分：

　　明确定位，做好预期管理

　　如果团队成员对于 TypeScript 不太熟悉，那么需要先培养 TypeScript 的氛围，让“星星之火可以燎原”。实操下来可以是团队内部的 TypeScript 分享，让熟悉 TypeScript 的同事把这门语言介绍给全团队的同事。同时在团队内部明确 TypeScript 的价值和意义，给予一定的资源支持（学习 TypeScript 的资源、适配 TypeScript 的开发时间等），让团队成员有明确的预期。

　　总结沉淀，完成抛砖引玉

　　如果团队有了一定的经验，那么就需要及时对迁移过程进行总结。一方面让团队成员来总结做得好的和可以继续提升的部分，通过可量化的数据来认可 TypeScript 对重构 / 迁移的作用；另一方面把这一总结落地到文字 / 幻灯片等产出里，因为公司内肯定还有没开始迁移的团队，以抛砖引玉的心态去做好分享，让 TypeScript 为公司带来更大的作用。如果这一过程做得足够好，你会发现自身团队的技术影响力也得到了显著提升。

　　有先有后，不搞一蹴而就

　　另外需要明确 TypeScript 中打算采用的技术的优先级。这话可能有点绕，解释一下主要是先把基础类型搭建起来，不要太拘泥于立马上手高级类型和“类型体操”，软件工程的核心在于不断迭代；另外对于 tsconfig 的配置也尽量以精简为主，有必要再去用更细致的控制功能，因为这门语言还在持续更新发展，一味求新求准往往容易丢失注意力，导致把该早点做的事情给安排到了靠后的位置；另外关于 tsc 和新的 compiler 的选择，优先上手 tsc，等到团队接受了 TypeScript 并形成了良好的协作氛围再考虑采用其他性能更优的 compiler 去减少开发时间并提升开发效率。因为 tsc 的支持一定是官方做得最好的，在项目早期用一个相对省心的 compiler 可以让团队把更多精力放在整个项目的完成上。这和软件工程先保证交付，再考虑卓越的思路也是一脉相承的。

　　积累技术势能

　　许侃：我从两个角度来分享一下：

　　理念角度，需要明确一点“you own your own career”

　　翻译过来是对自己的职业生涯负责。技术成长对于职业生涯本身不是一个硬性要求，但对于想要在技术这条路继续前进、想要不被技术浪潮落下的同学来说，最好的便是保持对技术的敏感度、对技术的热忱，不断学习和精进。

　　实操角度，程序员本质上还是“手艺人”

　　手艺能否精进靠的是经年累月的不断积累。所谓“台上一分钟，台下十年功”。对于打算走技术路线的人来说，一定要保证自己时常写一写代码来练手。很多新技术都是“新瓶装旧酒”，打好基础对于掌握新技术会取得事半功倍的效果。

　　所谓“闻道有先后，术业有专攻”，保持谦虚谨慎的态度，多向身边人和社区学习，这个时代学习技术的门槛越来越低，但学习技术的审慎态度要保持。

　　最后，如果你对我们团队做的事情有兴趣，欢迎联系：kxu@apac.freewheel.com