前言

你是否曾经苦恼于写不好文档, 写不好文章, 明明说得很溜, 但是一到动笔写字的时候就歇菜, 或者写的一手好文, 文档也写得很溜, 但是老板让你画图, 你就蒙圈, 不知从何下手? 如果是, 往下看, 如果不是, 也往下看.

这个世界是有等级的, 任何人都离不开三六九等之分, 抛开不公平因素, 在理想环境下, 人的等级主要由思考能力来决定, 简单的说, 不思考你可以从事体力活动, 如果你都懒得动, 那可以乞讨, 即一动不动, 但是如果你思考的是宇宙的诞生于发展, 那你所处的等级就非常之高, 比如爱因斯坦, 或者你思考的是国家如何发展, 民族的未来, 比如国家领导人(川建国同志除外)

这里的等级不等于阶级, 用更普世的概念看更像是一种人类社会的行为分级

聚焦到我们这个行业其实也是一样的, 比如大多数普通工程师的特征是关于技术, 会说不会写, 从事搬砖打杂高强度重复编码的工作, 俗称 CV工程师, 高级一点的会说会写但不会画图, 一般是团队的核心骨干, 资深或者高级开发, 再往上就是团队的灵魂人物会说会写会画图, 主要以架构师, 技术Leader, 技术专家为代表.

说, 写, 画其实都是一种信息流生产的手段, 而思考等级对应的就是我们在不同等级的思考框架下对信息流进行生产和消费, 无论是不会说还是不会写还是不会画都是缺少对应的思考框架所致

正文

思考框架

我们以已经大路货的 React 协调算法的原理为例, 我相信大多数读者在面试的时候, 如果面试官问你这个问题, 基本都能说上两句, 比如 key 的作用, 同层比较, 或者扯上 Fiber, 虚拟堆栈, 单链表, 两颗树的遍历等等.

但是有意思的是, 如果让你写一篇文章把 React 协调算法说清楚, 大部分人都会陷入挠头皮的困境, 如果更进一步, 让你进一步用图来描述 React 协调算法的技术架构, 可能 99%的人头皮都要挠秃了.

所以 Why? 为什么会这样?

因为大部分人的大脑里只有说这一种行为的思考框架, 而缺少写和画的思考框架, 由于我们从出生开始就接受说这种行为的长期练习, 从小学到大学, 关于说, 如何说, 怎么说我想你已经练习和思考了十几年, 这十几年大部分人拥有了不假思索的表达能力, 当你学习或者接受了某些信息, 能非常自然的说出来, 这就是思考框架赋予你的能力, 对消费旧的信息, 并快速的生产新的信息

信息 → 思考框架 → 说

但是写作和画图却不是我们从小练习的能力, 自然也没有对应的思考框架存在大脑里, 并且在进入社会之后, 也没有像上学那时候一样, 有理论和实践来帮助你练习和建立这两种思考框架, 自然也就缺乏这两种能力

所以何谓思考框架, 思考框架就是经过刻意练习使用特定的能力去消费和生产信息从而产生的固定的思维方式

回到画架构图这件事

看了上面这些内容, 我想你应该了解到架构图画不好的原因其实在于, 相比说和写, 画图对信息的消费和生产手段过于抽象, 并且需要对信息大幅度凝练, 这种要求也导致了思考的难度急剧上升, 所以如果说写技术文档大多数人还能胜任, 但是画架构图就只是少数人的专长了, 原因就在于真的很难

但是虽然难还是有些技巧的, 这些技巧有助于降低你思考的难度

技巧一不要试图在一张图上表达两种不同的信息流

当我们说和写的时候其实是不受空间, 时间等维度限制的, 因此你可以表达非常复杂的信息流, 比如过去和现在, 或者完全不同的东西, 对你来说只是停顿下喝口水, 或者另起一行换个标题, 但是架构图就不行, 因为架构图是在一个平面上并且空间是有限的, 当我们看到平面图的时候, 人的理解能力就被天然限制在了单一维度上, 即你无法用一张平面的架构图同时说明两个不同维度的信息, 通俗点讲, 你只能用图说明一件事, 要么是业务, 要么是技术, 要么是某个流程, 这是和说和写极大的区别.

技巧二学习和使用固定的思考框架

如果你学过软件工程, 应该了解过 UML图, UML 就是一种用于描述面向对象语言的特定的思考框架, 在给定的限制下, 你思考的范围和关注点都高度聚焦, 大大降低了思考难度, 但比较不幸的是, 对于前端领域 UML 基本没啥卵用, 但是你可以通过了解 UML 来找那种带着思考框架思考的感觉, 从而帮助自己建立属于自己的思考框架.

我自己总结的常用的架构图思考框架

经过多年画图的刻意练习, 我总结了作为前端架构师经常用到的三种图, 并附上背后的思考框架

每个人的思考框架不会完全相同, 但是大同小异, 你了解或者知晓某种思考框架有助于你去针对性的练习和思考, 但最终能不能变成你自己的, 这不一定, 但你不练, 你永远都不会有这个能力.

业务架构图和思考框架

做工程, 做架构首先要了解业务, 从业务推导技术架构这是一个固有流程, 所以在这一点上不需要怀疑, 你必须先了解业务才能开始设计技术架构, 你牢记这条即可, 同理想要画好技术架构图, 就必须先能画出业务架构图, 关于业务架构图我的思考框架差不多是这样的

业务类型

一线业务, 直接面向用户, 需求灵活, 不稳定, 变化快
横向业务, 对多个不同的一线业务进行提炼形成的业务
纵向业务, 公共业务, 为一线和横向业务提供业务支持

业务成熟度

创新
成长
成熟
停滞
衰退

图示例

对于不同类型的业务在技术架构上的设计也是有区别的, 再加上成熟度的思考, 在权衡和实施节奏以及采用的技术和工具手段等都会有更进一步的考量, 这里不做展开, 有兴趣的可以直接找我交流哈, 后续也会写相关的文章来说说 如何从业务架构推导技术架构

技术架构图和思考框架

技术架构图一般是用来描述我们是如何使用技术手段系统性的解决某类业务问题, 这两天我一直在深入学习 webpack, 并且也试图画出 webpack 的技术架构图, 以下是一张未完成的架构图, 先不讨论其中细节和正确与否, 从图上可以看出, 我试图通过 webpack 的技术架构图来说明 webpack 解决的业务问题是对 JavaScript Code 进行构建打包并运行的过程

因此我总结的技术架构图的思考框架是

技术架构包含一种以上的状态, 且无法兼容, 包括但不限于
- 开发时
- 运行时
- 编译时
- ...时
技术架构包含一种以上的技术素材, 同一张图只能说明同一抽象维度的素材 (这句可能不是很好理解, 我举个栗子, 图上你可以绘制 JavaScript Code 的流程和 Css Code 的流程, 但是你不能在一张图同时画 Code 和 JavaScript Code 的流程, 因为两者的抽象维度不同, 试图进行作画会非常难受而且不易理解)

生产消费流程图和思考框架

生产消费流程图我主要用来说明信息流在不同角色, 不同系统之间被消费和被生产的过程, 往往用来定义系统的边界, 比如这张图, 图结构类似泳道图

生产消费流程图的思考框架

每一张图应该具有唯一的生产消费源
边界和边界之间是不同的角色
图例应围绕该角色围绕如何消费源, 并生产源, 具有链性.

后话

文章结尾让我们来点个题, 为什么你画不好架构图?

缺乏有针对性的刻意练习
没有建立自己的思考框架
~~没读我的文章 😀~~
认为画图不是个重要技能, 其实反映的是你缺乏对更高思考等级的追求和理解.

最后的最后, 为啥说架构设计要追求简洁美 因为架构图本身是高度抽象且不复杂的, 复杂的图往往是有问题的