前端架构认知（转载）

没有一种架构是可以满足所有迭代的需求的

前言

是架构设计作为软件生命周期的一部分，并不是说开始的时候设计完成后就会一成不变，软件的生命周期包含了迭代、维护、重构等过程，架构设计亦是如此，所以说架构是需要变化的，目的就是适应当前情况的开发场景。

而架构产生的时间，必定是受到当时的约束条件，如人力、团队技术积累、时间、业务定位等等需求。所以，当前架构可能并不能满足未来的需求，我们要开放对待这个问题，只要当前的架构符合一定的设计原则，未来进行架构的演进就不是问题。

“架构”这个词解释也没有一个明确的定义，每个层级，每个场景都有自己的解释，所以到底什么是架构呢？

软件架构（software architecture），是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
-摘自百度百科

其实软件开发和盖一栋大楼一样，都需要规划、设计、实施等一系列的阶段，最开始设计建筑图纸，主体架构，还要考虑绿化、材料、安全等因素。经过一系列的决策，才有一套成熟的建筑施工方案，按照规范建造，才能保证质量和速度。

而开发一个软件或前端工程也是一个“建筑”的过程,我们要通过业务来定位系统间的关系，讨论技术栈和框架的选用，根据当前团队的技术水平进行技术的选型、考虑各个模块间的界限和交互，上线部署策略，问题回滚策略等一系列的决策才能设计出符合当前情况的技术架构。

大体来看基本要求点如下：

【因地制宜】应该是开始设计架构的基本准则，每套架构的产生都有他的外界因素影响，所以，各个公司，各个团队之间的架构不能照搬，如果强制搬过来，可能会适得其反，就像你那 alibaba 的技术架构去搬到初创公司，那是根本行不通的，人员，资源不匹配，是没办法去实施架构的。

因此我们在项目前端开发的生命周期中期望的架构应该具有哪些要点呢？

设计需要进行一系列的技术及非技术的相关工作

不同的架构师可能会有不同的观点，但是能被人大多数架构师认同的有一下三点

设计过少则为设计不足，会使一个框架的伸缩性和扩展性不强，不能灵活的面对即将产生的业务需求的迭代。设计过度也不一定是件好事，针对未来的技术框架或者需求的变更，我们不能保证目前的架构就一定能兼容这些变化，过度设计反而会让我们一会的架构重构产生很多无用的开发变更，增加成本反而得不到相应的输出价值。

适应环境能够生存下来的物种，并不是那些最强的，也不是最聪明的，而是那些对变化做出快速反映的。 -达尔文

演进事架构是指在开发过程中，预先设计好重要的部分如系统模块通信，功能模块划分，具体组件颗粒度等，然后在编码过程中，再进行细颗粒度的划分，遇到不适合的地方，进行快速的反应，找到最优解，最理想的状态是，20%的计划，80%的演进设计

持续性和演进式有一定的共同性，演进式的目标是在开发过程中进行架构的细化，持续性则指在迭代过程中进行框架的进阶，在迭代过程中，难免会出现架构不符合当前状况的情况，我们要灵活应对，进行持续性的优化，这样才能在迭代开发过程中，做到最优框架的目的

【延迟决策】有时候“拖延症”也并不一定是坏处，哈哈，开个玩笑，在我们设计架构的时候，会经历一系列的方向决策，但是一个框架的发展并不是总是一帆风顺，当遇到演进方向决策的时候，没有找到最优解，我们可以进行延迟决策，等等，也许就会有答案，这样也许会比当时匆忙做出的决定要更符合预期。

不同阶段构成架构的因素是不同的，基于这个思路，架构设计可以分为四个层级

1.系统级

对于其他业务系统，我们该如何设计之间的通信、协作、交互。比如A系统承载了内容库模块，B系统需要用其中的选择内容组件，我们设计了一套csi。去托管通信

2.应用级

应用级是指多个子应用直接的关系设计，可能是子应用，子模块，lib包、共享模块等，也就是架构设计的进一步细化

3.模块级

模块级是深入到子应用的级别的层次，颗粒度更加细化，包含一些设计模式和UI层面的规定，比如，单项还是双向数据流，采用的UI模板，公共css等

4.代码级

代码级的层级用于规范开发人员的代码，提高代码质量，此层次要做的工作有：

架构并不是只限于技术选型