1.easyCode介紹：
1.1 基本介紹:
EasyCode，一款IDEA插件，可以快捷的将資料庫實體的生成基于springMVC的後端工程代碼。 并且它提供了自定義模闆配置的強大功能。 它的強大主要源自于: IDEA強大的虛拟檔案體系; Velocity模闆解析器;
項目位址:EasyCode項目位址
1.2 我認為的弊端:
雖然具有了Idea的強大功能，但這将導緻一些問題：
與IDEA緊耦合，開發的學習成本高。 ---> 需要具有Idea插件開發的知識;
模闆代碼持久化受到IDEA的禁锢，擴充成本高； ----> 如 将模闆檔案 暫存到 SSO上需要單獨開發，且需要與IDEA體系相容;
基于配置檔案的方式不友善管理檔案，且不能夠回溯檔案。
這幾個問題将導緻一個嚴重的問題： 代碼生成将禁锢于 生成相對簡單的業務代碼（擴充程度有限），這将大大降低 “代碼生成” 的威力。 它的作用絕不僅限于此。 隻要與資料有關的代碼都可以生成，這不應該是理論上來說，這本應該是一個現實。
2.jeecgBoot介紹及我的改動:
2.1 基本介紹:
它是基于SpringBoot2.1與Vue3 的一套前後端的 中大型的企業級背景系統。 本次改動基于 jeecgBoot2.2的開源版本，僅授權個人學習使用，不授權商用。
jeecgBoot 也具有低代碼生成平台，功能也十分強大，支援數種代碼模闆的生成。
官網位址：官網位址
線上示範位址: jeecgBoot線上示範位址
2.2 主要使用的功能:
1.基于jeecgBoot前端Vue的動态元件加載政策，采用原有的代碼開發風格;
2.采用 jeecgBoot的 角色-組織-使用者-權限 的安全認證和授權體系；
2.3 開發遐想:
如果未來長期我還有精力和心情搗鼓的話，想進行以下的一些開發(這裡記錄一下)：
1.安全架構，将springSecurity內建進來，通過配置的方式進行動态選取；
2.支付子產品，将以前練習的支付體系內建進系統；
3.目前已有CAS單點，希望能夠将 oauth2的單點也內建進來;
2.4 相關改動:
1.将架構中 所有的 createBy,updateBy 改為 createUser,updateUser, 邏輯删除字段 統一為 effective;
2.sysUser表 和 sysPermission 表，所有的Boolean 字段 改為 String字段;
3.生成一套 postgresql 的資料庫代碼; 開發主要相容 mysql 跟 postgresql，原來自帶的 oracle與sqlServer，未修改，未測試;
3.代碼生成服務:
3.1 相關概念:
1.資料源： 廣義的資料源，并非java中特有的名詞，表示一切能夠提供資料流的資源。 具有代表性的有: 資料庫，json檔案,excel檔案，csv檔案......
2.資料源配置：來源于codeGenerator中的概念，資料源需要經過配置才能參與代碼生成流程。 在這個流程，可以對原始資料源進行強有力的修飾，比如 名稱轉換，表單元素生成，表格元素生成，資料填充......
3.映射配置：根據codeGenerate編碼規範，這裡做一個強制性要求 資料源元素必須具備一個原始類型，通過映射配置将原始類型轉換為java類型或者其它目标領域類型; 比如: mysql的映射規範與 postgresql規範可能存在差别，可以通過對映射配置進行多個場景的相容;
4.模闆域：針對于特定項目工程的模闆集合，這是本次代碼生成的核心要義之一。這也是設計的初衷之一，将模闆 B/S架構化，就是要滿足： 既能生成簡單的業務代碼，也能生成複雜項目體系代碼。從某種意義上來說，此時咱開發的是模闆，而非代碼。 此時，ctrl + c 與 ctrl +v 的神奇組合 發揮的可就不是1+1>2的效果了......
5.模闆宏：為模闆域中的模闆提供全局服務的 宏函數，這也是本次代碼生成的核心要義之一。它的提煉是對模闆本身的一個架構優化，可以大大提高腳本代碼的内聚度，思路來自于codeGenerate。
3.2 設計思路:
3.3 特點:
1.将資料源抽象化，支援資料庫源，json源，excel源（除了資料庫源外，其餘源暫未開發）;
2.模闆域，模闆宏，映射配置，資料源配置 均有注釋，理論上來說，越是複雜的功能，越需要更多的注釋，越精細的注釋，越有利于長期發展。 這是它 保持 強大與優雅的必要條件。
3.模闆引擎考慮了velocity與 freemarker，原因在于 springboot推薦使用freemarker，且velocity已經很久沒有維護了。 通過配置的方式可以實作模闆的切換。 (目前暫未進行freemarker的調試)。
3.4 操作流程:
3.4.1 進入jeecgBoot開發平台:
3.4.2 管理資料庫源:
3.4.2 資料源配置（同映射配置）:
3.4.3 模闆域配置（同模闆宏配置）：
3.4.4 開始生成
3.5 應用場景:
3.5.1 正常業務開發:
用于輔助生産，如生成正常的單表操作(注，這個是可以在模闆進行擴充的，生成主子表及 樹表 并不難)。 當然了，這是每個代碼生成插件都具備的功能。
差別在于，它的功能強大與否，取決于你的經驗與能力，開發者。
比如： 正常的前後端分離的javaweb項目可能會包括這樣的一些檔案:
mapper.xml映射檔案,dao層,service層,serviceImpl層,controller層
component.vue主元件，addOrUpdate.vue 附加元件;
當然了，這取決你自己;
3.5.2 設計模式模闆(設想):
衆所周知，java是一門面向對象的語言。 面向對象高階有一個設計模式的概念，它應該可以代表程式開發設計的優雅了。長期我們都是以各種部落格來補充知識，看了忘，忘了看。 為什麼呢？ 因為我們沒辦法用呀！
學以緻用，我們才能融會貫通。
當我們将設計模式抽象為一個個模闆，通過逐漸疊代，達到一個度，也就是它夠成熟了的時候，我們便可以使用它。 那時候，我們寫優雅的高品質代碼，便可以信手拈來了，是吧！
3.5.3 基于hybird的混合開發(設想):
我們知道，移動端開發的混合開發炒的火熱。舉個例子，uniApp可以一套代碼多端使用，包括：android,ios,h5,各個平台的小程式,且性能可控。
excuse me? 這可是産品哦，想想某天，我們能夠在兩個小時内生成一套産品的激動吧！(隻要經驗足夠，反複實踐疊代，生成健壯性和功能性強的模闆，那是一點問題沒有)，畢竟,人可能出錯，機器可不會。
4.參與開發:
4.1 目的:
計算機技術更新疊代太快，要想不被淘汰，必須成為一個終生持續學習者，這就要求我們投入更多的時間和精力。如果隻是為了上班謀生，我想這個動力是遠遠不夠的，也是不值當的。
但是我們能夠參與一個有趣的作品，情況可能就不一樣了。就像藝術家欣賞精美的藝術品，我們也會欣賞自己一手創造出來的作品。
4.2 條件:
*需要對計算機感興趣;
*需要具備vue全家桶技術 或者 javaEE後端開發技術;
4.3 途徑:
協作将基于 gitee進行(考慮使用官方推薦的pull+request的方式):
示範位址: www.automannn.cn/atm_front
5.關于我以及設計初衷：
5.1 關于我:
網名:Automannn，諧音為凹凸曼,寓意自覺，主動的人。家貧，末流二本學校，計算機邊緣學科。由于大學期間受到其它部落客的鼓舞，從大二上期開始寫部落格，記錄個人的成長。這點可以從上方部落客資訊及發帖記錄可以看出來。于今年畢業，目前從事軟體開發工作。
5.2 設計初衷:
大學期間由于對技術比較感興趣，是以幾年來大部分的空餘時間都花費在了學習新技術上面。但是大都是憑着一腔熱情猛的學習一陣子，熱情退去後，便所剩無幾了。