前言
從最開始的小公司做小網站，到現在進入現在的公司做項目，發現小公司裏很多很多工作都是重複的勞動（增刪改查），不過想想也是，業務軟件最基礎的東西不就是增刪改查嗎。
但是很多時候，這種業務邏輯其實沒有必要挨個重寫。總不能說你的增刪改查比我的高級很多。很大程度上，複雜的問題只是數據太多了怎麼優化。
簡介
在真的開始做之前，先來簡單介紹幾個概念。簡單介紹一下PaaS是什麼，大概意思就是已經做好了一個大的平臺，你可以在上邊快速的配置、擴展你的服務。
詳細的介紹推薦看一下阮一峯老師的博客 http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html
概念上
我想從零開始搭建一個能夠配置定義業務，通過代碼擴展業務的平臺。在這個平臺上，簡單的需求，不寫代碼。複雜需求，只寫與標準不同的代碼。
有啥好處
提高生產力
其實，做軟件的大部分時候，都是在寫增刪改查，實在是太簡單了。搬磚誰不會對吧，要想搬得快，不需要你有多麼好的腳力，更多的時候，你可能需要一個塔吊。
穩定的高負載
PaaS的設計之初，就是爲了比較大的數據量來考慮的。項目小的時候，怎麼着都行，但是，數據量一旦上來之後。小的項目可能根本沒法用，如果是PaaS平臺的話，你可能只需要多幾臺機器就完了，還是基礎組搞的事情。
分工明確
提到了高負載，其實很大程度上都是底層的事情。普通的開發，更多的好處只是性能的提升。那麼就需要兩撥能力不同的人來共同完成這件事情。搞底層的更專注性能、擴展，搞業務的就更關注自己的核心業務就完了。
更少的服務代價
這個指的是客戶花銷，也是PaaS對於傳統軟件的優勢。PaaS平臺一旦做完，他肯定已經有平臺了，如果要開發新的功能，可能並不需要佔用更多的資源，只是在原有的資源上增加點業務而已。況且PaaS服務商與客戶更多的是提供服務的續租模式，多一個客戶少一個客戶，其實對於服務器來說並沒有啥壓力，同一個團隊能夠服務與更多的人。
開發更快
就算是往小裏做，如果你有這麼一個PaaS的框架，你想要在上邊直接搞一個業務的話。其實也就是搞點配置，然後作爲一個單機軟件部署，純定製開發也會變得更快。
具體點 我們要做什麼
假設我們現在要做一個人員管理系統，我們一般需要以下內容。
- 增加數據
可以配置一個或者多個新增數據的頁面，點擊保存就保存了數據
- 刪除數據
可以配置個按鈕，點擊一下就把相關數據刪除掉
- 修改數據
可以配置個按鈕，點擊一下出現一個編輯頁面，裏邊會出現對應的數據，你可以修改，然後點擊一下更新，數據就更新了
- 查
-- 列表頁面
你可以在列表頁面，配置幾個篩選項，然後你修改完數據之後，點擊搜索，就會根據你的數據來改變列表內容數據
-- 詳情頁面
你可以在列表頁面點擊名稱（點擊哪個可以配置）然後，就會自動跳轉到詳情頁面
詳情頁面要展示哪些內容也可以通過配置來進行修改
NoCode能力
這個是整個業務的核心，也是PaaS之所以可以將幾個月的工作量濃縮爲數週的原因所在。
其實就是一個簡單想法的轉變，原本我們要實現我上邊畫的幾張圖，都是考改變代碼來實現，比如說列表頁面應該是戰士什麼Title、列表要不要出現選擇框、列表究竟展示那幾列、右上角究竟有什麼按鈕等等。
現在將這些原本需要寫到代碼裏邊的邏輯整理到配置裏邊，然後通過解釋這些配置，渲染出頁面，渲染出邏輯。
LowCode能力
當然了，上述的情況太過於簡單了，基本上就是一個數據庫的內容簡單展示而已，如果我們需要更復雜一點的內容呢？
比如說我們需要輸出這個人的年齡分層（幼兒、少年、青年、中年、老年），我們要怎麼做呢？
很顯然這個狀態不應該被存放在數據庫中的，因爲這個實際上是通過年齡動態計算出來的，過一年之後這個展示狀態可能就會過期了，這個時候我們就需要能夠動態插入邏輯根據年齡計算這幾個值，然後輸出結果。
當然這並不是全部了，其他還有很多需要解決的事情。比如
- 使用配置來實現渲染，配置數據，讀取起來是不是要比寫代碼慢很多？
- 搜索條件可能有很多，怎麼實現這些條件可用呢？
- 如果默認的頁面滿足不了我的需求怎麼辦？
- 業務權限要怎麼處理？總不能進入系統的人都有權限吧？
- 開發完了這個玩意怎麼發佈到線上去？
- ... ...
這個玩意有點龐大，一口氣說不完。這次內容就這麼多，我也只能一邊整理一邊寫博客，這可能會是一個很長，也可能是做不下去很短的系列。
寫的不好，能力有限多多見諒