在传统设计理念下，流程图的可视化、作业流的定义设计功能，随着作业量增加，越来越难用，越来越不适用是一个难以避免的问题。就这两个问题，我给大家分享一下TASKCTL是如何转变思路、如何突破、如何带来一些更理想的效果。同时，我也希望通过此次分享，带来一些抛砖引玉的效果，希望业界更多同仁，就批量调度技术更多的问题，敢于突破，使整个批量调度技术变得更完善、更易用。
第一部分：两大问题的再分析
在传统理念下，流程图可视化与作业流程定义方式不适用这两大问题，并不是孤立的，它们之间是相互影响，并相互恶化的。它们问题的核心都来源于一个共同的设计理念。
（一）传统作业依赖关系组织方式是两大问题的共同根源
传统作业依赖需求表
以上表格是传统方式对作业信息依赖关系组织的基本形态，作业之间的依赖关系采用属性记录的方式（有些调度设计不是前依赖，而是采用子作业后依赖方式，但本质是一样的）。这种方式，每条作业信息记录都是独立平等的，其中依赖关系只是每个作业的一个属性。我们认为，这种基本信息组织理念，对于小规模的作业信息组织影响不大，但对于大规模作业信息组织，就会影响到流程图展示，作业设计方式的适用性问题。
（二）对作业设计方式的影响：对话框方式不如Excel方式
（1）对话框方式不如Excel方式的原因
首先，是对作业设计方式的影响。从信息组织的记录特征出发，我们很容易想到对话属性框的设计方式。通过每个属性框的输入，完成作业各种属性信息的定义。但当我们面临大量作业信息的编辑时，很快就会发现对话框还不如直接编辑Excel。在Excel中，无论对更多信息的查看、编辑、拷贝、粘贴，都比对话框方便得多。
也许，你会说，我用的不是对话框方式，而是图形拖拽方式设计，很直观的。但实际上，拖拽编辑的直观是表面现象，背后依然是繁琐的对话框方式。这也是很多专业的调度软件，在实际使用场景中，宁愿选择 Excel方式主要原因之一。使用拖拽，可能只有两种情况，一是新手，二是唯一的设计方式（比如ETL工具），你没有更良好的选择。
（2）Excel带来的新问题
如果我们只关注编辑管理效率，相比对话框方式，Excel显然得到很大提升。但Excel的作业设计方式，又带来以下两个难以避免的问题：
第一个问题：脱机方式，与系统不能实时互动。我们采用了excel方式，单从编辑的角度，是提高不少效率。但Excel毕竟是第三方软件，不能与你的系统实时互动，它不能真实理解你每个属性的含义，不能实时检验你的信息，比如重复性，合法性。这一切，可能只有在导入的时候才知道。这些需求需求，你可能说，我可以通过二次开发Excel完成。没错，你可以做到。但我只想说，早知如此，何必当初，你又何必在调度软件里费那么大的力气，设计相应的对话框作业定义功能呢？
第二个问题：作业关系梳理很麻烦。采用excel，由于是脱机的方式，在excel中，我们很难实时直观的知道作业之间的关系，这对于作业间的依赖关系设计、修改，都变得非常困难。
（3）如果Excel方式是好的选择，那我们就应该多点匠心，多点优化。
虽然Excel有以上两个问题，但客观上，它的编辑管理效率比单纯的对话框方式，要高出很多。既然这样，我们为什么不多点匠心，将excel平面表格的方式集成到调度软件当中，这至少会使用户体验度，得到大幅度的提升。
（三）对流程图可视化的影响：线条大量交叉、排版混乱使流程图缺失直观性
（1）关系的*组织，客观上难以避免凌乱的关系
由于作业之间的依赖关系，采用属性定义的方式，使你可*定义作业间的多个依赖关系，但随着作业数的增多，你就很难控制这些关系的实际形状。一张蜘蛛网似的关系图，可能就此诞生了。
（2）人工编辑图形，同样难以避免凌乱的关系线条
为了避免凌乱的线条，你可能会想到图形编辑方式。毕竟在图形的向导下，可避免一些复杂的线条。但随着作业数的增多，首先是编辑变得异常困难，其次是在增删改的过程当中，线条的重构，重新排版带来的工作量也是你难以想象。也许,你会想到自动排版，但这种没规则的关系，在作业数多的情况下，其效果可能比你想象的还要糟糕许多。
（四）两个问题相互影响，相互恶化
总之，在这种信息组织理念下，如果采用图形拖拽，对话框方式，也许会减少很多凌乱的线条，使关系变得清晰一些，但这种方式又带来巨大的编辑工作量。如果采用Excel方式以提高编辑工作效率，那一定会给你带来难以接受的关系图。这两种矛盾，在目前设计理念下，是难以协调的。
第二部分：TASKCTL的突破
在TASKCTL理念框架下，不论作业数多少，作业间的关系线条，始终是无交叉、清晰、直观的，而且还没有图形编辑的繁琐。在IDE环境下，设计再多的作业，也比Excel似的设计，更为快捷、更为高效。而TASKCTL这些突破性的变化，更为理想的效果，主要是因两大理念的转换所带来的。
（一）作业依赖关系组织理念突破
（1）从*组织理念到结构化组织理念
传统作业间的关系信息组织是*的，但在TASKCTL中是结构化的，通过串并组的方式组织作业之间的依赖并行关系。
一个传统表达方式：
传统作业流需求表
同样的关系在TASKCTL中的表达方式：
TASKCTL批量作业XML文件设计界面截图
（2）TASKCTL流程图本质上是一张有序无环图
TASKCTL采用这种串并组结构化组织，本质上就不可能具备交叉现象，是一张有序无环图。以下是一张TASKCTL流程图示例。
TASKCTL有序五环图作业流展示截图
（3）TASKCTL对有序无环图缺陷的弥补
对于有序无环图这种图形关系表达理念，在大数据领域比较普遍。无论是底层基于资源的任务调度逻辑，还是OOZIE（一款大数据领域的作业流调度工具）业务工作流调度逻辑，都是采用有序无环的关系表达理念。但同时，我们也要知道，这种逻辑管理组织理念，有一种缺陷，就是无法做到一些交叉关系表达。比如以下关系：
作业设计需求流图示意图
在有序无环图表达理念中，上图C到D的关系是无法表达的。不过在TASKCTL，这种关系特殊的处理，可以通过LEAN（强制依赖）以及事件方式进行相应处理。LEAN属性与传统方式理念是一样的，可*组织依赖关系。只是在TASKCTL中，这种传统方式只是基于串行结构化依赖的一种补充。
在任何一门计算机语言当中，可能都有类似GOTO这样的语句，实现一些灵活的关系跳转。但我们都知道，为了增强信息的可管理型、可读性，尽量采用结构化语句编写，而GOTO，尽量避免。在TASKCTL中，LEAN就像GOTO一样，作业关系我们尽量用结构化串并组嵌套方式表达，而LEAN这种灵活的表达方式，还是少用为好。
（二）作业整体信息组织理念的突破
（1）从单纯记录信息到结构化，规则化的“代码”信息
在传统作业信息组织方式下，是以每个作业为一个独立的设计单位，而在TASKCTL中，是以一个结构或多个结构为设计单位；传统的焦点是每个作业个体，而TASKCTL更倾向于一个更大的整体。TASKCTL站在一个整体特征的角度，设计了相应的规则，并以XML格式进行表达。实际上，TASKCTL的设计信息更像具有一定语法规则的代码，并引入了很多代码语法理念，比如if语句、各种函数、属性继承、重载以及*注释等。
TASKCTL作业批量开发XML代码截图
（2）从配置理念到开发理念
传统作业信息组织是记录式表达，而TASKCTL是用具有一定语法规则的结构化代码来表达。记录采用配置概念，而代码显然采用开发概念。传统为了方便记录的配置，设计了相应的对话框；而TASKCTL，为了方便文本代码的开发，设计了相应的IDE环境。
传统方式，之所以更愿意选择Excel对更多记录的配置，其核心原因是Excel是一个平面文件。相比一个个对话框，平面文件更便于信息浏览、查看、编辑。而TASKCTL信息本身就采用格式代码的方式，本身就是一个平面文件。IDE设计的目的，只是为了更好的管理、设计开发TASKCTL的代码文件。
如果站在另一个纬度，传统Excel方式配置和TASKCTL代码方式开发，都是为了产出一个有规则的文件的话，一个是采用普通文件编辑器编辑，而另一个是采用针对这种规则设计的特殊编辑器（IDE）进行编辑。
TASKCTL作业设计IDE截图
我们知道，JAVA程序的设计，是可以直接通过简单的记事本来完成，但我们还是要采用更强大的eclipes进行开发设计，中间的差距，不言而喻。