环链表的入口图解：有向无环图与节点系统

环链表的入口图解：有向无环图与节点系统提高灵活性与效率的办法是将硬编码的方式换成动态的方式来实现DAG。所谓动态的方式就是将DAG的实现划分成两层：前端用领域特定语言（DSL）描述DAG，后端则是该DSL的解释器。DAG是一种形式化描述流程的理论方法，但是在开发过程中如何实现就相当考验开发者的架构能力了。业务需求的变动对应了DAG的变动，包括节点的增删，有向边的调整。如果DAG在程序中是以硬编码的方式来编写，那不好意思，每一次的调整就是拆旧屋砌新屋的过程。改动的影响边界也难以量化，需要依赖开发人员与测试人员的经验来把控。慢在哪呢？经历了多次项目的复盘，总结下来的原因无非是需求不清、风险识别不够、设计不到位、验证不充分等因素引起多次返工。风险识别等部分因素已经在 决策信息流与专家系统 中展开讨论了。这里我想着重聊下，业务需求与软件架构设计的关系。业务需求经过设计转换后，可以用DAG（有向无环图）来表达。用老板的口头禅“举个例子”

最近水了不少管理方向的粗鄙文章，自己还处于一知半解的状态就忍不住卖弄，想起来甚是汗颜。这篇还是聊点更接地气的开发问题吧。

公司规模从小到大的过程中，作为开发人员最直接的感受之一是迭代速度显著变慢。当公司还是个小作坊时，用户的需求会直接传到开发耳朵边，早上的需求晚上就出了版本，隔天立刻发给用户测试，无所谓测试，也无所谓瀑布还是敏捷流程，用户也觉得备受重视，打钱速度咔咔的。

而当公司人数多了，用户基数变大后，开发速度不可避免地慢下来，要分析来自不同用户的需求，要排优先级，要增加测试，要引入规范的开发流程，这一切的一切都是因为犯错成本显著上升了。但带给客户的感受却是，公司的研发节奏变慢了，每天发新版变成了每季度、每半年一次。仿佛从精瘦的猎豹变成了行动迟缓的大象。

如何让大象跳舞，如何让研发节奏加快，成为了每个公司都需要仔细研究的课题。在回答如何加快之前，得先想清楚慢在哪里。

慢在哪呢？经历了多次项目的复盘，总结下来的原因无非是需求不清、风险识别不够、设计不到位、验证不充分等因素引起多次返工。风险识别等部分因素已经在 决策信息流与专家系统 中展开讨论了。这里我想着重聊下，业务需求与软件架构设计的关系。

业务需求经过设计转换后，可以用DAG（有向无环图）来表达。用老板的口头禅“举个例子”，以每天早起穿戴为例，要穿的衣物包含如下圆圈内的物件。袜子与鞋子有先后（依赖）关系，内裤与裤子也是（超人可以反着来）。把这些要素用有向边连接以指代依赖关系，则构成了可以表达业务流程的有向无环图（DAG）。

有依赖关系的，需要在执行顺序上分清先后，无依赖关系的则可以并行处理。有人会问，要怎么才能做到同时穿内裤和衬衣还戴手表呢？人如果只有两只手，那肯定做不到，但如果有4只、6只手，是不是就可以了呢？别笑，这是在多核架构计算机开发中经常需要考虑的（非本文重点，不展开）。

DAG是一种形式化描述流程的理论方法，但是在开发过程中如何实现就相当考验开发者的架构能力了。业务需求的变动对应了DAG的变动，包括节点的增删，有向边的调整。如果DAG在程序中是以硬编码的方式来编写，那不好意思，每一次的调整就是拆旧屋砌新屋的过程。改动的影响边界也难以量化，需要依赖开发人员与测试人员的经验来把控。

提高灵活性与效率的办法是将硬编码的方式换成动态的方式来实现DAG。所谓动态的方式就是将DAG的实现划分成两层：前端用领域特定语言（DSL）描述DAG，后端则是该DSL的解释器。

这个想法并不新鲜，古文有授人以鱼不如授人以渔之言，硬编码就是授人以鱼，DSL 解释器就是教授其他人捕鱼技能。尤其在游戏引擎与设计仿真等大规模的软件中，这样的想法很常见。游戏系统的程序开发人员并不懂如何编写关卡，如何设计打斗画面和伤害系统；而游戏设计师知道怎样设计任务与场景动作，但不会编写代码。他们双方之间的交流就是通过节点系统来实现，比如Unread Engine的蓝图可视化脚本，Blender的Cycles节点编辑器，泽森科工的ZENO等。

通过这样的双层架构，可以将业务流程的开发调整与软件开发隔离，降低业务流程开发者的能力要求门槛。上图是泽森的ZENO的可视化编辑界面，其他几家也大同小异。

业务开发者基于可视化编辑界面，将不同的业务数据流串接起来，就可以输出一张DAG图。系统解析该DAG图，理解其中各个节点的依赖关系，自动优化出最优路径并执行。到此，可以将系统开发者和业务开发者，在组织架构层面解耦。系统开发者的职责是准备足够多的节点，业务开发者考虑的是如何根据用户的需求，以及系统有的这么多节点，快速拼装出用户想要的功能。至此，整个系统会变得既强大，又灵活，仿佛一头会跳踢踏的大象。

如何设计这样的节点系统？嗯，这又是个Big Story。留到以后再展开吧。