架构师对许多人和公司来讲，是一个奥秘的职位。他像一个都市传说，许多人听过，但没见过，他存在于每个程序员的脑海中，但形象各不相同。有人觉得架构师便是 PPT 工程师，是半个神笔马良，他担任画图，他人担任把图变成真实的程序；也有人觉得架构师便是资深的程序员，你不用急不用慌，安安分分作业踏踏实实编程，时刻会给你这个 title；也有人觉得架构师便是技能 leader，手下带几号人，不写代码了，天然就成架构师了；当然也有人觉得后端有架构师，要规划杂乱的体系，前端客户端画画 UI，哪有架构可言，天然也不需求架构师。在各个互联网大厂中，也没有『架构师』这个职级，但有各种架构组，而各个架构组实践干的事也跟人们认知中的架构师相同，充满了多样性，他们做的事也就无法用来界说架构。
我 15 年毕业，至今还在写代码，在我有限的职业生涯中，对架构这个词的认知一向在变。本文会聊聊最近的一些主意，趁便会对上面说到的架构刻板印象做一点个人向解读。
什么是架构
架构便是确认体系中模块的界说和划分，以及模块间的依靠关系和交互方法。
咱们习惯给体系分层，实践上是把模块按线性或许树状结构安排起来了。譬如模块 A 依靠 B，B 依靠 C（线性），天然就分了三层；或许 A 依靠 B、C，B、C 分别依靠 D、E 和 F，也分了三层。但在运用这种分层架构的时分，一旦需求比较杂乱，很简单出现跨层依靠、循环依靠等情况，这其实是分层架构的局限性，由于现实中的杂乱体系，模块之间的关系更挨近『图』。咱们能够先规划出一个相似图的结构，再像 dagre 布局算法相同，给这个图去环、分层、同层排序，笼统出一个更整齐的架构。但假如一开始就想用分层架构去套所有的体系，很简单由于实践情况的杂乱导致代码完成和架构规划截然不同，也就失去了架构的意义。
要学软件架构，先学数据结构（:狗头）
架构规划的要点
许多人认为架构规划的方针是提高软件的可保护性和可扩展性，我个人认为这些说法是片面的，架构规划的核心方针应该是如下两点：
- 一是满意需求，当然需求考虑当下的需求和未来的需求。
- 二是提高开发功率，相同需求考虑当下的功率和未来的功率。
所谓的可保护性其实是在未来需求变化的过程中确保软件能顺畅被修正，一向满意需求；而所谓的可扩展性也是为了在未来遇到新需求时能尽量高效地完成，只需求在原有的架构下新增逻辑而不需求改动老代码。这些目标都是面向未来的，这也是许多人在做架构时简单过度规划的根源。过于追求这些目标，很简单把架构搞得很杂乱，导致当下的开发功率很低，而实践上这个体系或许没两个月就下线了，糟蹋许多人力物力。
所以咱们在做架构时有必要平衡当下和未来的需求和功率。举个比如，像我现在在公司担任的低代码引擎，它自身便是一个根底结构，用来出产上层的低代码渠道，在可预见的未来注定会遇到各种新场景和新需求，可扩展性是一个硬性需求，所以咱们运用了一套基于贡献点的架构，哪怕对开发同学来说有必定的认知本钱和上手门槛。但假如是个普通的中后台项目，彻底没必要搞这么杂乱。再从可保护性的视点讲，之前有十来个开发同学保护引擎，所以咱们全体是采用 monorepo 的形式，尽量让每个同学独立保护一个模块，减少交流和保护本钱；但假如这个项目一开始就我一个人保护，并且时刻很紧，假如用 monorepo 便是自找麻烦。所以其实软件架构必定程度上也跟安排架构相关，像微前端这种计划之所以能火，最首要的仍是为了让子模块能够独立部署独立测试，而之所以有这种独立运维的需求，首要仍是同一个渠道或许有好几个不同团队保护。安排架构决议软件架构，从这个视点讲，必定的团队管理经验对架构规划来说是有必要的，这也是有些人印象中架构师便是团队 leader 的原因。
前端有架构吗
讲了这么多，有些朋友会觉得虚头巴脑，咱们做一个业务需求，尤其是前端需求，无非是路由 + 页面 + 组件，最多选一下 ui 结构用 react 仍是 vue，构建用 webpack 仍是 vite，有什么好架构的？
其实也没错。由于结构这个词的语义，自身便是指某个事物的主体或许笼统结构，在软件范畴能够理解为，结构便是已经完成好的一种范畴架构。譬如 react，它尽管一开始自称是一个 ui 库，但它包括明确的模块（页面、组件）界说，以及模块间的结构（树形）、交互方法（单向数据流），加上它周边的生态，它便是 web 开发范畴的一个通用架构完成。vue 当然也相似，尽管故事讲得没有 react 那么多，似乎没有一个统一的架构理念，但它也相同是前端的一个通用架构完成。有了这些结构，有了通用的架构完成，一般的需求，的确不需求再去规划一套定制化架构了。换句话说，假如你面对的需求和场景比较杂乱，仍是需求好好考虑，规划架构的。这不仅是前端，客户端、后端其实都相同。
所以前端有架构，只不过或许不需求你每次都自己规划了。
