乐趣区

关于软件工程:技术-|工程-浅谈开发中的逻辑可视化及-drawio-的自定义图形运用

事件是这样的,作为工程师,特地是全栈类的,常常要面对一人承当多角、关照多项的事实。

任何一个我的项目都会随着工夫倒退而逐步简单、精密和宏大化。在凝固纯正智力的编程开发过程中更是如此。

最近圈内很风行一个词:屎山。尽管听起来有些不雅,但却非常形象地比喻了随着开发进度倒退,而逐步繁杂、艰涩、不条理等等领有各种弊病的我的项目。

这种我的项目的代码,没有一个开发者违心碰,或者持续批改。就跟其名一样,唯恐避之不迭。

解决“屎山”惟一的方法,就是重整旗鼓,再造一个新我的项目(即使新我的项目也有倒退为新的“屎山”的可能)。

成熟的开发者通常领有肯定水平的代码洁癖,能够尽最大水平防止“屎山”的命运来临。但当我的项目体量增长后,再有洁癖的人,也会被各种逻辑搞到头晕。

不论是初学者还是资深开发,置信很多人都有这样的体验。第一天本人亲手写的代码,到了第二天再看的时候,就开始犯晕,到了第三天,感到了解艰难。静置一周后,就彻底不晓得本人过后是怎么写的了。如果放了超过半个月,可能连碰都不想碰了。

甚至经常会遇到,一顿饭的工夫,脑海中的逻辑运作就被彻彻底底打乱。

这与程序员的工作形式无关。智力输入须要大脑进入深度思考,优质高效的产出更是须要极为弱小的专一。这种状态下,对外界和工夫的感知都将削弱,也就是所谓的“忘我投入”(可参考心流实践)。

日常生活中大多不须要这种对脑力近乎到底的深刻,而程序员的工作则要求本人的大脑可能疾速进入状态。


但,光进入状态还不够。深度思考的目标是将逻辑以代码的模式编写进去,这个时候面对的问题就是:“逻辑”从哪里来,以及如何疾速将“逻辑”排汇到本人的大脑里。

先说“逻辑”从哪里来?

首先,开发不是零打碎敲的,少则数周,长则几十年。而人类是会忘记的,明天写的程序,特地是简单的算法,搁置一小会儿就会懵逼。这就须要咱们可能在文档或者代码中,从新载入 / 拾起之前的逻辑和状态。

在团队合作中,须要了解其他人写的代码是啥意思。集体开发中,则须要晓得本人之前写的是个啥。

这些代码或者文档的背地,就是“逻辑”。

做到准确无误的了解是根本要求,而事实的生产开发是个工程,谋求高效率就要求疾速精确了解。

如果把大脑类比为电脑,那么想要疾速进入深度状态,就要求你有一个优异的缓存,读写速度快,且容量大。

因为进入深度思考后,要同时顾及十分多的逻辑分支,大脑载荷会十分大。

而家喻户晓,计算机缓存的读写速度和容量大小,间接决定了性能好坏。人类大脑也是一样。

从“逻辑”连接角度看,咱们能够简略认为,编程工作须要将前序逻辑,加上本人的产出,输入给后续持续应用。就跟盖房子一样,理解后面的状态,增加新的状态,以供后来者持续添砖加瓦。

只不过这里所谓的砖瓦,具象为代码,实质是逻辑。也就是所谓的“搬砖”,搬本人或其他人大脑里生产的砖。

那读写速度由什么决定呢?

其实就是了解速度。

面对文档、代码,先了解字面意义,彻底消化吸收后,转化为形象逻辑,进而对逻辑进行加工生产,而后转化为代码和文档,再输入给将来的本人或者其余团队协作者。

下图是个繁难的示意,越往底走,跨层耗费的精力和脑力都越大。

这也是“屎山”为什么令人厌恶,就是因为要排汇的是一堆难以了解、繁杂艰涩的代码。不易浏览,且逻辑不通顺、不清晰、不条理,运行效率还低。对于谋求颅内低潮的程序员来说十分不敌对。

所以总有程序员之间会互骂对方写的代码跟“屎”一样,说的就是这个事。

优雅的代码总是给人一阵阵清风拂面的感觉。

进步了解速度有几个通过工夫考验的教训办法,比方好看的代码书写格调,规整的接口设计等等,常见的方法论有驼峰命名法这些。

还有就是好好写文档和正文,解释某一行要害代码是干啥用的。

规范的格局,通用的规定,体系的语言,对于升高了解老本非常无益。

此外,主观来讲,“了解”这个行为自身的状态,还与各种环境密切相关。

最近有一个显著的发现。工程体量大了当前,本人编程两个小时,有一个小时的工夫都用来了解回顾之前写的代码。而等到真正进入外围的编码过程中,最多也不过半小时。随着代码数的递增,了解难度和须要的工夫就会正相干增长。

更不用说,对于绝大多数开发者,还常常被外界乐音或者光线或者琐碎的杂事打乱。好不容易进入状态了,后果又被喊走解决其余事件,在进入深度思考的过程中重复横跳,耗费的是微小的精力。

我忽然了解了为什么之前会在一本业余书上看到作者举荐浏览《演员的自我涵养》。程序员进入逻辑世界的过程,就像是演员进入情感世界。试试如果在一个演员刚刚进入角色时马上把他喊出来,想要再次进入角色就会异样艰难。

同理于程序员,老是被打断,相当于从精力上覆灭。

这也是为啥简直所有的程序员都在早晨夜深人静后工作效率暴涨,完完全全没有打搅、能够宁静工作、彻底沉迷在编码过程中的大块残缺的工夫,在一天当中真的太少了。

而如果一周当中可能有一天齐全沉下心来解决一些重要节点,能够说对于任何一个开发者都是莫大的幸福。

(所以关爱程序员,请不要忽然吓他。)

既然环境不是那么的可控,那么咱们从人类如何了解问题这个最实质的角度登程,回归逻辑自身。


尽管轮子都是本人造的,编码的时候也极尽可能地放弃柔美,但还是不免被一些简单难点再次卡住。认知心理学通知咱们,人类对图像了解的速度远快于文本文字。所以用图像来形容逻辑,是一个十分无效的办法。

综上一大堆前置背景和现状条件,这就天然引申出一个概念:逻辑可视化。

比方常见的流程图,就是其中一种。

侥幸的是,通过工程学的长期倒退,前人总结出了一些方法论和无效的逻辑工具,其中最为驰名的,简直所有业余人员都应用过的,就是 UML,全称:对立建模语言。

首先,建模,不是单纯指物理层面的空间模型的构建,它能够指代构建任何设计或者概念中的实体,这些都能够叫做建模。比方数学模型、计算模型、软件模型等等等等,十分多。

UML 是一门语言,这就意味着它有零碎的形容问题的方法论。而承载这门语言的具体载体模式,是图形。换一步讲,就是 icon。

这就在逻辑、可视化和生产需要,三者之间构建起了桥梁。

而 UML 在很多大学里,都是一项专门的必修课。

狭义的 UML 能够泛指所有过程逻辑和流程。不过当初谈及,肯定离不开它是一种面向对象设计办法下的产物。

这就不得不提到,它的弊病。也是我集体当初开发过程中遇到的鸡肋的中央。

第一,UML 是文档驱动下的建模语言

置信说到文档驱动,第一反馈肯定是瀑布模型。而随着产品疾速迭代的需要和麻利开发的崛起,UML 这种规整老派的开发方式,无奈响应一直变动的需要。甚至逐步成为影响开发进度的绊脚石。

最传统的先建模,后依据模型来开发的工程思维,曾经跟不上当初的节奏了。所以目前来说,它的驱动作用逐步弱化,我集体更偏向于将其作为软件实现逻辑的演绎整顿工具。

第二,UML 是面向对象的

尽管想要整顿逻辑构造,但不论是用例图、时序图、泳道图、类图还是其余各种图模式,核心思想都是将操作环节看做对象的行为和交互。

面向对象的办法,很难将面向过程的局部也出现进去。但纯正的流程图形容下的面向过程思维又过于细颗粒度,对于想要在对象和过程之间找到一个适合的形容办法,UML 仿佛又太顶层了。

比如说,我想形容一个函数实现的嵌套关系。UML 既没有“函数图”这种货色,又没有必要将嵌套关系以流程图的形式完完全全铺开来看。

当初的集成 IDE 有不少反向代码求图的工具,比方 pycharm 中的 show diagram、profile 里的 Call Graph,还有基于 Graphviz 的 PyCallGraph。

尽管能够肯定水平上自动化生成类图或者函数图或者调用关系。但三者总有各自的短缺,比方没有接口 io,或者没有参数阐明,亦或者颗粒度不可控,以及性能非常无限。总之,每一款用起来都感觉缺斤短两。

如果把 CS 的所有具体都形象为一种模型来形容,其实就是下图这种:

三大件:一个输出,一个输入,两头一个解决模块

任何函数或者算法或者模块,都是依照这种模型来构建的。

那其实,用这种形式来串联逻辑节点,形容性能构造,是卓有成效甚至高效的。

如果你相熟或者据说过空幻引擎、Blender 或者达芬奇,他们的操作形式就是节点逻辑。一端输出,一端输入,各种迭代串联,连起来实现最终成果,甚至有了最近大热的低代码的影子。

但如果你认真看这个图,就会发现这种模式如同在哪里见过。

是的,没错,为了更不便地可视化逻辑,我去找了画电路图的软件 Quartus ii。

意外发现,硬件开发方法,在软件开发中,居然非常有用。

在硬件开发中,通常用引脚示意输出和输入,而且更广泛的是,为了不便了解和养成良好的习惯,通常右边示意输出,左边示意输入。

而图形代表的硬件配件外部是怎么实现的,则被封装起来。

此外,模块化的搭配应用,也完满满足代码复用,缩小重复劳动。无论从哪个角度看,这种可视化的形式都完满符合咱们的需要。

由此,找到了解决 UML 和流程图鸡肋的办法,也是一种高效的逻辑可视化的形式。

既然实践工具找到了,用什么来画呢?

IBM 的 Rational Rose 尽管是精于 UML 的,但年代过于长远,而且新零碎上很多都无奈运行。
Quartus ii 只专一于硬件设计,对于软件层面的类、函数、接口、流程这些,无从下手。
纯绘图软件诸如 Adobe Photoshop 或者 illustrator 都太过于宽泛。

在试用过有数工具后,隆重举荐赫赫有名的 drawio,一款开源的流程绘制软件。

内置集成了十分多畛域的图形元素,甚至还能够画产品界面、原型图、UI 等等。

它是基于 xml 的,跟 SVG 同源,这意味着能够运行在 web 端。也能够导出任意想要的格局。

基于 xml 是有一个原生劣势的,那就是你能够自定义图形。

在实际操作中,有一些非凡图形或者合乎我集体习惯的图形图标不存在,那么我就能够抉择自定义图形,而后保留为本人的图形库。

它的语法格局也很通俗易懂,外围就三个部件:
<connections> 示意连接点
<background> 画图标背景层(不便做暗影款式等)
<foreground> 画前置层(比方文字说明、图形等)

举个栗子:
设计了一个矩阵乘法的函数 icon

款式如图:

背地的代码很简略:

<shape aspect="variable" h="60" name="Inverter 2" strokewidth="inherit" w="100">
  <connections>
    <constraint name="in" perimeter="0" x="0" y="0.33333" />
    <constraint name="in" perimeter="0" x="0" y="0.66666" />
    <constraint name="out" perimeter="0" x="1" y="0.5" />
  </connections>
  <background>
    <path>
      <move x="0" y="20" />
      <line x="20" y="20" />
      <move x="0" y="40" />
      <line x="20" y="40" />
    </path>
  </background>
  <foreground>
    <fillstroke />
    <path>
      <move x="77" y="30" />
      <line x="97" y="30" />
    </path>
    <fillstroke />
    <path>
      <move x="80" y="30" />
      <line x="20" y="60" />
      <line x="20" y="0" />
      <close />
    </path>
    <fillstroke />
    <fontcolor color="#FFFFFF" />
    <text align="left" str="m1:dict" valign="bottom" x="22" y="22" />
    <text align="left" str="m2:dict" valign="bottom" x="22" y="42" />
    <text align="left" str="m_result:dict" valign="bottom" x="80" y="28" />
  </foreground>
</shape>

具体自定义办法能够间接看官网文档:
Create and edit complex custom shapes

把一个软件的构造像积木或者拼图一样开展,非常不便高深莫测地把握以后开发进度和逻辑节点。清晰看清逻辑脉络,如果真是一团乱麻,倒也很分明地展现出什么叫做“屎山”(不是)。

作为集体的一种教训办法,跟大家分享交换,心愿能够帮到有须要的人。

或者如果有什么更好的办法,也欢送交换探讨。

退出移动版