在《批量作業調度技術界的兩大困惑》一文中，分別討論了在傳統設計理念下，流程圖的可視化、作業流的定義設計功能，隨着作業量增加，越來越難用，越來越不適用是一個難以避免的問題。就這兩個問題，我給大家分享一下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中的表達方式：
（2）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語句、各種函數、屬性繼承、重載以及自由註釋等。
（2）從配置理念到開發理念
傳統作業信息組織是記錄式表達，而TASKCTL是用具有一定語法規則的結構化代碼來表達。記錄採用配置概念，而代碼顯然採用開發概念。傳統爲了方便記錄的配置，設計了相應的對話框；而TASKCTL，爲了方便文本代碼的開發，設計了相應的IDE環境。
傳統方式，之所以更願意選擇Excel對更多記錄的配置，其核心原因是Excel是一個平面文件。相比一個個對話框，平面文件更便於信息瀏覽、查看、編輯。而TASKCTL信息本身就採用格式代碼的方式，本身就是一個平面文件。IDE設計的目的，只是爲了更好的管理、設計開發TASKCTL的代碼文件。
如果站在另一個緯度，傳統Excel方式配置和TASKCTL代碼方式開發，都是爲了產出一個有規則的文件的話，一個是採用普通文件編輯器編輯，而另一個是採用針對這種規則設計的特殊編輯器（IDE）進行編輯。
我們知道，JAVA程序的設計，是可以直接通過簡單的記事本來完成，但我們還是要採用更強大的eclipes進行開發設計，中間的差距，不言而喻。