在2024年, TypeScript肯定算不上什么新鲜的技术. 但是经过长时间的使用, 我认为可以使用, 但是要适度.
我们知道TypeScript的类型定义是业务的体现. 但是业务的变化在很多公司都是非常快的. 在产品功能上可能更改了一点点类型定义, 但是你的类型系统可能要大改. 这当中不排除是当初设计的不合理, 但即使设计地再合理, 产品一样有办法让你的合理变得不合理. 因为产品需求永远是合理的. 基于此, 你要么花更多的时间去维护类型, 要么就逐渐走向AnyScript.
实际上, 绝大部分团队水平是不具备熟练使用TypeScript的. 当一个新手遇到看不懂的类型的时候, 为了跑通代码, 直接一手可选链操作, 并不是什么罕见的行为. 而可选链可能是最小的灾难. 为了让代码跑通, 你无法预估他们会做什么样的修改, 以及哪些修改是合理的. 此时又考验你们团队的review执行力度了. 一环套一环.
这一点我是没什么感觉的, 因为我电脑性能过剩. 64G内存, 怎么折腾都没事. 但是很多人的内存只有16G甚至是8G, TypeScript的类型推导必然需要消耗一些内存. 大家是否经历过等待VSC加载类型系统的时候呢? 过于复杂的类型推导更会加剧这个现象.
我在这里, 并不是告诉大家不要用TypeScript. 相反, 我是坚定的TypeScript拥护者. 只是根据我的经验, 发现这个东西可能还是中庸更适合. 不使用TypeScript, 会导致维护火葬场. 但是过度使用, 比如各种体操到处窜, 大概率后面维护的人也会很难受. 如何定义过度使用? 这个就看你们团队水平和项目情况了. 就我自己来看, Omit, Pick, 泛型, 这些都算正常使用. 一旦要自己写type去推导, 我建议慎重考虑.
技术上的东西, 往往是没有银弹的. 需要根据你项目的情况和现有资源进行选型. 像一些非常知名的repo的TypeScript确实也用的炉火纯青. 但是他们是他们, 我们是我们. 需要根据自己的情况来定.
*请认真填写需求信息,我们会在24小时内与您取得联系。