代码html个人网页完整代码_代码html位置_html代码

作者 | 米兰

译者| 王强

规划| 蔡芳芳

转发链接:

前言

随着时间的推移,我们给应用程序添加了很多新功能,应用程序变得越来越大,技术环境也在不断变化,各种新的框架、组件、架构不断涌现。 当开发人员回顾多年前编写的代码时,可能会很想将其全部丢弃并重写。 但很多时候这是不可能的,因为重写的风险和复杂性,你必须找到一种让旧代码与新代码共存的方法。 本文介绍了管理数字资产和产品信息的SaaS产品THRON的研发团队在将Web应用迁移到Vue的过程中如何实现新旧代码共存的技术思路和实践。

本文最初发表于博客。 经原作者授权,InfoQ中文网翻译并分享。

我们从2013年开始编写公司的旗舰产品。这个产品是我们编写的第二个单页应用程序(SPA)。 我们之前写的第一个程序是一个小项目。 我们分析了以往的经验,避免再犯同样的错误。

那时的浏览器和js库的环境与今天不同。 我们的企业客户目标需要覆盖IE9用户,我们不信任大型复杂的框架,所以我们更愿意采用一套独立的库。 我们构建了自己的框架:灵活、易用,并且有很多我们想要的功能,比如数据绑定、模板、路由、国际化……

至于缺少的功能,我们可以自由选择自己喜欢的库,自然所有的优点和缺点都会被接受。 这是“太多选择”的情况。

我们还写了一些关于拆分单体应用程序之旅的其他文章:

前端代码架构

随着时间的推移,我们向应用程序添加了许多功能; 我们变得更加熟练,技术环境也得到了发展; 但最重要的是,应用程序变得越来越大。 我们尽最大努力保持最高的代码质量,但如您所知,一段代码使用多年后,开发人员看到它总是想扔掉它并重写它。 对于大型 SPA(单页应用程序),由于重写的风险和复杂性,这是不可能的。 我们必须寻找另一种方式来满足新的需求:

但我们如何在不停止产品开发的情况下实现所有这些目标呢? 在一个版本中重写整个应用程序是不可能的。

我们使用的方法

我们把工作分为三个阶段:

第一步:从头开始,假装重新设计一切

我们试图抛弃现有的应用程序,从头开始想象一种新的架构,参考流行的框架和著名的应用程序来获取灵感。

然后,我们创建了一个概念验证 (POC) 解决方案来验证我们的需求。 在开发它时,我们添加了另一个要求:它必须提供独立于应用程序每个部分的管理级别的框架。 这意味着我们不能严格绑定到特定的框架。 迟早我们会需要一个新的框架来处理一些特殊需求或提高可维护性,希望那天到来时我们不必重构。

POC的思想是做一个“加载器”,可以一一导入我们需要的部分,同时尽量控制依赖的数量,直到我们想要导入用不同框架编写的部分。 在这种情况下,旧应用程序只是要加载的一部分。

我们发现,在不停止产品开发和应用程序现代化的情况下,这是唯一的选择:将旧界面视为新应用程序的特殊部分。

基于这些需求,POC的核心变成了“功能部件管理器”,它基于Vue及其强大的导航保护。 当用户请求某个部分时,我们会检查其功能并加载正确的代码块。

遗留应用程序结构如下:

代码html位置_代码html个人网页完整代码_html代码

遗留应用程序的加载过程

为了将旧应用程序作为模块加载,我们需要进行一些更改:

然后我们遇到了一个问题:新应用程序允许我们只创建新部件,这是可能的最小实体,但在某些地方我们觉得它仍然太大了。 为什么我们只停留在“功能部分级别”?

因此,我们找到了三个希望使用新架构管理的选项:

代码html位置_html代码_代码html个人网页完整代码

为应用程序创建新的部分不太常见,添加新的 () 则更为频繁:

事后看来,这是一个非常好的主意,因为我们确实找到了一个可以推动我们走向现代发展的场景:

代码html位置_html代码_代码html个人网页完整代码

搜索区域是在不同部分或应用程序中使用的组件的示例

第二步:更改代码库结构

当我们开始开发 SPA 时,我们有一个好主意,就是在组织源代码时将视图和控制器分开。 随着时间的推移,我们意识到简单地按部分分组可以帮助新开发人员更轻松地查看源代码并熟悉项目。

因此,让我们首先组织存储库:

按功能部分分隔资源。 旧代码被降级到一个文件夹中,我们的目标是逐渐减少那里的代码(当我们重构时),最终掏空文件夹:所有旧代码最终都会转换为新代码。

第三步:开关技术

事实证明,通过 POC 收集的经验非常有价值。 我们利用这一经验编写了一个真正的加载器,并将旧应用程序作为新加载器中的简单模块运行。

但总有一些事情会出错。 如果我们有机会重写整个遗留部分,我们就可以极大地提高性能,而且在加载遗留部分时,我们的性能仍然会保持在以前的水平。 最终用户并未从此次升级中受益。

我们对大规模重写感到不安的原因之一是自动化测试套件并未涵盖所有内容。 如果没有自动化测试套件,就会错过许多边缘场景或用户模式,这可能会导致代码中出现新的回归错误。 这是我们随着时间的推移学到的教训:测试可以极大地提高你对重构的信心,因为人的记忆可能有问题,但测试结果可以永远持续。

综上所述

最后,采用现代 JS 框架被证明是一个了不起的进步:开发人员可以专注于应用程序逻辑而不是底层细节。 通过每项新功能,我们现在需要维护的代码更少,并且可以为客户提供更好的性能。 旧代码和新代码共存于独立于框架的组件中,这些组件共同构成了我们的 SPA。

新架构还给我们带来了其他改进:

我们的下一步将是改进测试套件。

您是否有过类似的经历,需要让新旧代码共存? 你是怎么应对的? 请在评论部分告诉我们。

作者 | 米兰

译者| 王强

规划| 蔡芳芳

转发链接:

好了,今天的主题就讲到这里吧,不管如何,能帮到你我就很开心了,如果您觉得这篇文章写得不错,欢迎点赞和分享给身边的朋友。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注