X28 程式寫作員的未來(6)──系統的開發

曾經問過公司裡幾位資深的專案成員，請他們簡單描述心目中理想的開發工具是什麼？他們在開發系統上的期望都很一致：希望有個工具指引SA進行交易需求訪談的步驟，依序完成後可以自動建立可在系統架構下執行的交易骨架，同時產生需求規格書（給客戶驗證）與設計規格書（給PG開發），PG依據設計規格書將交易開發完成。



專案的開發模式為了爭取時效，大多只由SA根據需求規格書範本作訪談並填入結果後，就讓PG以人工方式建立所有相關內容並進行開發，設計規格書幾乎都從缺；測試出與需求有關的問題有時會發生沒有同步修改需求規格書的問題。從需求到可執行內容之間有很多需要記錄且有緊密關連的內容，全部交由人工製作時不僅比較花時間而且易產生錯誤，如果真的有這麼一種交易開發工具的話……。

公司裡較資深的技術人員的走向都是往快速建立可執行的系統架構，認為工具只能作為輔助設定的用途，唯有我在思考著定義可以增進開發人員產能的便利工具（我想，是因為從系統架構層層堆疊設計到工具並不在“可執行”那條捷徑上吧？），有時就會戲稱自己為“工具型”的資訊人員。2010年第一季試做了交易開發工具部分概念的POC，試用過的四位SA一致認為運用這樣的工具可以節省現行開發方式25%-33%的時間。

分析一個交易的組成單位大致有：主要的畫面、畫面邏輯、欄位、欄位邏輯、Context欄位、交易流程、交易參數（根據交易流程中使用的商業模組而來）以及次要的週邊控制、報表格式、電文轉換等。我認為不管要開發什麼用途的系統，幾乎都可以套用這些元素來定義交易內容，因此才會有“萬用交易開發工具”的想法；至於系統tier切割的差異，同樣使用替換“範本”的概念來對應不同的實作。

交易開發工具會有以下幾種不同的編輯器：
●系統參數（AP層）──編輯環境與系統面相關參數
●Context（AP層）──編輯Context欄位
●交易流程（AP層）──編輯交易流程
●交易參數──編輯選擇交易流程後所有商業模組的參數
●畫面──編輯畫面、畫面邏輯、欄位與欄位邏輯
●報表──編輯列印的格式與相關處理
●電文──編輯主機電文轉換與相關處理