专业建站网产品网络推广,dedecms建手机网站,张家港网站建设模板,工程咨询公司加盟合作点击上方 前端Q#xff0c;关注公众号 回复加群#xff0c;加入前端Q技术交流群 本文作者#xff1a;方长_beezen 原文链接#xff1a;https://juejin.cn/post/7358647992608489535 前言 随着软件行业的迅速发展#xff0c;开源项目的重要性已经成为不言而喻的事实。它能够… 点击上方 前端Q关注公众号 回复加群加入前端Q技术交流群 本文作者方长_beezen 原文链接https://juejin.cn/post/7358647992608489535 前言 随着软件行业的迅速发展开源项目的重要性已经成为不言而喻的事实。它能够为开发人员节省大量时间和成本避免重复开发已存在的功能。其次开源项目经过广泛的社区审查和测试具有较高的质量从而降低了开发风险。另外庞大的社区支持和生态系统能够提供及时的技术支持和解决方案。 然而并非所有开源项目都能直接满足企业的特定业务需求。在这种情况下开发者需要对其进行二次开发根据自身需求对特定功能进行修改和优化。传统的二次开发模式是通过 Fork 源码进行的然而这种方式存在一些弊端。一方面对开发人员的专业能力要求较高另一方面容易使开发者与开源社区脱节后续的技术方案可能无法直接使用。 相比之下渐进式开发模式是一种新型的二次开发模式它既能够与社区保持紧密联系又能够直接基于源码进行修改和优化是一种需要掌握的二次开发技巧。 开源项目的神秘面纱 Github 是全球最大的开源项目代码托管平台为开发者提供了协作代码管理和项目托管等服务。很多国内外优秀的开源项目都可以在 Github 上找到例如 Vue、Ant Design、Taro、Nodejs、React、Bun、express.js、Webpack 和 Babel 等等。 这些优秀的开源项目都有一些相同的特点社区活跃度高、项目透明和开放、使用场景较广泛。从 Github 平台数据上也能看到一些共同特点参考如下 Star 数较高代表项目受欢迎程度越高项目质量也可能更高。贡献者数量多反映了项目的活跃程度和社区参与度较高意味着项目的开发和维护工作得到了更多人的关注和参与。提交频率高反映项目的更新速度和活跃程度频率越高意味着项目的开发和维护工作越活跃。问题和拉取多反映项目的开发和维护工作活跃也意味着项目功能特性增加较快。 然而优秀的开源项目也意味着项目工程的复杂度极高面对来自全球各地开发者的代码提交如果没有一个全面且稳定的项目架构是无法做好项目管理和发展的。所以对于开源项目的二次开发主要要面对如下这些难点 理解项目结构和架构对于复杂的开源项目首先需要花费大量的时间和精力去理解项目的结构和架构包括代码组织方式、模块之间的关系、依赖关系等这对于新手来说可能是一个挑战。阅读和理解源代码开源项目的源代码可能包含大量的代码和注释需要开发者具备良好的阅读和理解能力以便理解代码的逻辑和功能找到需要修改或扩展的部分。遵循项目规范和约定开源项目通常有自己的代码风格、命名规范、提交规范等开发者需要遵循这些规范和约定以便保持代码的一致性和可维护性。处理依赖关系和兼容性开源项目可能依赖于其他的开源库或者框架开发者需要处理好这些依赖关系确保项目的稳定性和兼容性。与社区保持同步二次开发并不是一次性的任务随着项目的演进和需求的变化开发者需要不断地维护和更新自己的代码保持与原始项目的同步和一致性 传统的二次开发方式 通过 Fork 某个固定版本并进行后续的迭代开发。 操作步骤 1、在 Github 上 Fork 开源项目到自己的代码仓库。 2、在自己代码仓库中克隆已 Fork 的项目到本地。 3、从 develop 开发分支拉取 feat 特性分支进行代码修改然后提交代码到自己仓库。 4、在 Github 上发起对开源项目的 Pull requests 请求。(可以对开源项目进行贡献)。 5、然后就等开源项目维护者接受merge或者拒绝close你的请求了。 优劣分析 优点 稳定性 团队能够完全掌握特定版本的代码避免因为原项目的更新引入新的问题。可控性 团队可以更自由地管理自己的代码库不受原项目后续更新的干扰。预测性 团队能够更好地预测和计划开发进度因为代码库相对固定。 缺点 滞后性 由于固定版本可能错过原项目后续版本的新功能、性能优化和安全修复。维护成本 长期来看需要团队付出更多的维护成本尤其是当项目规模增大或持续时间较长时。 经历 我们曾基于 Taro v1.3.21 版本进行了 Fork也修复了数百个功能点。我们的业务项目在此基础上运行了两年多编写了大量兼容代码以适配 Taro v1.3.21。然而随着时间推移我们发现业务项目的维护变得越来越困难。 备注 很多国内大公司采用这种方式投入大量人力对代码进行修改从而将其转变为一个全新的项目或产品并将其与原开源项目完全分开。他们之所以能够成功主要是通过投入大量资源深入研究开源项目但对于小团队来说这种任务通常是难以胜任的。 渐进式开发模式 根据大量的实践经验纯粹采用 Fork 固定版本进行二次开发或通过引用的方式持续更新这两种方式都不够可行。我们通过长时间的探索和创新发现将这两种模式结合并结合工程化手段能够更好地应对二次开发的场景我们称这类开发模式为渐进式开发模式。 基本架构 首先我们需要组件基础框架团队开发人员的专业度要求较高他们会持续对开源项目进行调研并选择 Fork 一个稳定的源码版本代号 1.0.0并负责将其推广至业务团队项目中。 业务团队在项目开发过程中发现了 1.0.0 版本上的缺陷基础框架团队则负责在当前版本的源码上进行问题修复并发布一个补丁包暂且称为 xx/patch。然后业务开发人员只需要在项目中添加一个补丁配置 xx/patch并重新安装依赖通过一种工程化手段就可以将补丁代码生效于开源项目中。 另一方面基础框架团队会定期进行开源项目的版本更新比如每六个月进行一次版本调研和升级重新 Fork 一个较新的稳定版本代号 2.0.0并推广到业务团队项目中。对于业务团队而言他们可以按照自己的项目规划有选择性地考虑是否要对框架版本进行升级。 在该模式中有两个关键点需要注意 代码修复与优化策略智能补丁模块替换方案 代码修复与优化 开源项目的问题修复或新增需求我们需要制定一定的管理策略 当前维护版本存在问题但最新的开源版本已修复。此时只需对维护版本进行补丁修复。当前维护版本和最新开源版本都存在问题。我们将对当前维护版本进行补丁修复并提交 Pull RequestPR到开源社区。对于新增需求我们将仅在最新的开源版本上提交 PR。每个需求都必须经过内部审核机制。 在这里我们需要注意维护好补丁包与开源版本源码的关系。建议补丁包的包名与源码包模块保持一致例如tarojs/router:3.6.22 模块存在问题我们的补丁包模块可以命名为 xx/router:3.6.22-patch.1。如果后续还有继续更新可以递增补丁号如 xx/router:3.6.22-patch.2。这样有助于清晰地管理和追踪补丁包与开源版本的对应关系。 智能补丁模块替换 补丁模块替换逻辑主要采用 yarn 包管理工具的 resolutions 能力对于模块下载方式主要有如下三种 从源镜像下载模块在线资源模块本地文件模块 示例如下 resolutions: {tarojs/taro: 3.6.22,tarojs/components: http://patch.xxx.com/components-3.6.22.tgz,tarojs/router: file:./lib/router-3.6.22.tgz
} 在这里我们采用了本地文件加载的方式以方便后续实现资源缓存能力。当开发者在项目根目录下执行 yarn install 命令进行依赖安装时首先会触发 preinstall 勾子提前进行补丁包的资源下载并将补丁配置信息植入到 package.json 文件中的 resolutions 字段。然后在项目依赖安装时将会把配置文件中定义的补丁资源安装到指定的模块中而不会再拉取线上资源。这样我们成功实现了智能替换补丁模块的能力。 package.json 配置文件 // package.json
scripts: {preinstall: node scripts/preinstall.js
},
patch: {xx/patch: 1.0.0
}, preinstall.js 勾子文件 // preinstall.js 勾子模块
const http require(http);
const fs require(fs);
const path require(path);const pkg require(../package.json);
const patchVersion pkg.patch[xx/patch]; // 获取 package.json 中关于补丁包相关信息
const serverUrl https://xx.patch.com?version${patchVersion}; // 补丁资源服务// 发起 HTTP 请求
http.get(serverUrl, (res) {const filePath path.join(__dirname, .patch);const fileStream fs.createWriteStream(filePath);res.pipe(fileStream);// 处理请求完成事件res.on(end, () {const patchConfig require(.patch/config);pkg.resolutions patchConfig.resolutions;// resolutions 配置内容如下// {// tarojs/router: file:${path.join(__dirname, .patch/xx/router-3.6.22-patch.1.tgz)}// }fs.writeFileSync(path.join(__dirname, ../package.json),JSON.stringify(pkg)); // 重新写入 package.json 配置文件});
}); 上述逻辑简要说明了智能补丁的核心流程。我们可以将 preinstall 中的逻辑封装到全局的 CLI 模块中也可以通过在依赖安装完成后触发 postinstall 勾子来移除 package.json 文件中的 resolutions 配置。另外提到的 serverUrl 补丁包下载服务我们不一定需要自己搭建服务可以通过 npm publish 方式将补丁包发布到 npm 镜像源然后通过 https://registry.npmmirror.com/xx/router/-/router-3.6.22-patch.1.tgz 方式进行下载。此外我们还可以提供更多的配置参数以满足更多定制化的需求。 最后 在进行开源项目的二次开发过程中我们还需要重点关注二次开发本身从收集产品需求到验证项目质量和性能一直到最终的方案落地每一个环节都很重要。 值得一提的是二次开发方式各自有优劣选择取决于项目的需求、团队的开发流程和维护能力。 往期推荐 前端框架新势力大盘点 前端开发者必须知道的日常小技巧 TypeScript很麻烦不想使用 最后 欢迎加我微信拉你进技术群长期交流学习...欢迎关注「前端Q」,认真学前端做个专业的技术人... 点个在看支持我吧
