前言 与TypeScript相遇，还是在ThoughtWorks工作的时候。那个时候，我们需要维护大量的前端遗留项目，需要与客户规划我们的人效，需要控制系统迭代带来的bug率。我们接手的项目往往缺乏严谨的注释和完整的代码说明文档，这导致在维护JavaScript遗留项目时，需要花费更多的时间去厘清参数及函数之间的关系，甚至需要用debugger逐层去观察值的变化。工作非常低效，但客户的需求又总是急迫的，这迫使我们去思考如何提升团队的工作效率。 这个时期也是Facebook开始推广Flow的时候。我们觉得添加静态类型应该是个非常不错的方向，也看了很多应用静态类型的成功案例。碰巧Flow对于遗留项目非常友好，你不需要为每个文件、每个函数、每行代码都添加类型，而只需要在你认为有必要的地方写上类型即可。所以我们很快进行了实验。 然而，我们在采用Flow后不久就发现了很多新产生的问题： 1）升级困难，配置复杂。尤其是在React Native项目中，经常会在升级后运行失败。 2）生态弱势。很多第三方库当时没有Flow的类型问题件。 3）难于上手。Flow的气质更像考究的学院派风格，功能强大灵活，但对于新加入团队的人而言，其难度令人生畏。 于是，我们又将目光投向了TypeScript。最初了解TypeScript是看到Angular团队在更新Angular 2时开始全面采用TypeScript代码。他们给出了这样两个理由： 1）TypeScript明确了抽象。在大型工程项目中，我们希望模块之间的边界是使用接口定义的，而JavaScript不足以清晰表达类似的边界划分，Flow也不能。而TypeScript可以定义接口，可以强制程序员去思考API的边界，去设计代码，而不只是编写代码，暴露代码的耦合。 2）TypeScript可以使代码在一定程度上达到“Self-documenting”…