大量實踐發現後台管理程式，其實90%的**都是相同的，當然是在拋棄複雜邏輯業務的情況下，那麼如何能高效的節約這些時間呢，那就是接下來我要說的，對於後台系統自動生成的一些思考。
適用情景：
1、表編號id為自增（基於現在大部分表編號都是自增的情況）；
2、沒有太複雜業務關聯關係，比如表的某乙個字段，儲存了乙個json物件，為了平衡後台使用者使用，需要友好的分段展示給使用者的定製ui介面；還比如表中儲存了外來鍵的多個id，但為了方便使用者使用，只能已標籤name的方式，給使用者展示，等等這些超強業務黏合邏輯的情景，是不能被滿足的；
特殊說明：
先階段任何自動化的程式都是為了輔助開發，而不是替代開發的，因為任何人都不需要簡單並且千篇一律的系統。
進入正文：
最核心的就是下面這個思維導向圖：
只要解決了上述所有問題，就解決了自動生成的問題。
解決方案：
生成系統一定是可配置行的，需要用配置來替代編碼，並且他一定是基於某個模板的，不同的程式生成的**也是不同的，比如nodejs就是html和控制器、asp.net則是頁面加擴充套件類。
實現思路：
1.配置模板，提取生成迴圈標籤；
2.配置資料庫，先連線上資料庫；
3.列出資料庫下的所有表，開發人員選著相應的表，配置生成目標；
4.配置查詢條件、列表展示列和順序、配置新增/修改模板；
5.迴圈替換模板，生成模板；
到此就開發完成了。
以上為是鄙人對於後台系統生成的一點思考，願為大家提供一些幫助或者一些靈感！最後祝週末愉快！
關於makefile的一點思考
在gnu編譯工具軟體中，如果對單一的原始檔進行編譯，可執行指令如下 gcc o x x.c 此指令會將原始檔編譯為目標檔案。若是對執行緒類檔案進行編譯，則在末尾加上 lpthread指令。但若是對多檔案進行編譯，即若是編譯的目標檔案同時包含另一檔案中的函式。則在編譯的時候需將另一檔案加到編譯原始檔中...
關於指標的一點思考
指標是乙個變數，所不同的是，它存的是位址。因為資料型別決定著如何解釋這個位址 位元組數和操作 因此根據的資料型別的不同，指標又有不同的型別。某個物件 a 的位址範圍為 a,a size n 其中size n是a所佔的位元組數 比如乙個一維陣列int a 10 位址範圍為 a,a 10 sizeof ...
關於演算法的一點思考。。。
關於演算法的一點思考。在實踐過程中，我發現 有時候要解決乙個問題，可以設計幾個演算法分步完成任務，這樣處理起來比較簡單，但是情況並非總是如此，有時，我們需要將幾個步驟放在同乙個演算法內連帶處理，這樣才比較容易處理問題。我還發現，有時候，解決問題的演算法，是被發現出來的，並加以一步一步的檢驗才得以確定...