首页  >  文章  >  web前端  >  TypeScript(和 JSDoc)与 JavaScript

TypeScript(和 JSDoc)与 JavaScript

Linda Hamilton
Linda Hamilton原创
2024-10-25 06:42:29619浏览

简介

即使到了 2024 年,TypeScript 发布 12 年后,JSDoc 发布 17 年后,许多人仍然不知道为什么要在 JavaScript 项目中使用静态类型工具,即使它已经成为 JavaScript/ NodeJs 社区。

在本文中,我将解释什么是 TypeScript 和 JSDoc,以及为什么您应该在项目中使用其中之一。

它们是什么

TypeScript 和 JSDoc 是允许 JavaScript 进行静态类型化的工具。请参阅下面的示例。

如您所见,TypeScript 通常比 JSDoc 简洁,但另一方面,JSDoc 不需要构建步骤,它可以直接与 JavaScript 代码中的注释配合使用。

打字稿

convert-string-to-int.ts(TYPESCRIPT 文件!)

TypeScript (and JSDoc) vs JavaScript

JS文档

convert-string-to-int.js(JAVASCRIPT 文件!)

TypeScript (and JSDoc) vs JavaScript

优点

在谈论优点之前,我必须说,无论您读了多少文章或这些文章有多好,都无法描述使用静态类型时开发人员的体验有多好。

没有人可以用语言或论证来解释使用具有静态类型的代码库比无类型的代码库有多么好,即使是最好的诗人也是如此。

我和许多其他人一样,会尝试将这种感觉转化为事实和数据,但我确保这不足以描述确切的感觉。

避免生产中出现错误

毫无疑问,这是静态类型的最大优势。无论是在避免返工还是在节省金钱方面,都无法用言语来形容它的帮助有多大。

为了快速交付内容(主要是修补程序),我们最终没有时间编写单元测试或测试解决方案的所有可能流程。如果您使用纯 JavaScript,则无法确保:

  • 您正在使用的所有变量都存在

  • 您使用的所有变量均已声明

  • 您正在使用该类型允许的方法(例如:您可以在数字变量中使用映射)

  • 如果您正在比较等效变量(您不应该将数字与数组进行比较)

如果你没有很好地测试你的代码,你将不得不再次修复错误,将宝贵的时间花在你以前可能会咳嗽的事情上。由这些事情引起的错误可能听起来很愚蠢,但它们是发生最多的错误。

使用静态类型,您可以确保更安全、更快速的开发,极大地减少生产中的错误数量,并允许开发人员只关注真正提供价值的事情:业务逻辑。

没有不必要的测试

大多数遗留项目和云密集型项目(您的许多资源都属于云的项目)在本地运行代码的过程很困难,或者更糟糕的是,您必须部署它才能在没有模拟的情况下执行。

在本地运行事物的过程对于开发人员来说可能非常耗时且疲惫不堪,而能够避免它可以节省大量资源(时间、金钱、耐心、云资源等)。

使用静态类型,代码是非常可预测的,你可以开发一切,知道代码的每个部分发生了什么,并非常容易地跟踪执行情况,这使得你只需要运行代码是在开发完成后,真正测试一切是否按预期工作。

没有过时的文档

大多数时候(如果不是全部)当我们尝试编写有关函数的文档并尝试添加输入/输出的示例时,它眨眼间就会过时。开发人员永远不会记得更新文档,Scrum Master 也永远不想分配足够的时间来执行此操作。

使用静态类型,代码就是一个实时文档。它永远不会过时,因为当开发人员更新代码时,他们也会更新文档。

避免 CommonJs / ES 模块出现问题

在 NodeJs 中实现 ES 模块之后,许多库开始迁移到这种新的代码编写方式,因此它们的新版本(更安全、可靠、高性能且具有更多功能)与旧版本的 JavaScript 不兼容,这会让您陷入不安全的过时版本。

猜猜什么可以与 CommonJs 和 ES 模块兼容,而无需更改代码中的任何内容(只需配置中的几行)?没错,TypeScript(不幸的是,我认为 JSDoc 没有这个优势)。

自动完成并避免写错

TypeScript (and JSDoc) vs JavaScript

不必记住某个东西所具有的每个属性和方法,让静态类型和您最喜欢的 IDE 为您做这件事!

这减少了开发时间,因为:

  • 你不必来回查看某物的属性

  • 您可以只输入属性/方法的首字母并按 Enter(或选择正确的建议,然后按 Enter),它将自动完成

它还避免了单词写错,这种情况会导致生产中出现比应有的错误更多的错误。

减少知识损失,不浪费时间

在一个项目中,不同的开发人员会编写代码的特定部分,而对于编写代码的人来说似乎非常明显的部分,对于每个人来说可能并不直观。

如果其他开发人员致力于另一个人编写的新事物,他们将必须花一些时间来理解它,然后才能进行任何更改。使用静态类型可以让开发人员节省大量时间来理解变量的值和执行流程。

如果编写该代码的开发人员离开公司/团队,影响不会那么大,因为所有这些文档都直接在代码上。易于查找且易于理解。

开发人员还需要减少对结对编程的依赖才能在项目上工作,如果项目类型良好且足够简单,他们甚至可以在不与项目中的某人交谈的情况下进行改进/更改,增加荒谬他们的效率。

现代且对开发商有吸引力

根据 Stack Overflow 开发者调查,TypeScript 是最受欢迎的语言之一,这是连续 4 年的结果:

2020:

TypeScript (and JSDoc) vs JavaScript

2021 年:

TypeScript (and JSDoc) vs JavaScript

2022 年:

TypeScript (and JSDoc) vs JavaScript

2023:

TypeScript (and JSDoc) vs JavaScript

JSDoc 没有出现在调查中,所以我没有任何数据表明它是一个不错的选择。我唯一能说的是 HTMX 正在使用它,但它是一个非常简单的库。

另一方面,从这项调查中我们可以看出,近年来,开发人员更喜欢 TypeScript,而不是 JavaScript。

灵活的

您不需要输入所有内容。 TypeScript 和 JSDoc 可以猜测大多数事物的类型,这使得它比 Java 或 C 等其他语言更容易且更简洁。

TypeScript (and JSDoc) vs JavaScript

对于 TypeScript,在最坏的情况下,只需使用 any。 any 是百搭类型,它代表任何东西,因此你应该不惜一切代价避免它,但是如果你时间不够或者不想被缺乏所阻碍某种类型,你有这个选择。

对于 JSDoc,不要评论任何东西,它是纯粹的 JavaScript!

不再需要不必要的重构

我将在它的学习曲线较高部分解释更多关于它的原因,但我会在这里剧透一些。

代码难以理解的代码库需要重构,而没有适当文档的代码库(我们同意如果它与代码分离就不可能维护)有更多的部分不可能没有理解就无法理解大量的挖掘和分析时间。

重构不应该因为你的代码无法理解而发生,而是因为性能问题或业务逻辑的变化。必须做同样的事情两次对每个人都不好:开发者、用户和投资者。

给开发者更多的独立性

长期项目由多人参与是很常见的,而且总是需要一些时间(无论是对于新手还是经验丰富的开发人员)来让新手精通该代码库。

使用静态类型,我们可以大大减少必要的时间,因为开发人员至少可以单独理解代码的基础知识,并且只需要其他开发人员的帮助来理解更复杂的业务逻辑(如果它们没有记录在文档中)代码,但这是另一篇文章的主题)。

它让新人更容易加入项目,大大降低他们的学习曲线,并允许他们在项目上工作时破坏某些东西的风险较小,从而提高整个团队的效率。

缺点

更复杂的构建步骤

TypeScirpt 的唯一缺点是它的构建步骤更加复杂(因为说实话,现在所有 JavaScript 项目都已经有一个构建步骤,所以这只会让它变得更复杂一点)。

您可能需要适当的插件或适配器来将构建过程与 TypeScript 集成,但现在我们拥有大量成熟且可用于生产的库、插件、工具以及使其工作所需的任何内容。

我不会撒谎,它可能第一次会给你带来一些麻烦,就像 JavaScript 生态系统中的大多数其他工具一样,但还不足以超越专业人士。

如果你选择使用 JSDoc 而不是 TypeScript,TypeScript 的这个唯一缺点就消失了,但出现了一个新的缺点:如果你不使用类来表示更复杂的类型,JSDoc 就不能很好地处理它们。

揭穿论点

它有很高的学习曲线

静态类型需要您多写一些东西,但是学习曲线与您必须编写的额外 : 字符串无关,而是与使用它的难度有关该代码库.

如果没有静态类型,您需要更多上下文来了解代码中发生的情况、变量具有哪些值以及正在应用什么业务逻辑。

让我们看一个例子:

function processOrders(orders) {
 // Logic here
}

仅凭这些信息,您可以确定订单有哪些值吗?你可能会说它是一个数组!,但你猜怎么着?您错了。订单是一个对象。它有哪些属性?祝你好运,至少花一分钟时间查看代码来弄清楚。

属性是可选的吗?它们总是存在吗?它们是对象、数组还是字符串?您团队中的其他成员是否具备这方面的知识,或者编写此代码的人早已不在了?

静态类型本身减少了学习曲线大量

使用纯 JavaScript,每个从事与流程订单相关的工作的人都必须经历相同的过程:

  • 问自己什么是命令

  • 在流程订单逻辑中花费大量时间试图弄清楚

  • 如果需要 processOrders 的特定行为,可能会向其他团队成员询问更多详细信息并花费时间

让我们用数字来表示,这样会更有趣:

  • 一个5人团队,每人年薪10万美元

  • 假设他们必须每 6 个月处理一次 processOrders,时间足以忘记具体细节

  • 他们花了 5 分钟来弄清楚他们需要的一切(是的,我在这里非常非常乐观)

  • 一个项目通常有数千个或至少数百个函数,所有这些函数都类似于 processOrders,但我们这里只考虑一个小项目,只有 10 个函数。

  • 5 名开发人员 * 10 分钟/年 * 10 个功能 = 每年 500 分钟

如果每个开发人员每分钟赚取 88 美分,仅计算出 10 个函数接收和返回哪些内容就需要花费 440 美元。这是没有生产力的时间,不会产生任何价值,在最好的情况下,你的神奇项目只有 10 个功能,而不是现实世界中的项目有 数千个 个功能。

现在,使用 TypeScript:

interface Orders {
 ids: Array<number>
 skipTypes?: Array<string> // Skip orders if they have specific types
}

interface ProcessedOrders {
 total: number
 success: number // Amount of orders that were succesfully
 processed skipped: number // Amount of skipped orders based on input filters
}

function processOrders(orders: Orders): Promise<ProcessedOrders> {
  // Logic here
}

我知道这是一个可怕的、不直观的函数,但这种情况发生在代码中。 不应该,但确实如此,所以最好至少将其记录下来。

与纯 JavaScript 版本相反,这里有您需要了解的所有上下文函数接收和返回的所有内容,无论其是否可选,以及函数的基本原理.

在这一切之后,你仍然可以争论很多事情,比如 这是一个干净的代码问题,而不是 JavaScript 的问题!它缺乏文档 问题,而不是 JavaScript 的问题问题!, 但我向你保证,所有这些事情都是不同的 问题,是的,发生在代码中,我可能会在其他文章中解决这些问题,但不是本文的重点。

一些库不支持 TypeScript

这就是 TypeScript 的魔力:你不需要你的库来支持 TypeScript。

您无需任何输入即可使用该库,并且它的工作方式相同,但由于使用纯 JavaScript 库会更困难(因为它没有本文中提到的任何优点),您可能应该考虑使用不同的。

我必须学习一些新东西

是的。作为开发人员,我们必须每天学习新东西。这是我们工作的一部分。我们来这里是为了针对问题创建技术解决方案,作为参考,并找出如何解决我们面临的问题。

学习有很多好处的新东西是值得付出时间的努力。

结论

在了解静态类型工具对开发有多大帮助之后,并且没有任何明显的缺点,没有办法否认它对每个人都有多大的好处:开发人员、用户和公司的财务。

我希望这篇文章可以帮助您理解它并说服您的同伴改善您的开发体验。

以上是TypeScript(和 JSDoc)与 JavaScript的详细内容。更多信息请关注PHP中文网其他相关文章!

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn