大家回想一下，有多少軟體公司，多少專案，多少初中級程式設計師在做著CRUD方面的一些重複而繁雜的工作呢？對於公司專案來說，可能60-70%的成本都花費在CRUD方面的開發管理上，對於程式設計師職業生涯來說，可能也有60-70%的工作也是在做著一些CRUD方面的工作，無可否認，作者也是。

　　如果這些CRUD相關的工作全部省去，對於企業來說，意味著什麼呢？自定義表單引擎，就是幫助企業做這樣的事情！對於專案開發的核心三駕馬車，進度、質量、成本，自定義表單可能都是質的飛躍。對於進度來說，需求明確的情況下，原來開發一箇中等複雜的表單，從資料庫到後端再到前端，完整的開發完成，可能需要幾天的時間，如果這些工作全部由自定義表單通過配置自動完成，可能就十多分鐘就能完成，專案進度將會大幅度的提前；對於質量來說，傳統的CRUD方面的工作工作量大且繁瑣，程式設計師工作年限及能力水平不一，測試能力不一，進度要求不一，管理者能力不一，影響因素非常多，質量往往是不好控制的，但如果這部分工作全部自定義表單完成，只要保證自定義表單配置生成的功能是經過反覆驗證過的，那這些影響的因素就可以多數排除，大部分質量就能夠完全可控；對於成本來說，如果大大減少CRUD的開發管理，對於公司專案來說，可能節約半數的成本；這，自定義表單對於企業來說，將是戰略意義上的武器。

　　可能大家接觸比較多的是程式碼自動生成工具，前端後端可能都有。根據規則，從檔案或者資料庫讀取配置資訊，生成前端或者後端靜態程式碼，拷貝到專案中，開發人員在做適當的修剪，再加入業務邏輯，編譯釋出，但，這就是自定義表單麼？對企業來說，有多大的用處呢？我也用過一些，但作用真沒有想象的那麼大，也不是那麼方便，這些程式碼往往是沒有生命的，僅僅是把一些繁瑣的程式碼做了簡化，往往只是簡化了我們碼農複製貼上再批量替換的作用。

　　程式碼生成工具，不是自定義表單。自定義表單，是有生命力的，他是由非常多的資料建模以及規則引擎串聯起來的，資料庫、後端、前端，全是執行時根據規則自行計算、執行或者渲染的。接下來作者將寫一系列文件，介紹自定義表單的設計、開發供感興趣的同行學習交流，由於現在做的工作與自定義表單沒有任何關係，生活也不允許自己放下一切專門來做這個東西，只能在空餘時間來完成，大概半年多的時間，一直持續反覆迴圈做著技術預研、資料建模、定義規則、驗證模型、驗證規則，現在前端和後端基本能夠融合在一起形成一個整體，基本雛形已經形成了，參考基礎原型為K2自定義表單產品功能，程式碼將不斷的整理完善，未實現的功能也會陸續的完成，整理的程式碼連同部落格園文章將在gitee和部落格園上持續更新，歡迎感興趣的同學關注交流。開源地址：https://gitee.com/kuangqifu/sprite

　　後續的文章將會圍繞著大家都接觸過的部門和使用者管理進行展開，1對N關係，中等複雜，基於他們介紹自定義表單，再合適不過了。

　　大概設計的需求（結合下面幾個截圖。不用特別關注需求是否合理）：部門為一棵樹，每個使用者都可以關聯到部門的一個節點上，部門列表需要展示部門層級關係；人員列表支援普通查詢和高階查詢，性別下拉單選查詢，學歷支援下拉多選查詢，高階查詢可選擇查詢欄位以查詢方式（=,>,between,in等），點選部門某節點，過濾所選部門使用者資料，列表中性別以圖示區分，學歷用不同顏色區分，支援匯入匯出，支援批量刪除；使用者表單支援自定義驗證規則，性別和學歷為資料字典，部門欄位為下拉選擇部門樹；以及新增編輯分頁等常規操作；（一般做這樣的功能，中等水平開發人員，可能需要1周/人以上的開發時間，但用自定義表單可能只需要20多分鐘，且不需要寫程式碼）

部門管理

使用者列表

高階查詢

使用者表單

　　自定義表單是一個系統性的工程，絕非想象的那麼容易，但是難度也沒那麼難，關鍵在於資料建模和規則定義，由於之前作者在一家企業負責研發工作流引擎，對於自定義表單有一定的認識，所以個人就在策劃把她轉換為實現，後續的程式碼和文章就當作感興趣同學的拋磚引玉吧。

 　　有問題建議在gitee上提issue，或者與作者聯絡：郵箱：[email protected]，QQ：523477776