架构师对很多人和公司来讲，是一个神秘的职位。他像一个都市传说，很多人听过，但没见过，他存在于每个程序员的脑海中，但形象各不相同。有人觉得架构师就是 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 那么多，似乎没有一个统一的架构理念，但它也同样是前端的一个通用架构实现。有了这些框架，有了通用的架构实现，一般的需求，确实不需要再去设计一套定制化架构了。换句话说，如果你面对的需求和场景比较复杂，还是需要好好考虑，设计架构的。这不仅是前端，客户端、后端其实都一样。
所以前端有架构，只不过可能不需要你每次都自己设计了。