文章31画图一图胜千言.pdfVIP

2018/10/12 极客时间 | 程序员进阶攻略 讲堂 程序员进阶攻略 文章详情 31 | 画图：一图胜千言 2018-10-12 胡峰 31 | 画图：一图胜千言 朗读人：刘飞 09′41′′ | 4.45M 对于写作这种展现形式，有一种最好的补充手段就是画图。有时文字描述了半天还不如一张图来 得清晰，正所谓：一图胜千言。这对于程序员特别需要的技术性文档或文章写作，都是最好的补 充注解，有时甚至起到了画龙点睛的效果。 以前我在网上发一些技术博文，就常有读者留言问我是用什么工具画图的。其实我感觉他们很可 能问错了问题，因为我曾经为了画好图尝试过各种不同的画图工具软件，但最后发现能不能画好 图和工具的关系并不大。 一、为何？ 程序员不是主要写代码的么，为什么需要画图？ 有些程序员会认为写好代码就好，画好图有什么用？程序员成为架构师后是不是就天天画架构 图，成为了所谓的 PPT 架构师？曾经读过一篇文章《在首席架构师眼里，架构的本质是…》， 里面提出了一个架构师能力模型图，（我重新绘制）如下： /column/article/41571 1/5 2018/10/12 极客时间 | 程序员进阶攻略 架构师能力模型图 结合我自己的经历和经验，这个能力模型针对架构师这个岗位来说还是比较符合的。程序员出色 到了一定程度后想成长为一名架构师，就需要看看能力模型中的其他方面。而掌握好画图技法， 对这个能力模型有什么帮助吗？ 前面讲系统设计的文章《 与视图》中我已经给出过结论：“用更系统化的视图去观察和思 考，想必也会让你得到更成体系化的系统设计。” 在今天这个时代，我们都体验过各种各样的地图软件，一个国家，一个城市，一个街区，地图软 件总是在不同的抽象维度上来展示地图。而对于一个复杂的软件系统，也需要类似的不同抽象维 度：系统的全貌、不同子系统间的关联和交互、子系统内部模块间的接口和调用、某个关键实现 点的处理流程等。一个架构师应该可以在这些不同的抽象维度上把系统或系统的一部分清晰地描 绘出来。 而画图对于能力模型中的 “抽象思维” 就起到了一种锻炼，其作用就是帮助你在不同的层次上 去思考系统设计，并具象化这个设计。既然具象化了设计，那么再基于此去沟通交流自是事半功 倍。成为架构师之后，你自己明白还不是主要的，要让别人明白才更重要。 此外，站在一个多层次、全方位的系统架构图面前，在不同抽象维度上描绘了系统的各个重要方 面，想必更容易看到问题的本质，也能更好地发现和找到系统的症结。如果解决系统的问题就像 走迷宫，那么你是直接钻进去反复尝试寻找出路，还是站在更高的维度去俯视迷宫然后再找最佳 的问题解决路径呢？ 想必在更宏观和全局的视野下，与系统所有相关人员进行清晰准确地交流，直击问题本质，那么 再进行正确而适当的技术决策与平衡取舍也没那么难了，对吧？至于 “多领域知识” 和 “技术 前瞻性” 这两方面好像确实和画图的关联性不强，但如果“多领域知识”不限于程序技术领 域，那画图也算一个领域的知识吧。 二、如何？ 上一节探讨了画好图有什么益处，这一节我们看下如何画好图？画一个清晰易懂的技术架构或交 互流程的说明图例需要什么专门的绘图知识与技巧么？另外为了画好图会花费大量的时间么？ 过去几年在关于如何画好图这个课题上，我做了好些摸索和实践，想取得效率（即，画图花费的 时间不会比用文字来描述同样的内容更多）和效果（即，图例表达的效果应该比文字描述更好） 的平衡，在这个过程中我收获了下面一些基本认知和感觉还不错的实践方式。 1. 图形 我画技术图例时只会使用一些最基础的图形，比如：矩形、圆、三角、菱形、气泡、箭头，这些 最基本的图形几乎所有的画图软件都会自带的，所以工具的依赖性很低，但真正画时的操作效率 /column/article/41571 2/5 2018/10/12 极客时间 |