对于广大程序员来说，特别是在大厂，一个根本问题：写代码重要还是写技术文档重要？ 相信大多数的程序员还是干的修修补补的活，大牛的话就另当别论，不需要向上管抄。在各种评审会、培训会、汇报会、甚至批斗会，邀功会、都需要文档能力，甚至大领导或者架构师不会去关心你具体的代码（不代表他们不懂），往更高层次就是要看你的方案和设计。

10年+老程序员的个人观点：

非大牛做程序员玩的就是文档，文档的核心就是架构图。

写文档做汇报，这其中太能体现一个人的真正能力和潜力了，如果能把逻辑文档梳理的很清楚，那么一定写代码很清晰。文档错误百出那对代码的掌控肯定是出问题了。更多时候你跟领导或者架构师的区别就是文档能力，就像那句：能力低的做可以量化的工作，例如代码量；能力高的就做一些不可以量化甚至玄学的工作，例如写一个逼格很高的技术方案或者调研。这算是程序员困境中的一个分水岭，能干活重要，但是能说会道、能写PPT做汇报更加的重要，一句话：证明你的能力比干活更重要，更值钱。

下面分享一点软件架构图经验，大家一起学习

1. 明确利益相关者

首先最重要的问题并不是你的技术多高深，不能钻技术人员的牛角尖。

首先明确：哪些人会看这个架构图（受益者是谁），他们在这个架构图里面想看到那些内容？ 你想要跟这些受益者怎么沟通，达成什么样的共识，怎么容易消除认知的壁垒，怎么创造共同的愿景。

主要受益者应该是直接参与项目的团队（开发人员、测试工程师、业务分析师、软件工程师等）。根据经验，在团队之外，很少有利益相关者真正关心文档。在最好的情况下，他们可能对一两个高级架构图（例如上下文图、应用程序或软件组件图）感兴趣，这些图粗略地描述了系统的结构并提供了高层次的系统视图。

2. 什么是好的架构图

A picture is worth a thousand words （一图胜千言）

• 好的架构图是自解释的，图下面可以有一些细节的描述，其他不需要另外的辅助文字说明。一定要做到架构图能解释的问题比其导致的疑问要少。
• 架构图跟代码之间严格的保持一致性，并且实时更新变动。
• 不要包含过多和无关紧要的细节，一方面受益者不关心一下细节，另一方面细节太多维护困难。
• 需要对图中的方框、形状、边框、线条、颜色等元素进行说明，比如某种颜色表示HAL层等

3. 如何画好架构图

同一篇设计文档，甚至一个系统的所有设计文档的架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。使用标准的建模语言，正确使用其图形元素，这样不需要额外的解释，大家能理解一致，如使用标准的UML，流程图。

对于使用非标准的图形元素，需要加上图例说明，

• 不同的形状表示什么意思？
• 形状的不同边线（实线，虚线，点线）表示什么意思？
• 不同的线条或箭头表示什么意思？ 数据流（同步、异步）， 控制流， 某种关系 （依赖，继承，组合，聚合）
• 不同颜色代表什么意思？ 如非必要说明区分， 尽量只使用黑白色，免得给人带来更多疑问。

在同一个架构图里混杂运行时元素和静态元素：

运行时元素（比如线程、进程、虚拟机、容器、服务、防火墙、数据仓库，等等）不会出现在编译阶段，而且不应该与静态元素（比如组件、包、类）同时出现在同一个架构图里。针对运行时元素有专门的类型图（比如并发图、部署图），一定要注意区别这两种元素，尽可能避免把它们混杂在一起。

“架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。要对系统进行良好的文档化，我们不能只使用一种图表。不过在创建架构图的时候，我们也难以确定该使用哪些类型的架构图以及应该创建多少个。在做出决定之前，我们需要考虑多方面的因素。例如，架构的属性和复杂度、架构师的技能和经验、可用的时间、维护成本，以及利益相关者的关注点。网络工程师可能想看到包含了主机、通信端口和协议的网络模型，数据库管理员更关心如何系统是如何操作、管理和分布数据的。所以，我们要选择最优的架构图数量，不管这个数字是多少。

架构图的好坏，我理解主要是两个方向，一个是需要跳出图本身去看，业务领域的抽象设计合理性，是否符合“高内聚，低耦合”的要求，这个需要回到前文的业务建模、系统建模和抽象过程去寻找答案。另外一个方向是图本身，以下几个点供参考：

• 内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观；
• 图中的信息与相应的抽象级别相关，且满足利益相关者(合作方)的需求；
• 一张好的架构图不需要多余的文字解释！受众有没有准确接收到想传递的信息；如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图；
• 架构图应该帮助每个人看到大局，了解周围的环境，适当的上下文信息；
• 架构图应该避免“只见树木，不见森林”。

4. 架构的本质

这里引用三个观点来探讨架构的本质：

• 架构的本质是为了管理复杂性；
• 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化；
• 架构的本质就是对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。

上述三个观点提到的内容，基本表达了架构的核心目的：管理复杂性，效率最大化。以及架构的两个主要变化来源：一个是以改善软件质量为目的的内在结构性变化；另外一个是以满足客户需求为目的的外在功能性变化。

无论是何种变化，在我看来架构都是在不断的判断和取舍，在业务需求和系统实现之间做权衡，从而来应对未来变化的不确定性，如下图可以比较粗浅直观的表达这种理解。

5. 关于建模

百度百科定义：

建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。

• “把书读厚”：大量的信息输入，同时探求可能性；
• “把书读薄”：归类汇总，形成大图；
• 逻辑对照，确保理解和分析的正确性

业务架构图的核心目的是统一共识、减少沟通成本，无论是项目中的哪个角色大家都能讲一样的话，描述一样的事情。这就是建立对话能力和对话语境，特别是有大量外部客户的时候，一方面体现我们自己专业性很重要，另外一方面这种与客户对话的能力更重要，这也是上文中提到为什么要尽可能用原汁原味的文字去呈现一张图的目的。

6. 架构图示例

架构图的形式不固定，展示的对象也不固定，有时候可能是完全外行的用户，但是有很多好的实践我们可以去借鉴。 参考：https://www.zhihu.com/question/27440059 里面有：

• 整体架构图、
• 逻辑架构图
• 业务架构图
• 应用架构图
• 技术架构图
• 数据架构图
• 部署架构图
• 功能架构图
• 运行架构图

写本篇文章的时候发现，写的细了也不行，其实能懂的看了自然懂，不懂的看了也白搭，要看个人悟性，到具体的一个会议时候的察言观色和应变能力。其实大多数时候就是你周围有一群牛逼的人，自然潜移默化就学会了，不然刻意的学习可能效果也一般。想要高大上，还是需要一个环境，虽然我没去过硅谷，但是一些牛人动不动就谷歌、苹果的技术方案怎么怎么的，的确牛。

画得一手好图也是程序员功力的体现，一定有一些图让你感叹原来如此的清晰，有任何疑问看了这个图都迎刃而解，奉为至宝。