请问,您是也否见过这样的场景?
一群程序员在一起讨论某个技术问题,而他们只是在嘴上说,并没有通过什么工具来 记录
他们的谈话内容,更没有采用任何 图表
来 深入分析
他们正在探讨的问题。
为什么会这样呢?这样的交流方式是否高效呢?
除此之外,您是否也见过这样的场景?
一群程序员和几个非程序员在交流某个 IT 产品开发问题,其中涉及到了不同岗位的人员
。比如:产品经理、项目经理、开发人员、QA等。当某位程序员神采飞扬地讲述自己的 技术方案
时,周围很多人都露出了疑惑的表情,有人甚至目瞪口呆。等他讲完之后,其他人开始了疯狂的提问,这些 “低级” 的问题甚至让这位程序员开始怀疑提问者的智商。
为什么会这样呢?您是否见过甚至曾经成为过这样的程序员呢?
即使单纯从技术角度来思考,我们也可以找到一些实际的事例来证明画图的必要性。
假如以 Keep 为例,我们要讲述其 In-App Purchase 的交互过程。它的时序图大致是这样的:
试想一下,如果没有这个时序图,我们如何高效地解释这整个过程?
如果您感兴趣,这是原文:根治顽疾:Keep客户端 In-App Purchase 掉单踩坑指南
UML 是业内知名的建模工具,可以有效地帮助我们完成编程分析工作。
最最常用的UML图有以下几种:
经典的《设计模式》书籍 中就会用到 UML类图 来展示各种常见的设计模式,比如:
上图展示的是 抽象工厂模式的类图
,只要我们可以理解不同的框的含义、不同的线和箭头的含义,我们就可以很容易地通过这个类图来理解抽象工厂模式的实现。
目前为止,Ficow 个人认为 UML类图
和 UML时序图
是程序员必须要掌握的技能。
UML类图可以帮助我们剖析类型系统的静态结构关系
,而UML时序图可以帮助我们剖析活动参与者之间的动态交互关系
。
C4:Context, Container, Component, Code。
对比 UML,C4 没有那么知名。但是,其相对来说要简单很多,学习成本较低,绘制也很简便。您可以根据所要展示的内容的粒度来选择不同抽象层次的 C
。
这里是一些具体的示例,您可以通过它们来感受 C4 的简洁与强大。
Ficow 个人认为,C4 更适合在与非技术人员进行沟通的时候使用,因为其简洁、易懂!
我们不一定非要学会画 UML、C4,我们可以绘制草图并自行制定标准,只要别人可以理解图中的内容就好。
最好的例子就是 地图
,地图的左下角会有图例,而且会有比例尺。不同的地图可能有不同的图例,中国地图和某个景区的观光地图就有很大的区别。但是,你都可以很容易地理解地图中的内容。
比如,Ficow 在为 The Knot 移除供应商店面(Vendor Storefront)页面的 IGListKit 依赖的时候就通过草图来缕清楚了 IGListKit 的重要参与者之间的引用关系:
然后,为了尽可能少地改动项目中已有代码,Ficow 仿造了一套相似的架构:
其实,仔细对比就会发现,两套方案其实是一模一样的!现在,我们成功移除了对 IGListKit 的依赖,在减少项目编译时间、启动时间的同时,保证了已有代码的稳定性。
其实,这个图非常简单,我相信您也可以很快就画出来。只是,您可能不习惯去画图。
然而,如果您不去画图,直接在脑海中简单构思之后就开始去编码,您极有可能陷入到繁杂的细节中,最后被代码绕晕。
所以,Ficow 建议您,遇到代码逻辑较为复杂的情况,先画图!先画图!先画图!
通过切身感受以及读书学习,Ficow 对 前言
中提到的那些场景已经有了一些感触和心得。通过画图来对内容进行 可视化
是一种较为有效地解决这类问题的方式。
需要注意的是,不同的上下文环境需要不同的图,不同的人员需要不同的图。只要图的内容有助于看图的人理解你想表达的内容,一图胜千言
!
对于开发人员来说,画图可以把逻辑外化存储,为大脑减少记忆、思考的工作量。而且,即使过了数月或者数年,一张有效的草图可以帮助我们迅速理解相关的内容。
还是那句老话:工欲善其事,必先利其器。本文介绍了很多画图的方法,每一种画法都可以在一定程度上提高分析和交流的效率。选择适合您的方法并坚持练习,假以时日,我相信您一定可以感受到画图带给您的好处!
希望本文对您有所帮助,欢迎您留言和 Ficow 交流,大家共同进步~
参考内容:
UML
C4
设计模式 - 可复用面向对象软件的基础
程序员必读之软件架构
根治顽疾:Keep客户端 In-App Purchase 掉单踩坑指南
觉得不错?点个赞呗~
本文链接:画图 —— 程序员必备的神技
转载声明:本站文章如无特别说明,皆为原创。转载请注明:Ficow Shen's Blog