利用django打造本身的工做流平臺(一):從EXCEL到流程化運做

　　因工做所需以及管理我的一些平常事項，本身基於django（一個基於python的web框架，詳細介紹可查閱相關資料）開發了一個簡易的工做流平臺[平臺地址]。本文首先簡要介紹工做流平臺的設計思想及其在項目開發中的應用案例，代碼層面的細節介紹後續有時間繼續補充。

　　1.工做流平臺在平常工做中的設計思想： 

　　若是你是一名軟件研發類工做的從業者（開發、測試等），設想一下早期在沒有問題單系統的時候是怎樣處理軟件問題的：使用一份excel表格記錄問題，如圖1所示：用戶A在系統平常使用或者測試過程當中遇到問題，須要將問題的關鍵信息（概要，詳細描述，環境配置，觸發步驟等）整理到EXCEL表格中。再經過電子郵件把表格發送給開發人員B。B可能同時有幾個問題要處理，在接收到的問題中添加一些列用於記錄問題狀態信息（當前狀態；解決時間；問題處理人等）。

 圖1.問題記錄表格示例 

　　用excel記錄和傳遞問題信息的弊端：
　　1.處理閉環的不肯定性：發送給開發人員B的問題郵件可能被淹沒在他的大量郵件中，沒法確保問題必定被解決；
　　2.效率問題：經過郵件流轉問題處理信息效率過低。尤爲人員較多時，人手一份EXCEL的副本，進行信息同步帶來很高的溝通成本。

　　爲了解決上述兩個問題，誕生了專用於問題處理的問題單系統，其實質是web化的excel：圖1中的每一行對應爲一個問題單，每一列對應問題單的一個字段。其中有兩個字段較爲特殊："問題處理人"和 "當前狀態"，WEB後端利用"問題處理人"字段與當前登陸用戶X進行匹配，把過濾出相匹配的問題並顯示在界面上，就是須要用戶X處理的問題。另外WEB後端預設有問題處理流程，根據"當前狀態"字段決定接下來的處理：好比問題處於"待處理"狀態，則下一步能夠經過編輯問題單處理問題；若是問題單處於"已解決"狀態，則表示該問題已完成處理歸檔，不能再進行處理了。

　　問題單系統優點在於經過固化字段、流程以及某些流轉條件（好比設計xx字段爲必填項），首先保證了問題處理的閉環，同時最大程度減小了問題流轉到下個環節信息不足的狀況；解決了多個環節間信息流通，多人協做的效率問題。

　　其不足在於字段和處理流程固化致使功能單一，只能用於問題處理跟蹤，擴展性差。再審視一下問題單系統的實質：問題單系統實際是將一份EXCEL WEB化並使用固定的流程進行處理。咱們把問題單系統視爲一種特例，特例通常化（將多份EXCEL WEB化，每份EXCEL使用其給定的流程進行處理）就能夠打造可定製字段、流程的工做流平臺，用於部門團隊的事務管理和知識積累。

　　工做流平臺的架構很是簡單，採用自底向上的設計，步驟以下：

　　1.爲一種事務（問題處理、請假審批等）定製字段和流程；

　　2.把一種事務的字段和流程封裝成一個項目。

　　3.把多個項目封裝成項目羣。

　　工做流平臺的基本架構如圖2所示：　　

圖2：工做流平臺的基本架構

　　理解了上述架構，不難看出工做流平臺的核心就是兩張表：數據表和狀態轉換表。數據表決定顯示哪些內容，數據表字段決定如何顯示(好比從數據表過濾出「當前處理人字段」等於當前登陸用戶名的數據顯示在界面)。轉換表決定每一個問題的處理流程，每一個項目都有一組State1xStim1>State2格式的描述，表示State1狀態下收到Stim1激勵跳轉到State2狀態，這組轉換描述肯定了項目的處理流程。State1xStim1>State2格式的描述的具體實現形式能夠自由定義，下圖是一個示例：

 

圖3：狀態轉換描述表 

圖4：狀態轉換描述表對應的流程圖

　　圖3是狀態轉換描述的一種實現示例，其對應的流程圖如圖4所示。圖3中'source'表示源狀態；'trigger'表示觸發事件,對應界面上的按鈕; 'dest'表示目標狀態;'trans_condition'表示完成狀態轉換須要知足的條件;'trans_action'表示狀態轉換時須要執行的操做。狀態轉換描述表由狀態機引擎解析，這樣每一個項目只要定義本身的狀態轉換描述表就能夠肯定項目對應的事務處理流程。

　　平臺採用三級的頁面結構，按層級關係分爲項目羣首頁、單個項目主頁和具體問題單頁面。

　　首頁列出了每一個項目的項目名稱，該項目下分配給當前帳號的待處理問題個數等 信息，此外還能夠管理項目，建立項目下的問題，以及註冊爲特定項目的用戶等，如圖5所示。

 圖5.項目羣首頁

　　項目羣主頁上點擊項目名稱能夠進入具體的項目主頁；項目主頁中列出了分配給當前用戶的待處理條目，以及當前用戶的監視條目，如圖6所示。所謂監視條目就是 其餘人在處理，可是當前用戶比較關心的問題；好比某重大問題由人員 A 處理並使用該系統進行跟蹤，並將最新的處理進展更新到系統中的問題單裏，A 的直接主管能夠監視該問題單以及時瞭解問題的最新進展，避免了各類彙報帶來的整理材料和溝通成本； 若某重大問題的關鍵階段已處理完成，只有一些瑣碎的收尾工做，則主管能夠隨時取消監視問題，交由 A 處理便可。項目首頁的右半部分畫出了當前項目的處理流程，該流程圖根據項目的狀態轉換表自動生成。

 圖6.具體的項目主頁

　　項目主頁點擊問題概要可進入具體問題單頁面，其左半部分是問題單字段信息，上方有監視問題和取消監視兩個按鈕用於監 視和取消監視該問題（監視功能介紹見上文）；右半部分是問題單的管理信息，包括建立時間、建立人、當前處理人、當前狀態等，如圖7所示。問題單當前狀態下所能執行的操做由項目流程定義，好比在」 維護人員處理」 狀態下所能執行的操做是」 更新進展」 和」 提交審覈」，前者只更新字段信息，後者將問題處理結果提交給維護表明審覈，分別對應問題單界面下方的兩個按鈕。

圖7.具體問題單頁面

　　2.工做流平臺在平常工做中的應用示例：

　　團隊項目開發過程當中涉及下列事務：

1. 測試問題跟蹤
2. 代碼檢視記錄；
3. 版本發佈記錄;
4. 各類彙報材料管理
5. 調試設備信息、編碼注意事項等瑣事記錄

　　上述事務中有些須要歸檔記錄以便隨時查閱，好比版本發佈記錄、編碼規範、代碼檢視記錄以及調試設備信息、相關人員聯繫方式之類雜項記錄等；有些只須要完成處理便可，好比分解的子功能點開發、測試過程當中遇到的通常問題等。這些事務若是沒有統一的平臺進行管理，多名開發之間的協做，開發、測試、項目管理等不一樣角色之間的溝通，上下級間的彙報等都會帶來很高的溝通成本。

　　爲此在工做流平臺中建立了三個項目：

1. 任務跟蹤：用於跟蹤從需求分解出的子功能點開發、測試過程當中遇到的通常問題等，處理完後便可關閉，再也不顯示在界面上。
2. 開發記錄：用於記錄調試設備信息、相關人員聯繫方式之類雜項記錄等，不要關閉，一直顯示在界面上用於相關人員查閱。
3. 代碼走查：用於歸檔代碼走查記錄。

　　這三個新增項目的三級頁面結構見圖8-14。

圖8.項目羣首頁最後添加三個項目

圖9.任務跟蹤項目主頁

 圖10.任務跟蹤項目的具體問題 

 圖11.開發記錄項目主頁  

  圖12.開發記錄項目中的具體問題 

圖13.代碼走查項目主頁

圖14.代碼走查項目中的具體問題

　　此外，平臺中每一個項目都支持權限管理，平臺中數據與EXCEL之間導入、導出等，以下圖。還有的項目支持繪圖，詳見http://www.javashuo.com/article/p-oundwkry-nb.html。

 圖15.代碼走查項目導出到表格的問題

　　除用於項目管理外，工做流平臺還能夠拓展其餘方面的應用，如問政反饋、掃碼點餐、請假審批、物流信息跟蹤等。