前言
我是个从小喜欢读史的人, 所以对起源的探究特别感兴趣, 凡事都喜欢找源头, 当然现在网络这么发达, 有时候搜一搜更高效, 我找到了 一篇文章 介绍了架构在历史中的记载, 可见古人很早就用架构来描绘庙堂的结构.

当然作为软件开发人员, 我们谈的架构也往往是软件架构, 但结合架构的一些早期使用, 无论是政治架构, 建筑架构, 还是其他架构, 架构一词的应用非常广泛, 绝非仅限于软件, 故而我一直想弄明白到底什么是架构, 这个词汇如何解释, 能够更合理的, 毕竟我们使用和发明词汇是为了传达某种认知, 而这种认知应当是彼此一致的, 不然就会形成认知偏差, 这种认知偏差在一个广泛的从业人员中传播时会产生各种折射, 导致我们对架构的理解从根本上就很难达成一致, 这也就大大增加了软件架构在实际应用中的复杂性, 而前端架构其实是一个更复杂, 或者极其复杂的领域, 更容易产生认知偏差和折射.

再聊什么是架构

显然从架构可以表达不同领域的含义来看, 架构一定不是一个软件领域的特有词汇, 因此对架构的解释应该具有更高的抽象, 首先从字面来理解, 架构具有很强的可视性, 谈到这个词, 我们第一个反应的画面应该是类似铁架子, 或者毛坯的水泥建筑, 所以我想从词汇传达的角度讲, 知道这个词的人都应该有一种一致的理解, 架构是由各种边边框框隔开的 , 要验证这个说法, 我们可以套在各种领域词汇上, 比如政治架构是由各种政治边边框框隔开的的, 建筑架构是由各种材料边边框框隔开的, 软件架构是由各种软件边边框框隔开的.

似乎没什么毛病, 让我们提炼下边边框框, 比如用边界来代替, 于是可以试着得到一个关于架构的普适性的含义 某种事务内部有各种各样的边界, 这些边界形成了某种空间隔离

故而架构应包含两个要素

• 架构内部边界

• 这些边界隔离产生的空间

既然架构代表的是一种事物, 那应当也具有诞生, 发展, 消亡这三个阶段. 我们都希望事物的发展越来越好, 最好不要消亡, 因此有医生维护你的健康, 有科学家研究如何延长生命, 有健身教练指导你如何保持好身体, 这一切都在尽可能避免我们自身走向消亡, 所以生命都是趋利避害, 都是厌恶消亡的, 人类社会的分工也是为了让人类社会更好的发展, 避免走到消亡这个阶段, 所以为了让架构诞生, 发展, 尽可能延长到消亡的时间, 需要人为的干涉, 从事这份工作的人是 架构师

为了尽快回到我们讨论的领域, 我们就不对架构师展开讨论了, 让我们做个限定, 软件架构师

软件架构师

当我们对架构的理解达成一致, 再加上软件这个词就容易理解得多, 软件架构师负责设计软件架构并落地, 这个是诞生的阶段, 然后要维护这个架构进入发展阶段, 最后要为软件架构进入消亡阶段做好准备, 有时候我们可以主动消亡, 而不是被动的因为软件架构无法维护被动消亡, 那样会带来更多的不确定风险, 因此我们对于一个好的, 优秀的软件架构师的认识大致集中在这几点上

• 能设计, 并落地某种软件架构

• 在发展阶段尽可能延长架构的寿命, 同时要确保架构不会因为内部的不稳定而被动消亡

• 能识别架构的消亡到来, 能控制架构进入主动消亡

因为我们讨论的是前端架构, 所以就不在展开软件架构, 避免篇幅过长, 让我们聚焦一下

前端架构师

我并没有使用前端软件架构师这样一个概念, 是因为我认为前端架构并不是软件架构的子集, 随着时代发展, 前端架构其实可以算一种新的领域, 但是不是有了前端架构师才算是有了前端架构呢? 其实不然.

就像我们自己, 有时候没有医生,健身教练, 没有科学家, 你也能活到 100岁, 可见生命架构有天然的稳定性, 即使在没有人为介入的情况下它依然能很好的发展, 前端领域其实也类似, 很多时候对于一些小型团队或者小项目, 因为我们使用了标准化的开发手段, 比如你使用 JavaScript开发, 其实内部有 JavaScript 的语言架构来保障你的代码稳定性, 如果你使用了 webpack 用来构建打包, 那 webpack 内部基于事件的打包架构其实能保证你在构建上具有稳定性, 所以看, 其实我们用的很多技术天然有其内部架构, 而你的项目即便只是有这些架构堆砌而成, 但是因为项目本身不够复杂, 团队规模不大, 所以他们能保持天然的稳定, 不需要架构师的人为介入, 项目就能发展的很好.

所以正如我 2年前抛出的概念, 前端架构师是前端项目发展到一定阶段诞生的职责需求, 如果你所处的前端团队有这些问题某几项, 可能就是在呼唤前端架构师

• 代码日益增长, 看不懂的, 莫名其妙的代码越来越多

• 需求越来越改不动, Bug 越来越难修

• 性能日益下降, 产品体验越来越差

• Git 越来越容易发生冲突, 且不太好解决

• 需求越积越多, 加班越来越重, 头越来越秃

• 产品, 后端, 设计, 运维, 运营, 沟通越来越费劲

• 开发过程中经常被打断, 记忆力越来越差

你可以把前端架构映射到铁架子上, 上面提到的这些问题, 其实就是整个铁架子内部的铁杆要么生锈松动, 要么破漏, 不同空间内的东西, 开始渗漏, 当然前端架构比铁架子复杂多了, 所以一旦发生这种情况我称之为 边界渗出 , 一个架构从设计到落地, 进入发展阶段, 在没有人为干预的情况下, 一定会发生边界渗出, 这本身难以避免, 是事物的自然规律, 当边界渗出到一定阶段, 会导致架构中的边界坍塌, 随后一个边界坍塌压垮另一个边界, 最终整个架构进入消亡阶段. 所以做为前端架构师, 我们应当接受一个概念 没有万能的架构, 再漂亮的架构最终也会消亡 , 说到这里, 不得不提另一个概念 "重构" , 我对重构的理解其实是在架构进入消亡阶段前, 我们人为的认为当前架构即将进入消亡, 无法继续通过人为手段保障其发展, 所以通过重构, 将现有架构变成另一种架构来重启发展阶段继而延长架构的寿命, 但重构是破坏性的, 重构同时是基于现有架构的, 一个架构是否适合重构, 要看这个架构内部的边界渗出情况有多严重, 如果一个架构内部大量边界已经开始渗出, 其实是不适合再重构了, 因为很可能重构会导致坍塌继而彻底消亡, 这时候相对有效的手段应该是先解决边界渗出的问题, 加固现有架构, 在相对牢固的基础上再进行重构从而延续架构的寿命

就拿 React 来说, 在 15 之前的架构设计中, UI 渲染带来的压力, 就导致了 React 内部架构中递归处理这部分产生了边界渗出, 当然 15版本也远未到消亡阶段, 但是作为前端圈顶级的开发团队, 自然早早就开始规划重构的方案, 在 15版本还没有出现更大边界渗出 Fiber 就被提上了日程. 假设如果 React 是一个业务团队, 要做需求, 在巨大业务压力下进行重构其实就是件高风险的事情, 因为很有可能一个不小心, Fiber 还没搞定, React 内部就先搞坍塌了. 所以一般为了确保基础架构团队能够避免被业务压垮, 通常不会把边界设置在基础架构和业务之间, 但我在实际的了解中, 很多公司都让基础架构做一些业务上的事情, 或者让业务团队做一些基础架构上的事情, 从常规来看似乎很有道理, 考虑产出啊, 考虑成本啊等等, 但是这么做其实会给基础架构的发展增加额外的压力, 这个压力极有可能摧毁现有架构, 同时对基础架构的架构师的工作也增加了难度, 为了确保基础架构的平稳发展, 他需要考虑基础架构和业务之间的边界, 同时在这个边界上构建平衡, 为了取得平衡, 架构师必须关注基础架构和业务线之间的多个方面, 包括

• 研发流程, 基础架构如何保障需求的按时交付

• 基础架构团队内部对于需求交付和基础架构研发的精力分配

• 对业务方提前至少 6个月的规划了解, 考虑做一些前瞻性设计, 来保障现有架构的发展不受影响, 同时对业务形成有效支撑

可以看到, 一旦将基础架构放在一个具有业务属性上的团队就会面临业务上的压力, 这种压力对基础架构是一种额外的挑战, 如果架构师不能意识到这一点, 必然会导致不可控的边界渗出, 就好比房屋漏水并不可怕, 可怕的是我们并不知道存在漏水, 比如吊顶 , 未被识别的边界渗出可能会成为压垮架构的最后一根稻草.

那如果把基础架构和业务完全隔离呢?

就像上面说的, 没有万能的架构, 这里提到的基础架构, 其实是组织架构的一部分, 通过组织架构上的边界来确保基础架构不会被业务带来的压力导致边界渗出, 但这样会带来新的问题, 用图来说明下

<pre class="prettyprint hljs lua" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 1.5em; font-size: 14px; line-height: 1.5em; word-break: break-all; word-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> `业务线 业务线
------- =====> ------
基础架构 业务研发团队

基础架构 复制代码`</pre>

可以看到为了让基础架构不被业务压力渗透, 组织架构上增加了一级, 同时边界变成了两条, 但是作为基础架构的架构师, 从原有的一条大边界变成了 2条小边界, 作为基础架构的架构师, 虽然不再直面业务压力, 也不用考虑精力分配问题, 但是如果业务研发团队的边界没有保持好平衡, 这其实是很容易发生的情况, 业务研发团队没有架构师, 本身的架构平衡在业务线的压力下很容易导致边界渗出, 但这时候作为基础架构的架构师, 因为隔着一层边界, 其实你并不容易发现这一点, 或者也很难发现, 这个渗出点就像是吊顶中的漏水点, 等到渗出到基础架构的时候, 可能为时已晚, 为了避免这种情况

• 业务研发团队需要配置架构师, 来维持边界平衡,

• 同时 2名架构师之间要有通常的同步机制, 随时对边界的情况进行同步

• 架构师要有一致的架构理解和认知, 避免认知差异导致的信息无法有效同步

同时我们知道边界的压力是来自对冲的, 所以业务研发团队同样面临着来自基础架构的压力, 彼此的边界如果无法构建平衡, 也非常容易导致边界渗出, 这对业务研发团队的架构师带来了更复杂的挑战

• 如何保持业务研发和基础架构的边界平衡

• 基础架构势必要在业务研发落地, 如何不让这种落地破坏边界平衡

很有挑战不是么, 架构工作比一般的普通需求开发其实复杂的多, 对架构师的视野, 全局性, 前瞻性, 技术工具箱的完备性要求都非常高

后话