但长期坚持对我来说是一件很难的事情，核心原因可能是没有足够的动力，我应该深刻反思。
我们往往会写一个文档来描述自己的想法，但科学研究表明，很多时候，文字其实并没有那么直观，尤其是在一场会议中，使用大段的文字可能会让观众很容易疲劳，容易走神，GET不到重点等。
所以在文档中插入一些图示，能够帮助观众更好地理解自己的想法，也能更清晰地表达整体的设计思路，是开发者非常值得掌握的一个技能。
下面列几个比较常用的图的分类。
《ThoughtWorks现代企业架构框架白皮书》中，把架构分为了四个层次，分别是业务、应用、数据、技术。
其中最重要的是业务架构，只有梳理清楚了业务，才能指导应用、数据和技术架构，最终支撑业务的快速迭代和发展。业务架构的分析过程是复杂的，最终的产出可能也不仅仅只是一张架构图。还有更细节的流程、建模等产出物。
在实际工作中，笔者其实很少看到以业务视角产出的一张“架构图”，更多的是业务流程图、用例图。看到更多的是“产品架构”和“技术架构”。
一张好的产品架构图大概是这样，分层次、分模块讲清楚了各个产品模块之间的关系。下图是一张大型电商产品的全景图（图片来自人人都是产品经理）。实际上真正运行的系统远不止这些，但核心模块都有所刻画和体现。
作为技术开发人员，在实际工作中往往会有很多时候需要阐明自己的整体技术设计思路。这个时候可能需要一张“技术架构”图，从技术的视角剖析各个模块之间的关系。
我找了好久没有找到好的一个小型业务系统的技术架构图，最终找到一个比较宏观的图，后面有机会自己找业务画一个吧。但大体上的结构是类似的，从最底层的存储，到最上层的接口。右边是一些通用的运维体系或者支撑服务。
传统的UML用例图是用于描述角色和行为之间的关系，用例下面可以再拆分用例（或者叫进一步用例），类似这种：
但用例图只是刻画业务行为，并没有刻画领域模型、单据和领域的划分，所以信息量其实很少。
流程图可以刻画业务的核心流程，也可以在流程图的节点周围画上对应的产品功能、模型或者产生的单据。比如一个典型的流程图（刻画产品功能）：
如果在流程图上再加上“用户角色”，刻画xx角色在xx阶段做了xx操作。就是一张“操作动线”图：
如果不在意色彩等细节的话，时序图非常推荐使用plantUML来画，效率比较高。这个工具我们在后面介绍。
系统链路图，有时候也叫服务链路图。表达的是各个微服务之间的调用关系，一个好的微服务系统调用链路应该是干净的、单向依赖的，呈一个“树状”，但现实中如果设计不好，经常会有循环依赖，形成“图”状。
实际上好一点的基建平台可以根据现有的服务监控体系，自动生成调用链路图，不过在设计阶段肯定是要自己手动画了。
缺点是draw.io是国外的网站，要想流畅使用可能需要科学上网工具。不过由于draw.io是开源的，所以可以下载离线版本的软件，或者部署在自己的服务器上。
processon是一个国内的类似于draw.io的软件，免费版创建文件有数量限制，可以开通会员解除限制。也是web版本可以直接使用。processon的组件没有draw.io丰富，但基本够用。
它也有几个优势。第一个优势就是它是国内的软件，不需要科学上网，就能很流畅地使用。同时它有非常丰富的模板市场，你也可以把自己画得比较好的图发布到模板市场，从中赚取收益。也可以免费或者付费从模板市场克隆一个图，自己在此基础上修改。
processon的第二个优势是它可以团队协作，不过我个人目前还没遇到过需要团队协作画图的场景。
它的第三个优势是可以画思维导图，有点像xmind那种风格。虽然draw.io也能画，但是没有这个用起来方便。
平时我自己因为工作原因，用得比较多的是飞书文档。飞书文档有一个自带的画图工具，有点像draw.io的阉割版，能使用的组件比较少，只有常用的一些通用组件。
但飞书文档内嵌的画图工具最大的好处就是它与文档的无缝集成，可以随时随地直接编辑，不用在文档和画图工具之间切换，目前我大多数的图都是直接在飞书文档上画的。
plantuml是一个可以用代码生成图片的工具，免费的。其实它可以画很多图。包括时序图、类图、用例图等。但整体风格比较朴素，如果要画得很好看的话还是不适合用它。
但是plantuml有一个最大的优势就是效率高。尤其是在画时序图、UML类图等场景，如果用draw.io等工具可能要画很久，但用plantuml可以用几行代码很快画出来。比如：
vscode用plantuml的插件。飞书文档也可以直接插入plantuml，实际使用起来还是蛮方便的。
它也有对应的劣势。比如组件比较少，像图标这些可能要自己通过图片的方式粘贴进去。没有网格和自动吸附，要对齐的话感觉效率会稍微低一点。但是也有分组、对齐和自动分布等常用的工具，所以用熟练了其实也还行。
上面介绍的一些工具，我觉得更多的是“术”层面的东西。真正要画好一张图的核心，还是在“道”的层面要清晰。我总结为两点：清晰的思考和准确的表达。
有些人画图很快，有些人画图很慢。有些人图一次性就画好，后面修改得很少，而有些人会反复修改，怎么都不满意。
这背后其实是你对这个图有没有一个清晰的思考。比如画架构图，需要自己本身对业务和技术有深入的理解，清楚各个模块、层次之间的关系，才能做到胸有成竹，快速利用软件把自己心中的图画出来。
这里有一个小技巧，就是刚开始的时候先画大的模块和框架，不要扣细节。然后在大的模块和框架经过反复推敲确定后，再去完善内部小的细节。这样整个图就不容易在以后被大改了。
同样的架构图，里面可能有些模块比较重要，是自己重点想表达的部分，那这块可以用面积更大、颜色更醒目等方式来表达出来。
同理，一期、二期、三期，内部的、外部的，已有的、将要建设的等等，也可以用不同的颜色来区分，整个图应该是一目了然的把自己想表达的东西表达出来。
想要做好一件事，离不开持续的学习。多看看别人是怎么做的，尤其是优秀的人是怎么做的，是快速掌握一门技能的捷径。
另一个很不错的学习渠道是看看开源框架的官方文档或者源码解读文档。比如spring的架构图、tomcat的架构图、k8s的架构图等。因为文档在开源社区是一个很重要的东西，文档写得好，使用者就能降低理解门槛，快速使用甚至是加入到开源社区中来。很多成熟的开源工具都配有非常优秀的架构图。
稍微大一点的公司应该都有自己内部的知识库。里面有很多别的个人、团队的总结和实践，也是值得参考和学习的对象，看看他们是怎么理解自己的业务，并用技术文档、技术图来表达出来的。
但这里可能涉及到公司安全合规的问题，大家学习的时候要注意规避风险。