本文探讨了画图对于技术人员的重要性，特别是在沟通、分享和表达设计思路时。文章介绍了不同类型的图，如架构图、用例图、时序图等，并推荐了几款画图工具，如draw.io、process on、plant uml和excalidraw。作者强调画好图的核心在于清晰的思考和准确的表达，并建议通过学习优秀案例来提升画图技能。
点击↑上方↑蓝色“编了个程”关注我~
这是Yasin的第 75 篇原创文章
Y说
好久没写技术文章了，最近也不知道自己一天在忙啥，感觉很忙，但也没什么产出。这篇文章从周一开始准备写，中间大概断断续续写了三次，终于在周六写完了。
其实自己有很多东西想写的，但是平时下了班之后就只想躺着，根本不想动脑。早上有时候又起得比较晚，所以没有太多的时间写东西。感觉可能还是作息不规律的原因，如果能一直坚持早睡早起可能会好一点，早上的思维比较清醒一点。
但长期坚持对我来说是一件很难的事情，核心原因可能是没有足够的动力，我应该深刻反思。
为什么要写这篇文章，是因为自己以前觉得会画图是一件很简单的事情，甚至有点鄙视那种只会画图，不写代码的“资深程序员”。但后来慢慢才发现，想要画好一张图其实也不是一件容易的事情，而且画图有时候真的比写代码重要，它是值得深入学习和掌握的一个技能。
为什么要画图
作为一个技术人员，在很多场合可能会与别人沟通或者交流自己的架构设计、规划等思路，比如在分享、答辩、沟通需求等场景。
我们往往会写一个文档来描述自己的想法，但科学研究表明，很多时候，文字其实并没有那么直观，尤其是在一场会议中，使用大段的文字可能会让观众很容易疲劳，容易走神，GET不到重点等。
所以在文档中插入一些图示，能够帮助观众更好地理解自己的想法，也能更清晰地表达整体的设计思路，是开发者非常值得掌握的一个技能。
图的分类
下面列几个比较常用的图的分类。
架构图
《ThoughtWorks现代企业架构框架白皮书》中，把架构分为了四个层次，分别是业务、应用、数据、技术。
其中最重要的是业务架构，只有梳理清楚了业务，才能指导应用、数据和技术架构，最终支撑业务的快速迭代和发展。业务架构的分析过程是复杂的，最终的产出可能也不仅仅只是一张架构图。还有更细节的流程、建模等产出物。
在实际工作中，笔者其实很少看到以业务视角产出的一张“架构图”，更多的是业务流程图、用例图。看到更多的是“产品架构”和“技术架构”。
一张好的产品架构图大概是这样，分层次、分模块讲清楚了各个产品模块之间的关系。下图
最低0.47元/天 解锁文章
扫一扫
8962
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
