转载声明：文章来源：https://blog.csdn.net/ligang2585116/article/details/103128050

《前端架构：从入门到微前端》

本书围绕前端架构的实施，从基础的架构规范，到如何设计前端架构，再到采用微前端架构拆分复杂的前端应用。

设计：架构设计的模式，以及设计和制定前端工作流

基础：通过深入构建系统、单页面应用原理、前端知识体系等，来构建出完整的前端应用架构体系

实施：通过与代码结构的方式，介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构

微前端：引入6种微前端的概念，以及如何划分、设计微前端应用，并展示了如何实现这6种微前端架构

演进：提出更新、迁移、重构、重写、重新架构等架构演进方式，来帮助开发人员更好地设计演进式架构

本书虽“厚重”，但是内容上并不复杂。比较适合初、中级的前端开发人员或者想了解前端的小伙伴。在此并不想呈现太多的书中内容摘要，而是想通过作者的一些表达来结合自身和自己团队来谈一下观点和想法，特别是在架构方面。

为啥需要架构

长期项目面临的主要挑战是团队的士气、能力的增长以及架构的演进；

短期项目的主要挑战是技术实践与业务进度的冲突。

就我而言，架构带来的直观收益是：减少了大量的重复开发工作以及一些复杂问题的场景化处理。我们可以专注到业务上来，而不必去处理那些复杂的数据流、事件交互等。对于前端而言，业务性和交互越来越重，架构的重要性不言而喻。页面整体渲染 => 结构行为表现分离 => 插件化/模块化 => MVC/MVVM => 组件化。整个发展历程，都是在尽可能的保证职责单一性，来达到复用更高、维护更便捷。

一个老生常谈的话题，前端日新月异，我们如何选择前端框架呢？业务+团队能力+浏览器支持范围+框架星数+社区活跃度+未来切换成本。选择了一个框架，代表接收了一种开发理念和思想，这个至关重要，一定要和自己团队的调调契合。与此同时，选择了一个框架，也不能一味的只用该框架。对于不同的项目，架构和选型，不能一概而论。接收变化、迎接变化、主动变化才能更好的发展。

“大而全还是小而美”，没有标准答案。不要想着一个框架可以满足所有；也不要手里拿个锤子，看啥都是钉子。没有一种架构能满足未来的所有需求。我们要「因地制宜」，一些场景下，jQuery/Bootstrap 依然具有很大的用武之地。对于开发人员来说，要永远坚信：实践出真知！

架构需要些啥

架构需要发展、需要迭代！ 好的架构：20%的计划式设计，80%的演进式设计（只凭一系列的架构蓝图，没有相应的实施规范和原则，便无法按我们预期的方式来实施）。

《Linux/Unix 设计思想》中提及了这样一段：

在背水一战的情况下，设计了第一个系统

专家们在第一个系统的基础上，做出来伟大而臃肿的第二个系统

受累于第二个系统的人，设计出了第三个系统

所以，关于架构的重要决定 – 要延迟决策（在条件充分的时候再做决策），而不是直接拍脑袋。花费大量的时间盲目地修改架构，那样只会造成资源的浪费。

1.不多也不少：不做多余的设计，也不缺少关键的部分

2.演进式：不断地演进以使架构适应当前的环境

3.持续性：长期的架构改进比什么都重要

架构的产生不是一蹴而就，需要过程：架构设计 => 概念验证 PoC（Proof of Concept）=> 迭代0，搭建系统的基础设施。

我们做了哪些

整个公司前端团队20多人，自己团队（平台前端）人数10人左右。两年间、我们经历了大大小小近50个项目。项目的相似度很高，更多的时间大家都在写页面、改bug，每周奔波于多个项目之间。除了劳累，其他收获微乎其微。 因此，对于我们的挑战：

1.和业务关系不大、相同部分如何抽离+维护？

2.业务相关的内容，相同部分如何抽离+维护？

业务关系不大

首当其冲，组件库啊！！！但是组件库的可扩展性、维护成了拦路虎。同时，我们划分不同的前端边界（和业务关系不大）不是一件容易的事。

罗列一下大致内容（看似简单，过程艰辛漫长）：

第一阶段：从项目中抽离了组件库和图表库（两个独立工程、项目中通过 git subtree引用）

第二阶段：对 charts、components 按照组件思路进行改造（merge + extend + template）

第三阶段：建立 Demo 站，为 charts、components 提供开发和展示环境（无特殊诉求无需查看源码）

第四阶段：抽离 charts、components 共同的 utils（独立仓库 git subtree 引用）

第五阶段：通过 yarn workspace 来处理公共依赖（关键点）

第六阶段：解决 charts、components、utils 多仓提交的问题（monorepo）

有了上述组件库的基础上，衍生了可视化大屏生成器。对于我们而言，组件+模式库仍然是一个长期积累过程：风格指南（Style Guide） => UI库 => 设计系统。总之，实现业务是我们的首要任务。技术的发展源于业务；反之也会更好的推动业务发展。业务着眼的是今天或明天，技术放眼未来；商业模式无壁垒，技术才是王道；技术会推动行业变革。

业务相关内容

微前端？目前预演中，对于目前我们思考的点：

业务边界如何划分？

应用的标识化或者注册中心的方式如何考量？

应用通信机制：嵌入业务的特定通信机制 或 剥离业务的通用通信机制？

数据共享机制，两部分：状态 和 应用数据？

应用生命周期如何管理？

综述，人为了逃避真正的思考，愿意做任何事。 最小MVP行动起来才是王道。没有脚踏实地，又哪里来的志存高远。杜绝纸牌屋心理（它可以工作，可我不知道为什么，所以谁也别碰它）。