共计 5027 个字符，预计需要花费 13 分钟才能阅读完成。
事件是这样的，作为工程师，特地是全栈类的，常常要面对一人承当多角、关照多项的事实。
任何一个我的项目都会随着工夫倒退而逐步简单、精密和宏大化。在凝固纯正智力的编程开发过程中更是如此。
最近圈内很风行一个词：屎山。尽管听起来有些不雅，但却非常形象地比喻了随着开发进度倒退，而逐步繁杂、艰涩、不条理等等领有各种弊病的我的项目。
这种我的项目的代码，没有一个开发者违心碰，或者持续批改。就跟其名一样，唯恐避之不迭。
解决“屎山”惟一的方法，就是重整旗鼓，再造一个新我的项目（即使新我的项目也有倒退为新的“屎山”的可能）。
成熟的开发者通常领有肯定水平的代码洁癖，能够尽最大水平防止“屎山”的命运来临。但当我的项目体量增长后，再有洁癖的人，也会被各种逻辑搞到头晕。
不论是初学者还是资深开发，置信很多人都有这样的体验。第一天本人亲手写的代码，到了第二天再看的时候，就开始犯晕，到了第三天，感到了解艰难。静置一周后，就彻底不晓得本人过后是怎么写的了。如果放了超过半个月，可能连碰都不想碰了。
甚至经常会遇到，一顿饭的工夫，脑海中的逻辑运作就被彻彻底底打乱。
这与程序员的工作形式无关。智力输入须要大脑进入深度思考，优质高效的产出更是须要极为弱小的专一。这种状态下，对外界和工夫的感知都将削弱，也就是所谓的“忘我投入”（可参考心流实践）。
日常生活中大多不须要这种对脑力近乎到底的深刻，而程序员的工作则要求本人的大脑可能疾速进入状态。
但，光进入状态还不够。深度思考的目标是将逻辑以代码的模式编写进去，这个时候面对的问题就是：“逻辑”从哪里来，以及如何疾速将“逻辑”排汇到本人的大脑里。
先说“逻辑”从哪里来？
首先，开发不是零打碎敲的，少则数周，长则几十年。而人类是会忘记的，明天写的程序，特地是简单的算法，搁置一小会儿就会懵逼。这就须要咱们可能在文档或者代码中，从新载入 / 拾起之前的逻辑和状态。
在团队合作中，须要了解其他人写的代码是啥意思。集体开发中，则须要晓得本人之前写的是个啥。
这些代码或者文档的背地，就是“逻辑”。
做到准确无误的了解是根本要求，而事实的生产开发是个工程，谋求高效率就要求疾速精确了解。
如果把大脑类比为电脑，那么想要疾速进入深度状态，就要求你有一个优异的缓存，读写速度快，且容量大。
因为进入深度思考后，要同时顾及十分多的逻辑分支，大脑载荷会十分大。
而家喻户晓，计算机缓存的读写速度和容量大小，间接决定了性能好坏。人类大脑也是一样。
从“逻辑”连接角度看，咱们能够简略认为，编程工作须要将前序逻辑，加上本人的产出，输入给后续持续应用。就跟盖房子一样，理解后面的状态，增加新的状态，以供后来者持续添砖加瓦。
只不过这里所谓的砖瓦，具象为代码，实质是逻辑。也就是所谓的“搬砖”，搬本人或其他人大脑里生产的砖。
那读写速度由什么决定呢？
其实就是了解速度。
面对文档、代码，先了解字面意义，彻底消化吸收后，转化为形象逻辑，进而对逻辑进行加工生产，而后转化为代码和文档，再输入给将来的本人或者其余团队协作者。
下图是个繁难的示意，越往底走，跨层耗费的精力和脑力都越大。
这也是“屎山”为什么令人厌恶，就是因为要排汇的是一堆难以了解、繁杂艰涩的代码。不易浏览，且逻辑不通顺、不清晰、不条理，运行效率还低。对于谋求颅内低潮的程序员来说十分不敌对。
所以总有程序员之间会互骂对方写的代码跟“屎”一样，说的就是这个事。
优雅的代码总是给人一阵阵清风拂面的感觉。
进步了解速度有几个通过工夫考验的教训办法，比方好看的代码书写格调，规整的接口设计等等，常见的方法论有驼峰命名法这些。
还有就是好好写文档和正文，解释某一行要害代码是干啥用的。
规范的格局，通用的规定，体系的语言，对于升高了解老本非常无益。
此外，主观来讲，“了解”这个行为自身的状态，还与各种环境密切相关。
最近有一个显著的发现。工程体量大了当前，本人编程两个小时，有一个小时的工夫都用来了解回顾之前写的代码。而等到真正进入外围的编码过程中，最多也不过半小时。随着代码数的递增，了解难度和须要的工夫就会正相干增长。
更不用说，对于绝大多数开发者，还常常被外界乐音或者光线或者琐碎的杂事打乱。好不容易进入状态了，后果又被喊走解决其余事件，在进入深度思考的过程中重复横跳，耗费的是微小的精力。
我忽然了解了为什么之前会在一本业余书上看到作者举荐浏览《演员的自我涵养》。程序员进入逻辑世界的过程，就像是演员进入情感世界。试试如果在一个演员刚刚进入角色时马上把他喊出来，想要再次进入角色就会异样艰难。
同理于程序员，老是被打断，相当于从精力上覆灭。
这也是为啥简直所有的程序员都在早晨夜深人静后工作效率暴涨，完完全全没有打搅、能够宁静工作、彻底沉迷在编码过程中的大块残缺的工夫，在一天当中真的太少了。
而如果一周当中可能有一天齐全沉下心来解决一些重要节点，能够说对于任何一个开发者都是莫大的幸福。
（所以关爱程序员，请不要忽然吓他。）
既然环境不是那么的可控，那么咱们从人类如何了解问题这个最实质的角度登程，回归逻辑自身。
尽管轮子都是本人造的，编码的时候也极尽可能地放弃柔美，但还是不免被一些简单难点再次卡住。认知心理学通知咱们，人类对图像了解的速度远快于文本文字。所以用图像来形容逻辑，是一个十分无效的办法。
综上一大堆前置背景和现状条件，这就天然引申出一个概念：逻辑可视化。
比方常见的流程图，就是其中一种。
侥幸的是，通过工程学的长期倒退，前人总结出了一些方法论和无效的逻辑工具，其中最为驰名的，简直所有业余人员都应用过的，就是 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
把一个软件的构造像积木或者拼图一样开展，非常不便高深莫测地把握以后开发进度和逻辑节点。清晰看清逻辑脉络，如果真是一团乱麻，倒也很分明地展现出什么叫做“屎山”（不是）。
作为集体的一种教训办法，跟大家分享交换，心愿能够帮到有须要的人。
或者如果有什么更好的办法，也欢送交换探讨。
