当前位置: 主页 > JAVA语言

重构java-java代码重构书籍

发布时间:2023-05-19 22:03   浏览次数:次   作者:佚名

前端框架 Svelte 作者 Rich Harris:“我太老了,不能再胡闹了”。

作为 JavaScript 的超集,TypeScript 自发布以来深受开发者喜爱,从 JavaScript 迁移到 TypeScript 也一度成为一种趋势。

前段时间,State of JavaScript 对近 40000 名 Web 开发人员进行调查,在回答有关 JavaScript 编程风格问题的人中,TypeScript 的使用率高达 98.9%。其中,20.7% 的受访者仅使用 TypeScript 编写代码,而仅使用 JavaScript 的受访者比例为 8.2%。尽管 TypeScript 可以编译成 JavaScript,但对于许多开发人员来说,TypeScript 仍是优先选项。有声音甚至认为,“TypeScript 正在慢慢吞噬前端开发人员的世界”。

但另一个有趣的趋势是,一些开发者正在“反向操作”——从 TypeScript 迁移到 JavaScript。

Svelte 计划重构代码:从 TypeScript 切换到 JavaScript

今年 3 月,前端框架 Svelte 作者 Rich Harris 在接受 The New Stack 采访时表示重构java,Svelte 的第一个主要修订工作正在进行中,目前,团队正在将底层代码从 TypeScript 切换到 JavaScript。Rich Harris 认为,这一更新将使团队能够在今年晚些时候为 Svelte 5 融入“伟大的想法”。

作为一个在 2019 年才诞生的新兴框架,Svelte 发布之初的一大痛点就是不支持 TypeScript。2020 年 7 月,Svelte 终于加入了 TypeScript 支持。如今 3 年不到,就要从 TypeScript 切换到 JavaScript?

消息一出,不少网友跑去 Twitter 求证,Rich Harris 当即给出了肯定的回复,并表示“原生支持 TypeScript 是很棒的选择,直到你有了 TypeScript 的依赖分布,那时它就变成了一个加载的 footgun。我们欢迎其他人去胡闹,但我太老了,不能再胡闹了”。

重构java_java代码重构书籍_java 重构

5 月 9 日,Svelte 团队发布了一个名为 TS to JSDoc Conversion 的 PR,根据描述,Svelte 团队将会从 TypeScript 迁移到 JSDoc。

java 重构_java代码重构书籍_重构java

该举动迅速引发网友激烈讨论。有用户提问“为什么要这么变?我一直在到处搜相关的问题和讨论,但找不到答案。”

至于背后的原因,其实 Rich Harris 在上个月接受采访时就已作出回答。Rich Harris 认为 TypeScript 对开发库来说“不值得”,团队正转向 JavaScript 和 JSDoc。Rich Harris 在采访中提到:“我们已经决定,在 Svelte 核心代码库中完成从 TypeScript 到 JavaScript 的迁移。原因比较复杂,所以我一直没能做充分解释。”

Rich Harris 表示:“我的观点是,类型确实很棒,但 TypeScript 有点麻烦……一旦用上了.ts 文件,就必须同时使用支持它的工具……所以我逐渐觉得,使用 TypeScript 这样的非标语言并不值得。于是,我们开始将所有类型都放入 JSDoc 注释,这样既保证了类型安全,又回避了缺点。毕竟这只是 JavaScript,所有内容都在注释当中,只要运行代码就行。我们在 Sveltekit 代码中就是这么做的,效果非常好。所以对于 Svelte 4.0,我们也将采取同样的思路、借此加快开发速度。”

Svelte 并不是第一个放弃 TypeScript 的社区。2020 年,Deno 完成了内部代码从 TypeScript 到 JavaScript 的迁移,以减少构建时间,生成高性能代码。最近,有消息称 Deno 也在考虑在内部切换到 vanilla JS。

在相关设计文档中,“问题”部分展示了 Deno 迁移的原因:

在 cli/js 中更改文件时的增量编译时间需要几分钟,修改起来非常缓慢且痛苦。

我们在 cli/js 中使用的打字稿组织/结构正在产生运行时性能问题。例如,我们最近意识到我们无法让 TS 生成一个名为“Header”的类,因为它隐藏了我们 d.ts 文件中的声明。因此,我们将类命名为“HeaderImpl”并将其分配给“window.Header”。但这会产生“Header.name”具有错误值的问题。所以我们被迫添加不必要的运行时代码

Object.defineProperty(HeaderImpl, "name", { value: "Header" });

修复“Header.name”。谁知道这是否会将 Header 踢出 V8 中的某些优化路径。最佳的做法是生成“class Header { … }”,任何不足都表明设计中存在根本缺陷。

TypeScript 应该可以帮助我们组织代码,但有人可能会声称它具有相反的效果。例如,我们有两个独立的 Body 类。由于生成运行时代码涉及的复杂性,因此很难了解这一点。理想情况下,我们会有一个系统,其中两个 Body 类显然是错误的。

我们的内部代码和运行时 TS 声明必须已经手动保持同步。TSC 没有帮助我们生成 d.ts 文件——当我们之前尝试时,它的开销和复杂性太大了。

从 TypeScript 转向 JavaScript 是一个好选择吗?

虽然 Svelte 不是最流行的 JavaScript 框架,但在开发者心目中却有着极高的地位。开发人员之所以选择 TypeScript 是因为他们发现强类型有助于减少错误重构java,并通过代码补全和弹出帮助等功能改善代码编辑器内的开发体验。

JSDoc 则是一种 API 文档工具,同样可用于类型检查。Visual Studio Code 已经内置 JSDoc 支持,开发者只需添加以下内容:// @ts-check 至 JavaScript 文件开头即可。文档解释道,“当无法推断类型时,可以使用 JSDoc 注释进行指定。”此功能实际由 TypeScript 提供支持,所以 TypeScript 和 JSDoc 可以说是相互依赖。

但一个容易被忽略的细微差别是,Rich Harris 指的主要是库开发场景下的 TypeScript。如果大家正在构建应用程序,那么实在没必要转向 JSDoc。“这就没必要了,因为在构建应用程序的过程中,大家无论如何都需要构建的步骤。应用开发的重点在于优化代码、控制它的体量,并把一切都捆绑起来。但如果是想构建一个库,那我强烈建议改用 JSDoc。”

虽然 Rich Harris 解释了团队从 TypeScript 转向 JavaScript 和 JSDoc 的理由,但面对强势提升的 TypeScript 普及度,Rich Harris 的决策似乎显得有点“非主流”,在 Hacker News 上也引发了许多网友讨论。

Rich Harris 本人也在 Hacker News 上回复道“没想到一个内部重构 PR 能在 Hacker News 上排名第一”,Rich Harris 还进一步介绍了迁移背景,以免大家面对变动胡猜乱想。

java 重构_java代码重构书籍_重构java

Rich Harris 表示,“如果你是 TypeScript 的铁杆批评者,认为我们脱 TS 入 JS 的做法证明了你的观点……抱歉要让你失望了。但如果你是 TypeScript 的狂热拥护者,觉得我们脱离 TS 就是背叛了精神信仰……你同样会失望”。

Rich Harris 补充道,首先,Svelte 不会放弃类型安全,只是决定将类型声明从 .ts 文件转向带有 JSDoc 注释的 .js 文件。作为 Svelte 用户,这不会影响大家在 Svelte 中使用 TypeScript 的能力——从 Svelte 导出的函数,仍拥有大家所熟悉的各种 TypeScript 优点(类型检查、智能许可、内联文档等)。Svelte 对 TypeScript 的支持承诺,比以往任何时候都更加坚定(具体示例请参阅)。

此外,Svelte 用户基本感受不到任何变化。有限的区别就是包体积更小了(不需要传递巨大的 sourcemap 之类),还可以通过 cmd-clicking 使用“Svelte ”及其子包导入的函数来调试框架(它提供的不是无用的类型声明,而是引向实际源代码,开发者可以直接在「node_modules」中编辑并查看实际变化)。

Rich Harris 表示,希望此举能显著降低框架的贡献参与门槛,现在开发者:1)不需要理解如何链入 repo;2)不必在监视模式下运行构建流程;3)不需要为了观察 source 和 dist 代码间的变更而理解其映射关系。

Rich Harris 认为,这次调整将使 Svelte 的用户和贡献者受益,同时也给项目团队减轻负担。团队经常需要针对沙箱测试对源代码做修改,新的工作流要比以往的 build 步骤好很多。体验过 TypeScript 工具那参差不齐质量的朋友肯定都为此头痛过,这次的迁移也帮团队回避了此类问题。相对而言,最大的缺点就是在 JSDoc 中编写类型确实不像在 TypeScript 中那么舒服。这个缺点虽然相对可以接受,但团队内仍然存在争议,当前网上的激烈争论也主要来自这个角度。

“总而言之,我们的迁移决定基于实际需求,而绝不是什么立场问题。长期以来,我们一直以求真务实的态度构建 SvelteKit(反而是在 Svelte 那边更多追求理想主义),毕竟在这边提高生产力才是硬道理。”Rich Harris 总结道。

参考链接: