第1關
一天，老闆找到我，說要做個簡單的工作流引擎。
我查了一天啥是工作流，然後做出瞭如下版本：
- 按順序新增任意個審批人組成一個連結串列，最後加一個結束節點
- 記錄當前審批人，當審批完後，審批人向後移動一位
- 當審批人對應結束節點時，流程結束
老闆：簡陋了點。
第2關
老闆又來了：要支援會籤節點。
我又查了一天啥是會籤節點，發現會籤節點就是一個大節點，裡面有很多審批人，當這個大節點裡的所有人都審批通過後，才能進入下一個節點。
我想了一個星期，推翻了原來的連結串列式設計：
結構上我做了如下調整:
- 把節點分為兩大類：簡單節點(上圖中長方形)和複雜節點(上圖中圓形)。
- 用一棵樹表示整個流程，其中葉子節點都是簡單節點，簡單節點都是葉子節點。
- 每個簡單節點裡都有且僅有有一個審批人。
- 複雜節點包含若干個子節點。
- 加入會籤節點: 會籤節點啟用後，所有的子節點都可以審批，當所有的子節點都審批完畢後，會籤節點完成。
- 加入序列節點：子節點只能從左到右依次進行審批，當最後一個子節點審批完成後，序列節點完成。
- 所有的工作流最外層都是一個序列節點，該節點完成後代表整個工作流完成。
為了控制審批流程，我設計了一些節點狀態:
- Ready: 可以進行審批操作的簡單節點是Ready狀態。
- Complete: 已經審批完成的節點狀態。
- Future: 現在還沒有走到的節點狀態。
- Waiting: 只有複雜節點有該狀態，表示在等待子節點審批。
藉助上述規則，一次帶會籤節點的工作流審批過程如下：
老闆：有點意思。
第3關
老闆來了：要支援並行節點。
我查了一下午啥是並行節點，發現並行節點是一個包含很多審批人的大節點，這個大節點裡任何一個人審批通過，則該節點就完成。
然後很快就加入了並行節點：
- 並行節點是一個複雜節點，該節點啟用時，任何一個子節點都可以進行審批，且任何一個子節點是完成狀態時，該節點完成。
加入新狀態 Skip:
- 當一個並行節點的子節點狀態為非(Ready, Waiting)時，其它兄弟節點及其子節點的狀態被置為Skip。
舉個例子?：
老闆：這個設計新增新節點還挺方便的。
第4關
老闆又來了：節點要支援巢狀，比如會籤節點裡有個並行節點，並行節點裡又有個複雜節點，要可以巢狀任意層的那種。
我：其實已經支援了~
- 能無限擴充套件的樹形結構可以支援任意複雜流程。
老闆：小夥子有點東西！
第5關
老闆又來了：要支援條件節點。
工作流附帶一個表單，要根據表單的內容確定下一步進入哪個分支。
經過幾天的冥思苦想，我加入了條件節點：
- 條件節點類似並行節點，只不過只有滿足條件的子節點才能進入接下來的審批。
老闆：已閱。
第6關
老闆又來了：審批人多加兩種型別，比如可以從表單中選擇下一個審批人，還有根據發起人不同選擇不同的審批人。
經過一番考慮，我把簡單節點分成了3類：
- 第一種：審批人是寫死的。
- 第二種：審批人從表單中讀取。
- 第三種：根據發起人和一個對映函式，算出審批人。比如 get_主管("錢某") 得到錢某的主管 李某。
老闆：嗯。
第7關
老闆又來了：節點可以從前往後審批，那能不能從後往前駁回？
我: ......
首先實現了駁回到發起人的功能，相當於一切從頭開始：
- 只有Ready狀態的節點有權利駁回。（就像只有Ready狀態的節點有權利審批一樣）
老闆：你小子偷懶。
第8關
老闆又來了：先實現駁回到上一個審批人吧。
駁回到上一個審批人其實是個很複雜的邏輯，因為工作流中的節點可以無限巢狀，所以如何確定上一個狀態有哪些審批人並不簡單。
犧牲了一些頭髮，我終於實現了駁回上一級的功能：
老闆：閱。
第9關
老闆又來了：實現一個駁回到任意節點的功能。
我發現這個需求並不難實現：
- 不斷的駁回上一級，直到Ready狀態的節點包含要駁回到的節點為止。
老闆：嗯。
第10關
老闆又來了：在普通節點加一個時間限制，要是在規定時間內沒完成就顯示已超時。
我：還有這種需求?
不過還是實現了。
此時我明白了需求和頭髮呈負相關，需求越多，頭髮越少。
第11關
老闆又來了：加一個代理功能，比如有件事讓你審批，但是你拿不準，那就轉給拿得準的人審批。
馬上我發現這個需求跟以往有本質的不同，以往的工作流的節點關係一開始就是固定的，就是在發起流程之前確定的，
但是現在要在審批過程中更改。
無非是加了一些班，掉了一些頭髮，最終設計瞭如下方案：
- 代理操作的本質是，新建一個並行節點作為本節點的父節點，再新建一個兄弟節點放代理人，這樣自己和代理人都能審批通過。
- 代理操作可以無限巢狀，即代理人也可以找人代理。
第12關
老闆又來了：能不能再加一個取消代理的功能？
。。。我已經寵辱不驚了，加就加：
- 取消代理是代理的逆操作
- 如果代理人審批過了那就不能取消代理
第13關
老闆又來了：給每個節點加個前後置條件吧，滿足前置條件才能進入該節點，滿足後置條件該節點才能審批完成。
我的內心：啊老闆再見，啊老闆再見吧再見吧再見吧！
我的嘴：好的老闆，收到收到。
後來：後來我真的給每個節點加了前後置條件，與此同時審批邏輯的相關程式碼增加了一倍。
第14關
老闆又來了：現在有的工作流已經非常複雜了，審批起來耗時較長，能不能對每個進行中的工作流計算一個指標：直觀的顯示目前審批進行的百分比。
我：收到。
其實跟之前的需求比起來這個並不複雜，因為不涉及核心邏輯的改動，本質只是輸入一棵樹形結構然後根據不同節點的狀態輸出一個整數。
經過測試思考，最終敲定的方案如下：
- 工作流完成的百分比指的是樹中最右側Ready狀態的節點到最左側節點的距離 / 最右側節點的距離。
第15關
老闆又來了：能不能給每個節點掛兩個可以執行的指令碼，分別在開始審批該節點和審批完成該節點後執行？
我：收..到。
後來我當然實現了這個功能，同時也發現正值壯年的我已經禿了。
後記
老闆是清華畢業的高才生，不然大概想不出這麼多巧奪天工的需求，後來老闆把這一套工作流系統賣給了廣*證券等公司，我也去別的公司各奔前程，當然那個時候我以為我還有前程。
開始做這個工作流的時候我剛剛本科畢業，後來從這家公司公司離職的時候看鏡子已經垂垂老矣。這已經是3年前的事情了，現在回想起那些加班改工作流的日子，仍然心驚。
最後願天下的同行們都沒有bug，身心健康，攢的錢夠在一線城市買兩套房，在若干年後能無病無災的過上領養老金的休閒退休生活。
近期熱文推薦：
1.600+ 道 Java面試題及答案整理(2021最新版)
2.終於靠開源專案弄到 IntelliJ IDEA 啟用碼了，真香！
3.阿里 Mock 工具正式開源，幹掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式釋出，全新顛覆性版本！
覺得不錯，別忘了隨手點贊+轉發哦！