Java 後端服務開發過程中常用的技術
爲開發團隊選擇一款優秀的 MVC 框架是件難事兒,在衆多可行的方案中決擇需要很高的經驗和水平。你的一個決定會影響團隊未來的幾年。要考慮方面太多：
簡單易用，以提高開發效率。使小部分的精力在框架上，大部分的精力放在業務上。
性能優秀，這是一個最能吸引眼球的話題。
儘量使用大衆的框架（架構師可以自定義輕量級框架，越簡單但能完成業務功能的框架最好，方便進行重構），新招聘來的開發人員技術功底不一致，要按水平最低的人員考慮，減低人員流動再適應的影響。
這是大部分項目優先選擇的條件 基於這些條件 一般選擇輕量級框架爲主，如果架構師無法自定義架構，則優先選擇 Spring（畢竟比較流行）。
但使用 Spring 開發服務應用，需要開發人員有一定的基礎，至少 3 年以上經驗的才能獨自獨擋一面，效率上肯定無法比 5 年以上工作經驗的高。
揭開後端開發過程中可優化區域方向
想優化服務後端 ，首先要了解可優化的模塊，以及框架優化可行性，當前主流框架 Spring、Mybatis，使用開發比較方便，但同時限制了擴展，框架非輕量級，想擴展和修改，則必須要有相當豐富經驗的架構師來處理，且測試時間相當漫長，不利於普通開發人員。
普通開發人員關注的其實只是業務實現，無需考慮其他。比如開發人員無需考慮框架是如何存儲數據到數據庫以及權限具體實現流程等（普通開發人員只需考慮如何實現業務功能，以及業務功能實現的高效合理性），具體的模塊如數據存儲，權限模塊主要有架構師完成設計。
架構師設計成對應的模塊接口，如登錄，架構師只需對外提供登錄接口的詳細信息，開發者只需調用該接口即可完成登錄操作。
至於開發者使用何種框架對接接口，可由架構師設計，這樣開發者只管調用方法，而無需關注框架。（開發者可以在不知道 Spring、Mybatis 框架的前提下完成開發任務）。
故架構師可以考慮將原有的三層架構模式設計成接口-微服務模式，每個功能爲一個接口模塊，這樣部署服務商可以橫向擴展進行負載均衡，方便靈活的進行單個模塊的更新，而無需停止整個服務，做到服務零維護，7*24 小時對外提供服務。
架構師可以分配單個模塊給指定開發者，開發者只需實現單個模塊，單個模塊功能可以使用架構師指定的方法用於實現，只是使用架構師提供的框架進行流程設計，無需編碼即可進行功能開發。
瞭解作者多年開發項目經驗後自定義架構的高效框架
由於本人實在是懶（沒辦法，寫了幾年代碼後發現寫代碼特別累），於是就想着能不能在不寫代碼的前提下把後端功能開發出來，之前一直做 ETL Kettle 開發的工作，瞭解到數據流插件後，發現可以將 Kettle 運行思想應用到 Web 請求開發中，下圖 Kettle 開發界面：
該圖可以完美展示登錄判斷流程，其中
INPUT：接收用戶傳入的參數，用戶名密碼等信息
判斷：用於判斷用戶傳入參數信息
登錄以及用戶信息：獲取用戶基本信息
ADMIN_CHECK：判斷是否是管理員
putCache：放入緩存
通過可視化工具，這樣就可以方便設計出功能流程，小到獲取單記錄信息，大到查詢數據等功能都可以很方便完成。
測試也很方便地直接通過可視化工具傳入請求參數，而無需使用開發工具（Eclipse 等），實際項目開發者無代碼能力者也可以完成分配的功能任務。
流程化工具：
主要設計理念參考了 Kettle 等ETL工具，用於數據流向所處理的系統化模式，並帶入 Web 理念中去。
試想下，一個 Web 請求服務端，服務端需要如何處理？處理後返回給客戶端的數據又需要做什麼處理等等。
分析具體步驟，並把一個個功能劃分成積木那樣，先考慮最小化模塊。
如登陸模塊：
接收傳入的參數
判斷用戶名是否存在
判斷密碼是否存在
判斷用戶名格式，密碼格式是否正確
判斷驗證碼
查找數據庫是否存在用戶名
查找到用戶，判斷用戶密碼與輸入密碼是否一致（密碼判斷）
判斷成功後生成 token，返回給用戶，失敗的話 返回錯誤信息
簡單的登錄流程簡化成上述 8 個處理步驟，分析下這八個步驟，每個步驟需要的插件可以歸類爲：
INPUT 接收參數插件
判斷過濾插件
數據格式驗證插件
數據庫記錄查詢插件
返回信息插件
常量插件
如下圖：
我們看到圖中主要使用了幾種插件，如 INPUT（接收用戶輸入的參數），配置內容如下圖：
增加常量：設置常量用戶輸出信息，配置如下圖：
過濾插件：判斷字段值，如下圖：
數據格式驗證：判斷字段值的格式是否符合要求，如下圖：
數據查詢插件：查詢數據庫表記錄值，如下圖：
輸出內容選擇值：選擇需要進行下一步操作的字段，如下圖：
現在我們發現，原本需要進行代碼編寫進行用戶登錄驗證操作的功能，現在只需要動手配置下具體實施流程即可，無需編碼，是不是很方便，而且不需要有開發經驗的人即可進行配置。
如何帶領 Java 團隊開發並效率最大化
項目架構師和管理者（最好是同一人，這樣對項目瞭解通透）應考慮團隊人員的水平情況，並以最新人開發者爲基準設計框架，而不是一味的讓開發者迎合架構師，架構師應站在產品經理的方向上考慮，將開發者當做產品用戶 設計出合理的產品給開發者使用。
另外架構師要儘可能的”懶”（這裏指通過工具就可以完成工作，而無需大量編碼），只有這樣才能想着如何調高效率，而不是每日加班來凸顯自己，一直以來我不認可加班，沒有什麼事情需要一個加班就處理好，如果需要那也是線上運維出現的緊急情況，而不是開發過程中。
後臺開發效率提高取決於以下方面：
1. 人員配置
理論上項目配置越多的開發人員開發效率越高，但盲目的增加人員不緊增加管理人員的負擔，且軟件工程配置人員有一定規則，不是開發人員越多越好。
2. 框架選型
選擇合適框架的前提下能更好的提高開發效率,但是框架的選型要考慮同組開發人員的整體水平，框架要約簡單越好，簡而不繁最優 ，還要兼顧團隊中的測試 需求等人員，如果框架選型上可以讓測試和需求人員一同參與開發（一般只要求測試人員可以一同開發，如果框架選型後可以讓需求人員一同參與開發則最好，畢竟開發項目時壓榨人力資源是每個管理者追求的）。
3. 代碼工作量
項目中編碼必可不少，但如果能儘量減少開發的代碼量，讓人員有更多時間關注業務方向（畢竟開發項目主要還是與業務相關聯緊密），既然不想寫多餘代碼，自然而然想到通過可視化操作來實現（現在 APP 開發都可視化，幾分鐘就可以生成一個），架構師就主要考慮開發出可以讓開發人員可視化工作的框架。
詳細效率：
人員配置方面，我所在項目目前配備人員：
架構師兼開發工程師（A），開發工程師（1-2 名，B 和 C）無開發經驗或從測試組以及其他部門借調（沒辦法，公司不給多配人），測試人員以及需求人員和其他組公用。
鑑於以上人員組合，如果選用 Spring MVC 等框架的情況下，只有A有能力快速開發且需要編寫大量代碼，B 和 C 需要先提前對其進行培訓，培訓結束後開始開發，效率肯定不如有經驗的開發人員，即使 B 和 C 是同 A 一樣的開發能力，三人同時開發編碼量也比較大。
此時如果 A 開發一工具可以讓 B 和 C 可視化編程操作，如當前所在項目使用的架構，通過工具 T_VISUAL（A 開發出來的可視化工具），B 和 C 完全可以在無基礎開發能力的情況完成功能開發，如下圖：
這是參考開源軟件 ETL 工具 KETTLE 實現模式，開發了一條後臺程序流程工具，比如界面上 VALI_LOGIN_CHECK 這個表示一個功能塊，該功能可以作爲一個簡單判斷功能塊，其中 INPUT 插件表示接收 WEB REQUEST 請求的參數，如下圖：
這三個參數是從頁面請求傳入，後續步驟分別判斷用戶名密碼驗證是否符合驗證要求。
用以上工具此時 A 只需全力開發需要的功能插件，而 B 與 C 只需要規劃業務功能塊，比如項目中需要的登錄、註冊、獲取用戶信息、獲取產品列表等功能模塊，只需要創建對應的功能模塊即可。B 和 C 無需編碼，只需可視化設計流程即可，後續只需安排好模塊功能，人員安排可以成幾何倍擴展，而無需擔心開發人員能力問題，藉助工具，只需要基礎開發人員，具有一定的邏輯能力即可。
如果架構師沒有開發出對應的可視化工具，則建議架構師設計時應儘量先將各單元操作類獨立成單個插件（類似於上圖工具的插件步驟），這樣編寫代碼的時候，無需編寫功能塊的詳細內容，只需編寫功能流程，即編寫時。
如下圖：
其中 A 只需要編寫功能塊的內容，B 和 C 只需要調用功能塊重的模塊類進行拼接。項目難點在功能塊實現上，而具體模塊實現功能無需考慮具體功能實現，只需考慮業務流程即可，對開發能力要求較低，這樣 A 就可以帶領 B 和 C 進行開發，且 A 不需要對 B 和 C 進行詳細指導，只需要再他們覺得有問題的時候進行解答即可。每個人都可以更加專注，如果後續功能模塊需要增加的話，只需要增加和 B、C 同等水平的即可，而無需增加 A 類工程師。大大降低人員成本，開發效率上也有高效率。
Web 框架上選用 Spring MVC 雖然符合主流，但對人員要求比較高，爲了兼顧團隊整體可以考慮一些輕量化框架如 JFinal（現在項目所用），對人員要求較低，且適合初級開發人員。
以上是本人總結的一些經驗以及個人帶領團隊開發中總結的一些方法，主要兼顧下團隊中的其他人員，畢竟高大上的框架看上去完美，但是確是開發人員的噩夢，尤其是要在編寫代碼量巨大的份上。
後續
多年的開發經驗總結下來就是，程序員需要懶，因爲只有懶才能開發出高效的工具以及流程，你看一個開發人員每日編程 代碼量巨大，看似勤奮，但是卻比不上一個使用工具的開發人員一半的工作量，有時候開發停下來要思考下如何將當前的工作流程簡化，編寫的代碼可以儘可能的小而精，從而開發出可以複用的工具。
最後附上我的個人公衆號：
