前言
作为工作多年的前端, 最近也开始刷题了, 不管怎样, 算法是程序员的基本功, 既然前端已经被接纳为程序员, 我们也要顺其自然加入刷题大军, 每天练一练, 不为了面试, 纯粹是保持大脑的活性, 这个和将军日常习武差不多, 可能出门打仗没机会出手, 但是武艺不能落下不是, 万一哪天吃了败仗, 不也得贴身肉搏嘛.
正文
好了刷完算法题, 我不得不回到现实世界陷入沉思, 因为我的从业生涯中经常被两个词困扰, 他们就是 框架 / 架构, 没错就是这两货, 除了他们, 另一个让我非常脑阔痛的就是 套接字, 当然我们不在本文中讨论 Socket 和 套接字 翻译合不合适的问题, 我们来讨论下 框架 和 架构 的区别, 关于架构, 我在之前的文章中讲了很多我自己的理解, 其核心主要包括两条
- 内部有边界
- 边界之间形成空间
因此, 从脑补效果来看, 架构像个 田 字, 内部被纵向横向的边界隔开, 形成了一些封闭空间. 那框架呢?
我以前看过一个综艺节目, 叫 梦想改造家 主要讲如何装修改造老房, 里面有一种加固技术我记忆特别深刻
设计师在勘察了老房屋的建筑结构后, 发现其中一个门洞的支撑不是很牢固, 经不起重新装修, 需要加固, 因此设计团队对这个门洞用同等大小的钢材做了一个门框支撑原有的门洞
门框, 框架, 我现在对框架脑补出来的第一个印象是个 门 字. 所以框架和架构是完全不同的两个概念, 框架不是用来制造边界隔离空间的, 框架是用来加固现有架构形成的空间 . 换个说法, 任何一种框架都是为了服务于某种架构而被设计出来的, 在前几篇文章中, 我提到架构师的工作中很重要的一部分是为了维持架构内空间平衡, 保持边界不渗出, 不坍塌, 在这个过程中架构师需要各种工具来完成这项工作, 而框架就是架构师工具箱中最有力和最强大的武器.
以 React 为例, React 是一套 UI框架, 干开发的时候我觉得 React 就是用来开发组件的, 提高我们的开发效率, 所以我对框架的理解就是为了让开发具有一致性, 大家在同一个框架下工作, 尽量避免太大的差异, 同时也能提高效率, 但自从干了架构师, 我发现这么理解过于表象, 和 React 同时诞生的还有 Flux 架构, Facebook 给出了 Flux 架构的解释 "An application architecture for React utilizing a unidirectional data flow." Flux 是一种应用架构, 它将应用看成是数据的集合, 所以这里的 application 的含义并不是我们所理解的那种可见的, 有视觉的应用, 是一种数据应用, 用于处理数据, 而且处理的方式是单向的, 我们可以画个架构图来描述 Flux
Dispatcher 数据传输
-------action------ 边界
Store 数据处理
Flux 的架构很简单, 其包含数据处理和数据分发两部分, 并且以 action 作为数据传输和数据处理的边界, 这里假设你作为架构师, 你觉得 Flux 架构不错, 当前业务确实面临数据流混乱的问题, 因此你将 Flux 架构添加到你的应用架构中去处理数据流问题, 但是你怎么保障这部分子架构的稳定运作, 以便实现将数据流切换到单向的目标呢, 你需要一个框架, 没错, 框架!!
比如 Redux, 架构从某种角度上看是抽象的没有具体的实现, 是一种概念和设计, 而框架则是服务于这种概念和设计, 并将其定义的边界和空间进行强约束和加固的实现, 所以我们评价一个框架合不合适很大程度上在于 框架是否能够实现你的架构设计目标 , 如果不能, 那你可能要审慎的看待是否使用这个框架了.
让我们回到 React, 很显然 Flux 解决了数据流向问题, 数据最终需要呈现出视觉效果, 所以我们可以大胆的推测 React 最早就是为了服务于 Facebook 设计的用于治理内部数据流的应用架构的一个 UI框架. 为此我们可以得到这样的架构图
React Event UI 交互
-----------
Dispatcher
--action--- 数据处理
Store
-----------
React State 视觉呈现
React 其实可以考虑将内部的 Event 事件独立出来, 这样其实在架构设计上边界会更清晰, 大胆预言一波, 说不定后面 React 会考虑这件事情或者新的 UI 框架就是不带事件系统的.
所以 React 引入响应式意味着整个应用架构的重构, 我前面提到过, 重构是一件风险极大的事情, 很容易搞完犊子, 基本上愿意被重构 KPI 的都是 真汉子 , 献上我的膝盖 😀
后话
看着 LeetCode 不断增长的题库, 我陷入了沉思... 这全刷完大概要多久 🤔 ?
