适合程序员的画图技法，再也不是“PPT”架构师

程序员不是写代码的么，为何须要画图？不少程序员会认为写好代码就好，画好图有什么用？程序员成为架构师后是否是就每天画架构图，成为了所谓的 PPT 架构师？如上这些疑问，好几年前也曾让我困惑过。

在一篇文章《在首席架构师眼里，架构的本质是...》提到了一个架构师能力模型（下图），结合我本身的经历和经验，这个能力模型针对架构师这个岗位来讲仍是比较符合的。

 

一个程序员作了不少项目，写了多年代码逐步成长为一名出色的程序员。从上面的能力图中能够看出，一个出色的程序员离一个架构师还差好多其余方面的能力。咱们之前觉得程序员积累了足够经验就会天然成长为一名架构师，但其实架构师并非程序员天然成长的一个延续，只是由于架构师的工做相对管理岗而言离程序员和技术更近，因此咱们对它产生了这样的错觉。不断在「出色的程序员」这块领地内不断的耕耘和出色下去会让你成为该垂直领域内的技术专家，这才是程序员天然成长的延续。

于是，程序员出色到了必定程度后想成长为一名架构师，就须要看看能力模型中的其余方面。而掌握好画图技法，我觉着至少对其中的抽象思惟、沟通交流、平衡取舍与透过问题看本质都有帮助。至于多领域知识和技术前瞻性这两方面好像确实和画图的关联性不强，但若是多领域知识不限于程序技术领域，画图也算一个领域的知识吧。

今天这个时代的地图软件咱们都用过，一个国家、一个城市、一个街区，地图软件老是在不一样的抽象维度上来展现地图。而对于一个复杂的软件系统，也须要相似的不一样抽象维度，系统的全貌，不一样子系统间的关联和交互，子系统内部模块间的接口和调用，某个关键实现点的处理流程。一个架构师应该能够在这些不一样的抽象维度上把系统或系统的一部分清晰地描绘出来。

当在不一样抽象维度上描绘了系统的各个重要方面，咱们才能够更好的发现和找到系统的症结。若是解决系统的问题就像走迷宫，你是直接钻进去反复尝试寻找出路，仍是站在更高的维度俯视迷宫再找到最佳的问题解决路径。这就是透过问题看本质领域一个方面的体现。

关于沟通交流，俗话说，有图有真相，哦，不对，是一图胜千言。有些程序员写技术文档啪啦啪啦的写一大堆，有时真不如一张清晰的架构图或交互图让人更快速清晰的理解到。在对系统有了抽象全面的多维度呈现，清晰准确的交流，直击了问题本质，那么正确而适当的平衡取舍也没那么难了，对吧。

如何？

上一节探讨了画好图会带来什么样的收益，这一节咱们看下如何画好图？画一个清晰易懂的技术架构或交互流程的说明图例须要什么专门的绘图知识与技巧么？另外为了画好图会花费大量的时间么？

在过去几年关于如何画好图这个课题上我作了好些摸索和实践，想取得效率（画图花费的时间不会多于比用文字来描述一样的内容更多）和效果（图例表达的效果应该比文字描述更好）的平衡，在这个过程当中收获了下面一些基本认知和自我感受还不错的实践方式。

图形

我画技术图例时只会使用一些最基础的图形，好比：矩形、圆、三角、菱形、气泡、箭头，这些最基本的图形几乎全部的画图软件都会自带的，因此工具的依赖性很低，但选择的效率很高。固然若是有时为了表达和一些著名外部系统间的交互，这些著名外部系统可能都有各自著名的 Logo 图标，也会直接使用它们的 Logo 图标。

像下面图示，就是我经常使用的一些画图图形元素。

 

颜色

有时系统的组成比较复杂，只用基本图形不足以表达全部不一样的系统组成部件，这时就须要用颜色来区分了。那么下一个问题就来了，该用哪些颜色呢？个人答案是使用大部分人以为美的颜色。那大部分人喜欢什么颜色呢？固然我没有做过任何调查，全凭脑壳拍的。我以为大部分会以为彩虹是美的，因此我通常用得颜色就是彩虹七色外加两种经典色：黑、白。这样就有九种颜色加上几种基本图形，能够组合出几十种表达不一样组件的图形元素，基本够用了。

彩虹七色包括：红、橙、黄、绿、青、蓝、紫。但七种颜色的选择也是有优先级，在一本讲设计的书中 Designing with the Mind in Mind （中文译名《认知与设计》，其实我以为译名没有原名那么的有感受）提出了下面一些色彩使用准则：

使用饱和度、亮度以及色相区分颜色，确保颜色的高反差，由于人的视觉是为边缘反差而优化的。

使用独特的颜色，由于人最容易区分的颜色包括：红、绿、黄、蓝、白和黑。

避免使用色盲没法区分的颜色对，好比：深红－黑，深红－深绿，蓝色－紫色，浅绿－白色。

使用颜色以外的其余提示，对有颜色视觉障碍的人友好，并且也加强了可理解性。

避免强烈的对抗色，好比：红黑，黄黑

因此你看为何交通灯是：红、黄、绿。为何乔布斯选择这三个颜色做为 Mac OS X 操做系统中全部应用窗体的按纽颜色，这也是暗合人类的视觉认知原则的。因此我如今多选择是白底、黑字、黑色线条、色块优先选择：红、绿、黄、蓝，实在不够用了才会选择：橙、青、紫。

固然红有好多种红，绿有好多种绿，我用哪一种？看下图所示，给出了 RGB 三原色的配色数值（别相信本身的眼睛，不一样显示器上看到的效果会有差别，做为程序员须要精确点）。至于为何是这个选择，后面再说。

 

审美

除了基本的图形和颜色选择以外，另一个关注点是审美。审美对最终的效果呈现有很大影响，这得感谢苹果总设计师 Jonathan Ive 把大众的审美倾向所有带入到扁平化时代，因此实际我只须要把图形弄得扁平，去掉立体、阴影什么的，看起来就还不错了。

 

几何？

探讨了如何，咱们接着看看几何。此「几何」不是数学里的几何，而是曾几什么时候，咱们想象中很麻烦的事原来如此简单。掌握画图技法到底代价几何？又价值几何呢？

三年前，我画的技术图示（来自之前一个分享 PPT）大概是下面这样的，老是以为很差，不太满意，却又不知道很差在哪里，该怎么改进。而后就归罪于工具很差用，从一开始用 Viso 画，后来尝试了 Mac 下的专业绘图工具 OmniGraffle，以为太复杂后又找到个在线绘图网站 draw.io，感受还能够，但因为是国外网站，访问效率不太好没多久就放弃了。以后须要作一些 Slide 演示时，用了 Mac 下的 Keynote（至关于 Win 下的 PPT），须要画技术图示时想若是直接在 Keynote 里画最省事了，而后就开始用 Keynote 画了。

 

前面写到颜色选择时，提到为何就选这种红而不是其余红，其实这就是 Keynote 在白色背景下默认提供的调色板色块选择。做为程序员提供一个软件的默认参数，一般的道理是这个参数可能在大部分场景下都是最优的。因此我倾向于认为 Keynote 的默认色块是这个背景下的一些最优纯色选择，并且我本身肉眼看起来也还感受不错，这样就省了打开更高级的配色参数界面，绘图的效率又更高了，代价也更小了。因此按这个指导原则，从新画下上面这个技术图示大概就像下面这样，花费的时间绝对不会比画上面那个更多，但呈现效果自我感受确实要好多了。

 

因此，学会使用一种简单的软件，使用简单的图形和配色，在最有效率的状况下画出一幅效果还不错的图例，也是颇有价值的。固然不少程序员会认为只有写出的代码才有价值，其实这里可能忽视了一个大部分程序员都认同的观点：代码也是写给人看的。程序员不会认为一份机器能运行而人很难看懂的代码是好代码，而画好图能更好的帮助你去思考代码的组织和呈现方式。

须要画图工具和之类的教程，能够加个人群：705194503  里，供你们免费下载，但愿能够帮到你们

本文只是介绍了一种极简的绘制技术图例的技法，毕竟咱们画图只是为了追求讲清楚一个技术或展现一个系统，不须要考虑任何多余的艺术性。最低的代价，还不错的效果，在效率和效果之间取得性价比最高的平衡。

...