网站建设的频道是什么意思,免费的h5页面制作工具,搜索引擎网站推广定义,南京网站备案前言
去年年中基于若依vue前端框架进行了改造#xff0c;加上后端的配合#xff0c;我写了一套脚手架和项目中后台模板。中后台模板中包含了许多基础代码#xff0c;比如登录/注册、路由、权限等等相关功能。这个中后台模板是基于我们实际开发定制的#xff0c;所以跟通用…前言
去年年中基于若依vue前端框架进行了改造加上后端的配合我写了一套脚手架和项目中后台模板。中后台模板中包含了许多基础代码比如登录/注册、路由、权限等等相关功能。这个中后台模板是基于我们实际开发定制的所以跟通用的中后台模板vue-element-admin还不一样可以认为是快速搭建系统的一种解决方案。
问题
在搭建了多个系统之后我们遇到了点问题。项目模板在前期并不是特定稳定有些功能需要进行调整如果我们需要调整则需要在所有项目都进行手动调整这会变得非常麻烦。随着系统的不断增加这种每个系统都需要手动调整的方案势必会造成大量的资源浪费。所以我们开始讨论如何解决这个问题。
系统架构
在提出正式解决方案之前我先简单介绍一下我们系统架构思路。我们前后端项目都是基于若依系统进行改造的后端是使用Spirng cloud Gateway 将 api 分发到各个项目的微服务中前端则是通过设置请求头来告知当前系统访问的项目。
方案一 – Monorepo
Monorepo – 单体仓库基建方案。将多个开发项目放到一个项目中进行管理的一种手段。这种方案的优势和劣势也是显而易见的
优势 代码重用将变得非常容易由于所有的项目代码都集中于一个代码仓库我们将很容易抽离出各个项目共用的业务组件或工具并通过 TypeScriptLerna 或其他工具进行代码内引用依赖管理将变得非常简单同理由于项目之间的引用路径内化在同一个仓库之中我们很容易追踪当某个项目的代码修改后会影响到其他哪些项目。通过使用一些工具我们将很容易地做到版本依赖管理和版本号自动升级代码重构将变得非常便捷想想究竟是什么在阻止您进行代码重构很多时候原因来自于「不确定性」您不确定对某个项目的修改是否对于其他项目而言是「致命的」出于对未知的恐惧您会倾向于不重构代码这将导致整个项目代码的腐烂度会以惊人的速度增长。而在 monorepo 策略的指导下您能够明确知道您的代码的影响范围并且能够对被影响的项目可以进行统一的测试这会鼓励您不断优化代码它倡导了一种开放透明共享的组织文化这有利于开发者成长代码质量的提升在 monorepo 策略下每个开发者都被鼓励去查看修改他人的代码只要有必要同时也会激起开发者维护代码和编写单元测试的责任心毕竟朋友来访之前我们从不介意自己的房子究竟有多乱这将会形成一种良性的技术氛围从而保障整个组织的代码质量。 劣势 项目粒度的权限管理变得非常复杂无论是 Git 还是其他 VCS 系统在支持 monorepo 策略中项目粒度的权限管理上都没有令人满意的方案这意味着 A 部门的 a 项目若是不想被 B 部门的开发者看到就很难了。好在我们可以将 monorepo 策略实践在「项目级」这个层次上这才是我们这篇文章的主题我们后面会再次明确它新员工的学习成本变高不同于一个项目一个代码仓库这种模式下组织新人只要熟悉特定代码仓库下的代码逻辑在 monorepo 策略下新人可能不得不花更多精力来理清各个代码仓库之间的相互逻辑当然这个成本可以通过新人文档的方式来解决但维护文档的新鲜又需要消耗额外的人力对于公司级别的 monorepo 策略而言需要专门的 VFS 系统自动重构工具的支持设想一下 Google 这样的企业是如何将十亿行的代码存储在一个仓库之中的开发人员每次拉取代码需要等待多久各个项目代码之间又如何实现权限管理敏捷发布任何简单的策略乘以足够的规模量级都会产生一个奇迹不管是好是坏对于中小企业而言如果没有像 GoogleFacebook 这样雄厚的人力资源把所有项目代码放在同一个仓库里这个美好的愿望就只能是个空中楼阁。 从上述引用来看monorepo的劣势对于我们小团队太过于沉重了。第一我们没有足够的人力资源这个问题还不单单在于项目权限的控制更在与我们团队的人员水平和精力 – 是的不得不承认团队水平参差不齐并非所有人都愿意去付诸精力和汗水去学习。第二我们已有的需求并不一定适合这种解决方式。我们的目的是快速搭建各个系统前端并不需要微服务化各个仓库之间没有明确调用关系。第三对于现有系统的改造会很困难。我们每个系统都要重复的功能页面但是我们并不能保证所有的前端页面都是一样的表现形式 – 可能针对某个特殊项目有功能调整。基于这一点我们如果要使用Monorepo的进行代码调整的话我们需要将基础框架与页面、组件进行分离。这个工作量相当庞大我们希望有更加轻量级的解决方案。
方案二 – 插件开发模式
插件开发模式 – 将系统分成shell和runtime模块shell视为宿主runtime视为插件。每个项目都包含shell和runtime两个部分其中shell是包含基础的功能包含开发、打包和基础的框架内容runtime包含了业务相关模块。shell通过读取每个项目的配置文件进行调整shell运行时会加载runtime的相关业务模块。
优势
这种开发方式好处是可以将 基础框架 与 业务开发 进行分离如果后续我们需要升级shell 时就会变得相对简单如果业务本身不需要修改shell的话同时分离还降低了系统开发的复杂程度使常规开发人员只关注业务本身的开发就好了。
劣势
完全剥离框架与业务困难目前的项目模板就是根据业务系统定制的系统模板本身就集成了部分业务模块。但是我们并不能保证已经集成的业务模块不会发生变动或者需要新增一些新的公共业务模块。剥离基础框架和业务并不困难困难的是我们的框架本身包含了公共的业务模块我们无法对这块儿进行较好的处理。短期工作量大难以渐进完成框架杂糅了业务模块如果需要采取插件模式开发对现有的调整框架的调整较大。 一是要划分清楚框架与业务代码对shell和runtime进行分离二是要编写配置模块明确需要读取哪些配置文件三是已有的每个系统都需要按照这种较大的改动的方式去做工作量大。
这确实是一种思路但是我认为它适用的场景是那种 shell 与 runtime 分离比较容易的情况类似于APP或者是小程序开发 – 有一个统一的shell运行各个需要加载的模块降低不同开发人员使用不同的shell导致多个项目合并打包失败的问题。
方案三
物料市场。 物料即组成一个前端项目的不同单位根据抽象粒度的不同我们将物料从小到大分为 组件component、区块block和模板template 。在基于物料体系的开发中我们使用模板物料来初始化前端工程提供最佳实践解决工程问题再使用区块和组件像搭积木一样快速搭建页面。 物料分为 组件component、区块block和模板template 三种类型 组件component组件是组成页面的基本结构单元是对局部交互逻辑的抽象和封装。通常需要设计和暴露属性、插槽、事件和方法等 API。使用者根据这些 API 直接使用一般不需要做二次修改。 从业务维度去看组件又可分为基础组件和业务组件两种 基础组件与业务无关的组件基础组件保持统一的视觉规范考虑高内聚低耦合的设计思想例如 UButton、UInput、UTableView 等在 Vusion 体系官方维护 Cloud UI 基础组件库业务组件面向业务的组件一般功能比较确定可复用同时复杂度较高例如用户选择器、计费卡片等。 区块block区块可以理解为在页面中由一些组件组合而成的代码片段。在一个页面中使用者可以快速把某个区块的代码添加到自身项目里进行二次修改。模板template项目的样板工程包含了完整前端项目所有组成部分包括布局、常用页面、基础插件、工程配置等用户可以快速初始化项目。 我们已有中后台框架模板就是对应到了物料中的模板这块儿。对于我个人而言我更加倾向于采取这种策略原因如下
改造中后台框架调整工作量可控的。根据我们对物料的抽象程度不同我们可以对项目进行不颗粒度划分。举例说明我们将登录页面及其相关功能做成区块那么新的项目就可以直接添加到进去并根据业务要求进行修改。如果是需要调整在将区块下载下来后能做到快速更新的能力。
其他相关优点
最大化资源复用。项目团队成员之间轻松共享。提升迭代上下游协作效率。提升人效比。提升项目中前端开发人员的人效比让前端做的更快、更多、更好能力中台化。支撑业务快速发展。
参考链接 All in one项目级 monorepo 策略最佳实践 什么是物料 物料前端中台建设 从生产到消费设计基于物料的前端开发链路 从业务组件库看前端物料生态 如何建设前端物料平台
