架构或者可以说是一套方法论，让我们知道在什么场合遇到什么问题应该如何解决。

架构师=前端工程师+后端程序员+系统分析人员+关键技术解决方案+各种技术组合+设计模式+部署调整+软技能；

前端架构的原则

在设计前端架构的时候，我认为应该遵守几个基本原则。

第一个是「以不变为中心」。

软件开发的本质就是操作数据，放在 web 开发的场景，后端是存储、获取数据，前端是收集、展示数据。

数据在前、后端流转时，数据的基本形态不会变：基本类型、对象、列表；数据的传输协议也不会变：HTTP、WebSocket。在前端开发中，离它们越远、离 GUI 越近的东西就越容易变。

所以，首先要做的就是梳理出哪些东西是不易变化的，哪些是很容易就变了的。

第二个是「各层皆可替换」。

将根据易变性梳理出的模块按职责进行分层，定义好层与层之间的对接协议（接口）。除了因自身进化需要，对接协议是基本不会变的，也不应去改变。以此为前提，各层实现可在业务需要或技术升级时进行替换。

第三个是「视图层尽可能薄」。

视图层的职责是展示数据，理应只有交互逻辑，而大多数前端在写 UI 组件时会掺杂较多的业务逻辑，使视图层变得很是厚重、臃肿。这样一来，业务逻辑不利于复用，也会增加视图层技术的迁移成本。应将业务逻辑进行抽象，并提取到领域层，让视图层保持纯粹。

由于视图层的易变、多样，并想让它尽可能薄，最好有什么方式能够增加它访问逻辑层的成本，就像前端只能通过网络请求访问后端一样。

忽然想到在做业务开发时有遇到过这种架构，你有印象吗？没错，就是微信小程序！微信小程序的架构是将逻辑层与视图层放到不同的线程中运行，从而做到了天然隔离，它们之间交流的媒介只有「数据」：

微信小程序是建立在客户端应用提供一些原生能力基础之上的，那么在浏览器中能够达到相同或类似的效果吗？当然可以！浏览器提供原生能力，视图层运行在 iframe 中，逻辑层则在 web worker 里：

觉不觉得这很像「微前端」架构——据我理解，简单来说就是一种能够让不同技术栈的模块同时运行在浏览器中，它们可以是组件也可以是应用，并且相互之间能够通信、协同工作的架构模式。

基于这种架构，可以开发出一个类似于浏览器、操作系统的「超级 app」，成为平台级应用。

前端架构师需要什么能力？

我觉得说架构师很空泛，大家会告诉你技术的深度广度，软技能硬技能等等内容。各位无论处于什么阶段的前端，可以对照下面前端能力阶段，找到自己的特征和提升方法。

入门阶段

能够解决一些问题，常见的HTML标签和属性、时间、方法，常见的CSS属性也了解。Js掌握基础，条件，语句和循环，还有简单常用的算法。还了解一些常用工具比如：Webstrom、Sublime text3、Dreamweaver等。

进阶：这个阶段最简单的方法就是找到官方帮助手册，通读所有的方法属性，读到完全理解了，这些手册可以帮助我们夯实基础。最起码优化了我们不规范的代码。

解决问题阶段

这个阶段的前端可以解决一些有难度的问题了，哪怕是复制粘贴，也可以完成布置的所有需求。这个阶段内容不会出错了。

进阶：此阶段最大的特点是能够解决问题了，但不是最佳解决方案。解决这个问题最好的办法就是拓展认知。积累大量的项目经验，比如到GitHub上面找一些开源。

优化方案阶段

本阶段碰到一个需求可以给出各种方案了，自己也讷讷感判断出优秀的方案。这个阶段在团队基本上就是主力了。有个2-3年前端开发经验的基本上都是这个阶段。

进阶：2-3年的工作经验最容易飘。戒骄戒躁，注重前端框架的实现原则、开发、重新配置前端一般终端组件的能力。

拥有全局观的阶段

这个时候思想在需求前面，有的时候需求还没有提出来，我们就有发现的能力。另外这个时候已经不追求最优不最优了，而是解决方案和代码可复用性等。

提升之路：关于面向对象开发的思考；面向对象的JavaScript；javascript闭包、范围链、原型链等高级功能；常用的设计模式；使用本机JavaScript原理实现框架封装；...；基于组件和模块化的发展：SeaJS、RequireJS。有能力解决复杂的问题和技术问题，并能够独立设计和开发复杂的功能模块。

往「架构师」的发展

• 第一是深度：封装概念
• 第二是广度：自称体系，基础扎实，掌握理论，知道原理；