软件开发架构师

什么场景下不应该使用TypeScript?-InfoQ

前端 15 2019-09-03 04:07

TypeScript 很棒,但有时用它编程只是在浪费时间。TypeScript 的优势在于它能在编译时调试 JavaScript,但有些情况并不适合我们使用 TypeScript,比如构建小型应用程序或原型应用时。

作为一名前 C#程序员,我是 TypeScript 和强类型编程语言的忠实粉丝——说是这么说,但我也知道不是每个项目都很适合用 TypeScript 的。本文将探讨哪些类型的项目中 TypeScript 能完美满足项目需求,又在哪些项目类型中使用 TypeScript 只不过是在浪费时间。

TypeScript 的优势在于它能在编译时调试 JavaScript,为你节省很多麻烦;但如果你在错误的场合使用它就是另一回事了。就像使用其他工具一样,我们要用它来构建应用程序之前需要先了解我们应该做哪些准备,然后才能放心地大动干戈。

那么什么情况下我们不应该使用 TypeScript 呢?首先我们来搞清楚 TypeScript 到底是什么东西。

小技巧:推荐使用 Bit 来将组件及其依赖项和安装内容打包在一起,从而创建真正模块化的应用程序,获得更好的代码复用、更好的可维护性并减少开销。在应用之间共享组件,使团队能更快协作构建应用

什么是 TypeScript?

TypeScript 是一种开源的编程语言,由微软开发并维护,相当于 JavaScript 的超集;它可以在代码编译期间检查类型,并为编程语言添加了可选的静态类型。

微软设计 TypeScript 时主要考虑的是大型应用程序的开发需求,例如用户超过 500 人的企业级应用程序。TypeScript 还可以用于后端应用程序(例如 NodeJS),为其提供强类型语言。

那么什么时候我们不应该使用 TypeScript 呢?在下面的这些场景中你可能会重新考虑是否要使用它:

构建小型应用程序或原型应用

我认为这种情况是相当明显的。当你在构建原型应用以尽快展示生产级应用程序的功能效果时,你肯定不愿意在 JavaScript 中额外的类型检查器,因为它们可能会影响你的工作效率和交付速度。

我们比较同一种功能的两段代码:

JavaScript

复制代码
const myFunction = (x, y) => x * y;

TypeScript

复制代码
const myFunction = <T>(x: T, y: T) => x * y;

在项目中添加 TypeScript 代码需要我们声明很多类型,上面就是一个例子。大概没人想在原型设计阶段做这种事情。

请注意,TypeScript 用起来是很啰嗦的,因为我们需要声明很多类型才能完成工作。有人可能会说 TypeScript 的代码虽然啰嗦但容易调试,函数出错的时候尤其有用——但这取决于你或你的开发人员是怎样使用类型系统的。你的开发人员可能只是简单地在函数中输入各种类型,因此就算出了问题也没什么用。

也有很多人会争辩说,提前添加类型检查能为我们节省很多时间,在构建原型应用时可以预防很多会让你头疼的错误。确实,从长远来看静态类型可以为你节约大量时间,但如果你是在构建自己的原型应用,这个应用可能压根就不会进入下一阶段,你也就没法体验到类型系统的长期收益了。

此外,我认为 TypeScript 在这个阶段带来的好处是微不足道的,因为我们毕竟是在构建一个很小的应用程序。我们很少遇到类型问题,因为 JavaScript 是一种动态编程语言,无论类型如何都可以解析数据;因此与其他编程语言相比它非常宽容,用起来相当轻松。

TypeScript 未能带来预期的结果或价值

只有当 TypeScript 提供了你预期的那些好处时才有自己的价值,否则结果会变得很糟糕。在你将 TypeScript 深度用于实践工作之前,必须首先搞清楚为什么你要使用它,为什么要在项目中应用它。如果它没能提高你的生产力,没能增强你正在构建的应用程序的可靠性,那么你就没有从中获得什么价值。

比如说,首先你应该确定要构建的应用程序是什么类型。它是原型应用?还是一个企业级应用?抑或是将由数百名开发人员使用的 API?是一个仅关注用户交互或动画的应用程序?或者是一个充满复杂计算和公式的应用程序?

你需要评估 TypeScript 在你的使用场景中到底能提供多大程度的改善和价值,然后再决定要不要用它,这样才能充分利用它的优势。

你的开发人员缺乏经验而不愿意适应它

你应该仔细评估和观察开发人员使用 TypeScript 的经验水平。你还可以研究他们为了使用它需要多久的学习时间。如果团队中的开发人员都不熟悉 TypeScript,你可能就得放弃强制推广这项技术了,除非这样做的投资回报率很高。

没有令人信服的理由,我们就不能强迫团队适应 TypeScript,具体还要取决于团队处理的项目类型。另外还要考虑团队成员之前所拥有的技能类型组合。他们有 OOP 的开发经验吗?接触过 C#和 Java 这些吗?如果答案是否定的,那么强迫他们使用 TypeScript 就是弊大于利的。

最后,你应该主动询问你的团队是否愿意适应和使用这项技术。如果你没有正确评估你的团队拥有的技能组合,没有正当的理由也没有对你正在解决的问题作出恰当的分析,那么你可能会做出非常自私的决定。

我们要深入分析团队和项目是否真的需要 TypeScript,然后才开始研究如何在项目中使用它。你的团队成员一定会感谢你的谨慎态度的。

使用 TypeScript 仅仅是为了跟风

最后但同样重要的是,如果你只是为了“跟风”而使用 TypeScript,我认为你的方向是错误的。为了练习和掌握 TypeScript 而使用它没什么问题。但仅仅因为“跟风”而在生产级应用程序中使用它是不合理的,不代表你就能从中获得更多价值。

我们不能用技术的流行度来衡量我们正在使用的工具价值,这是一个非常糟糕的指标。TypeScript 犹如一场风暴,席卷了整个 JavaScript 生态系统,吸引了大批开发人员广泛使用。我认为这是因为大多数使用 TypeScript 的开发人员都有 Java 或 C#的背景和经验,所以 TypeScript 才得以出头。

我得承认自己就是这类开发人员的一员,当年微软刚发布它时我就开始使用 TypeScript 了,因为我那时候还不习惯使用标准的 JavaScript。

我经常面临需要在各种新技术中来回切换使用的情况。但作为一名软件工程师,随着我的经验愈加丰富,我也意识到如果一项新技术无法提供我们需要的价值,那么跟风使用这些技术就是毫无意义的。

小结

微软给我们送上了 TypeScript 这份礼物,为 JavaScript 生态系统送来了更趁手的开发人员工具;但它既可能是一种祝福也可能化身为一种诅咒,这取决于我们如何使用它。

我的建议是,你只需要了解 JavaScript 的工作机制即可,添加 TypeScript 会成为一种代码优化方法,但前提是在正确的上下文中正确地使用后者。

希望本文能帮助你决定到底在什么时候应该使用或放弃 TypeScript。

英文原文: https://blog.bitsrc.io/when-not-to-use-typescript-2431177135b3

文章评论