共计 2642 个字符，预计需要花费 7 分钟才能阅读完成。
没有一种架构是能够满足所有迭代的需要的
前言
架构并不是只限于技术选型
是架构设计作为软件生命周期的一部分，并不是说开始的时候 设计实现后就会变化无穷，软件的生命周期蕴含了迭代、保护、重构等过程，架构设计亦是如此， 所以说架构是须要变动的，目标就是适应当前情况的开发场景 。
而架构产生的工夫，必然是受到过后的约束条件，如人力、团队技术积攒、工夫、业务定位等等需要。所以，以后架构可能并不能满足将来的需要，咱们要凋谢看待这个问题， 只有以后的架构合乎肯定的设计准则，将来进行架构的演进就不是问题 。
“架构”这个词解释也没有一个明确的定义，每个层级，每个场景都有本人的解释，所以到底什么是架构呢？
软件架构的定义
软件架构（software architecture），是一系列相干的形象模式，用于领导大型软件系统各个方面的设计。- 摘自百度百科
其实软件开发和盖一栋大楼一样，都须要布局、设计、施行等一系列的阶段，最开始设计修建图纸，主体架构，还要思考绿化、资料、平安等因素。通过一系列的决策，才有一套成熟的建筑施工计划，依照标准建造，能力保证质量和速度。
而开发一个软件或前端工程也是一个“修建”的过程, 咱们要通过业务来定位系统间的关系，探讨技术栈和框架的选用，依据以后团队的技术水平进行技术的选型、思考各个模块间的界线和交互，上线部署策略，问题回滚策略等一系列的决策能力设计出合乎当前情况的技术架构。
前端开发过程中须要怎么的架构
大体来看根本要求点如下：
- 合乎以后的业务定位
- 前端架构必须具备可施行性
- 必须匹配以后技术储备
- 有足够的人力资源去实现
- 具备可伸缩、可扩展性
【就地取材】应该是开始设计架构的基本准则，每套架构的产生都有他的外界因素影响，所以，各个公司，各个团队之间的架构不能照搬，如果强制搬过去，可能会事与愿违，就像你那 alibaba 的技术架构去搬到 初创 公司，那是基本行不通的，人员，资源不匹配，是没方法去施行架构的。
因而咱们在我的项目前端开发的生命周期中冀望的架构应该具备哪些要点呢？
- 精确的业务定位，业务可能是影响架构的次要因素之一，所以咱们要找准业务上的定位
- 明确与其余零碎之间的关系，确定与其余零碎的档次关系，相互间的通信依赖等
- 设计好零碎内子模块之间的关系，如 A 业务模块须要与 B 模块交互，该采取怎么的形式
- 根底模块明确，我的项目中，必然含有根底模块去提供一些专用的办法，数据去提供给各个子模块
- 组件布局，这就是再细一层的布局了，制订组件的交互方式，开发范式
- 开发标准和上线流程，用于领导开发中的过程
架构设计 setp
设计须要进行一系列的技术及非技术的相干工作
- 收集利益相关者的需要，产品经理、业务人员、我的项目负责人等
- 与相应技术人员进行探讨，确定架构上的潜在限度和要求
- 寻找可行性的技术计划
- 细化技术计划细节，确定一些性能列表中的技术可行性
- 确定危险点
- 与技术人员重复探讨，汇合大家意见
- 对技术计划进行 demo 的概念验证
- 联合以后业务，细化架构的局部施行细节
- 进行排期
架构设计准则
不同的架构师可能会有不同的观点，然而能被人大多数架构师认同的有一下三点
- 不多也不少：不做多余的设计，也不短少外围局部
设计过少则为设计有余，会使一个框架的伸缩性和扩展性不强，不能灵便的面对行将产生的业务需要的迭代。
设计适度也不肯定是件坏事，针对将来的技术框架或者需要的变更，咱们不能保障目前的架构就肯定能兼容这些变动，适度设计反而会让咱们一会的架构重构产生很多无用的开发变更，减少老本反而得不到相应的输入价值。
- 演进式：一直的演进以架构适应以后的环境
适应环境可能生存下来的物种，并不是那些最强的，也不是最聪慧的，而是那些对变动做出疾速反映的。- 达尔文
演进事架构是指在开发过程中，事后设计好重要的局部如零碎模块通信，功能模块划分，具体组件颗粒度等，而后在编码过程中，再进行细颗粒度的划分，遇到不适宜的中央，进行疾速的反馈，找到最优解，最现实的状态是，20% 的打算，80% 的演进设计
- 持续性：长期的架构的改良
持续性和演进式有肯定的共同性，演进式的指标是在开发过程中进行架构的细化，持续性则指在迭代过程中进行框架的进阶，在迭代过程中，难免会呈现架构不合乎当前状况的状况，咱们要灵便应答，进行持续性的优化，这样能力在迭代开发过程中，做到最优框架的目标
【提早决策】有时候“迁延症”也并不一定是害处，哈哈，开个玩笑，在咱们设计架构的时候，会经验一系列的方向决策，然而一个框架的倒退并不是总是一帆风顺，当遇到演进方向决策的时候，没有找到最优解，咱们能够进行提早决策，等等，兴许就会有答案，这样兴许会比过后匆忙做出的决定要更合乎预期。
前端架构设计的档次
不同阶段形成架构的因素是不同的，基于这个思路，架构设计能够分为四个层级
1. 零碎级
对于其余业务零碎，咱们该如何设计之间的通信、合作、交互。比方 A 零碎承载了内容库模块，B 零碎须要用其中的抉择内容组件，咱们设计了一套 csi。去托管通信
- 对于前后端的服务通信形式。ws or http，鉴权，config 记录等
- 对于报错收集解决的根底信息建设
- 是否采纳微前端等架构
2. 利用级
利用级是指多个子利用间接的关系设计，可能是子利用，子模块，lib 包、共享模块等，也就是架构设计的进一步细化
- 脚手架的设计，能够标准利用的根底，有利于疾速的构建子模块或者子利用，退出一些格式化插件，能够无效的避免一些不符合要求的代码上传到近程仓库
- lib 包设计，能够把一些专用的，细颗粒度，反复利用性高的作为一个 lib 包抽取
- 组件零碎模板，根底组件设计好模板，有利于进步开发效率
3. 模块级
模块级是深刻到子利用的级别的档次，颗粒度更加细化，蕴含一些设计模式和 UI 层面的规定，比方，单项还是双向数据流，采纳的 UI 模板，公共 css 等
4. 代码级
代码级的层级用于标准开发人员的代码，进步代码品质，此档次要做的工作有：
- 初期的开发领导文档
- 开发过程中的 codeReview
- 定期的技术交换分享
- 开发文档或代码正文的生产
【小结】
本文在作为一个引子，先介绍了对于架构的一个认知，简略的阐明了在开发过程中咱们须要怎么的步骤去设计一个架构，以及架构设计中咱们应该留神什么，及架构设计者应该关注的档次，接下来的文章会更深刻的介绍下前端架构
继续更新
- 【来聊一聊前端架构之二】前端架构的落地施行
- 【来聊一聊前端架构之三】构建合乎以后我的项目的架构开发流程
- 【来聊一聊前端架构之四】前端脚手架在我的项目中的利用
- 【来聊一聊前端架构之五】前端架构中组件化的拆分
- 【来聊一聊前端架构之六】微前端架构在我的项目中利用
关注一波哦~
