Java Web 后臺(tái)開發(fā)效率提高

Java 后端服務(wù)開發(fā)過程中常用的技術(shù)

為開發(fā)團(tuán)隊(duì)選擇一款優(yōu)秀的 MVC 框架是件難事兒,在眾多可行的方案中決擇需要很高的經(jīng)驗(yàn)和水平。你的一個(gè)決定會(huì)影響團(tuán)隊(duì)未來的幾年。要考慮方面太多：

1. 簡單易用，以提高開發(fā)效率。使小部分的精力在框架上，大部分的精力放在業(yè)務(wù)上。

2. 性能優(yōu)秀，這是一個(gè)最能吸引眼球的話題。

3. 盡量使用大眾的框架（架構(gòu)師可以自定義輕量級(jí)框架，越簡單但能完成業(yè)務(wù)功能的框架最好，方便進(jìn)行重構(gòu)），新招聘來的開發(fā)人員技術(shù)功底不一致，要按水平最低的人員考慮，減低人員流動(dòng)再適應(yīng)的影響。

這是大部分項(xiàng)目優(yōu)先選擇的條件 基于這些條件 一般選擇輕量級(jí)框架為主，如果架構(gòu)師無法自定義架構(gòu)，則優(yōu)先選擇 Spring（畢竟比較流行）。

但使用 Spring 開發(fā)服務(wù)應(yīng)用，需要開發(fā)人員有一定的基礎(chǔ)，至少 3 年以上經(jīng)驗(yàn)的才能獨(dú)自獨(dú)擋一面，效率上肯定無法比 5 年以上工作經(jīng)驗(yàn)的高。

揭開后端開發(fā)過程中可優(yōu)化區(qū)域方向

想優(yōu)化服務(wù)后端 ，首先要了解可優(yōu)化的模塊，以及框架優(yōu)化可行性，當(dāng)前主流框架 Spring、Mybatis，使用開發(fā)比較方便，但同時(shí)限制了擴(kuò)展，框架非輕量級(jí)，想擴(kuò)展和修改，則必須要有相當(dāng)豐富經(jīng)驗(yàn)的架構(gòu)師來處理，且測(cè)試時(shí)間相當(dāng)漫長，不利于普通開發(fā)人員。

普通開發(fā)人員關(guān)注的其實(shí)只是業(yè)務(wù)實(shí)現(xiàn)，無需考慮其他。比如開發(fā)人員無需考慮框架是如何存儲(chǔ)數(shù)據(jù)到數(shù)據(jù)庫以及權(quán)限具體實(shí)現(xiàn)流程等（普通開發(fā)人員只需考慮如何實(shí)現(xiàn)業(yè)務(wù)功能，以及業(yè)務(wù)功能實(shí)現(xiàn)的高效合理性），具體的模塊如數(shù)據(jù)存儲(chǔ)，權(quán)限模塊主要有架構(gòu)師完成設(shè)計(jì)。

架構(gòu)師設(shè)計(jì)成對(duì)應(yīng)的模塊接口，如登錄，架構(gòu)師只需對(duì)外提供登錄接口的詳細(xì)信息，開發(fā)者只需調(diào)用該接口即可完成登錄操作。

至于開發(fā)者使用何種框架對(duì)接接口，可由架構(gòu)師設(shè)計(jì)，這樣開發(fā)者只管調(diào)用方法，而無需關(guān)注框架。（開發(fā)者可以在不知道 Spring、Mybatis 框架的前提下完成開發(fā)任務(wù)）。

故架構(gòu)師可以考慮將原有的三層架構(gòu)模式設(shè)計(jì)成接口-微服務(wù)模式，每個(gè)功能為一個(gè)接口模塊，這樣部署服務(wù)商可以橫向擴(kuò)展進(jìn)行負(fù)載均衡，方便靈活的進(jìn)行單個(gè)模塊的更新，而無需停止整個(gè)服務(wù)，做到服務(wù)零維護(hù)，7*24 小時(shí)對(duì)外提供服務(wù)。

架構(gòu)師可以分配單個(gè)模塊給指定開發(fā)者，開發(fā)者只需實(shí)現(xiàn)單個(gè)模塊，單個(gè)模塊功能可以使用架構(gòu)師指定的方法用于實(shí)現(xiàn)，只是使用架構(gòu)師提供的框架進(jìn)行流程設(shè)計(jì)，無需編碼即可進(jìn)行功能開發(fā)。

了解作者多年開發(fā)項(xiàng)目經(jīng)驗(yàn)后自定義架構(gòu)的高效框架

由于本人實(shí)在是懶（沒辦法，寫了幾年代碼后發(fā)現(xiàn)寫代碼特別累），于是就想著能不能在不寫代碼的前提下把后端功能開發(fā)出來，之前一直做 ETL Kettle 開發(fā)的工作，了解到數(shù)據(jù)流插件后，發(fā)現(xiàn)可以將 Kettle 運(yùn)行思想應(yīng)用到 Web 請(qǐng)求開發(fā)中，下圖 Kettle 開發(fā)界面：

該圖可以完美展示登錄判斷流程，其中

• INPUT：接收用戶傳入的參數(shù)，用戶名密碼等信息

• 判斷：用于判斷用戶傳入?yún)?shù)信息

• 登錄以及用戶信息：獲取用戶基本信息

• ADMIN_CHECK：判斷是否是管理員

• putCache：放入緩存

通過可視化工具，這樣就可以方便設(shè)計(jì)出功能流程，小到獲取單記錄信息，大到查詢數(shù)據(jù)等功能都可以很方便完成。

測(cè)試也很方便地直接通過可視化工具傳入請(qǐng)求參數(shù)，而無需使用開發(fā)工具（Eclipse 等），實(shí)際項(xiàng)目開發(fā)者無代碼能力者也可以完成分配的功能任務(wù)。

流程化工具：

主要設(shè)計(jì)理念參考了 Kettle 等ETL工具，用于數(shù)據(jù)流向所處理的系統(tǒng)化模式，并帶入 Web 理念中去。

試想下，一個(gè) Web 請(qǐng)求服務(wù)端，服務(wù)端需要如何處理？處理后返回給客戶端的數(shù)據(jù)又需要做什么處理等等。

分析具體步驟，并把一個(gè)個(gè)功能劃分成積木那樣，先考慮最小化模塊。

如登陸模塊：

1. 接收傳入的參數(shù)

2. 判斷用戶名是否存在

3. 判斷密碼是否存在

4. 判斷用戶名格式，密碼格式是否正確

5. 判斷驗(yàn)證碼

6. 查找數(shù)據(jù)庫是否存在用戶名

7. 查找到用戶，判斷用戶密碼與輸入密碼是否一致（密碼判斷）

8. 判斷成功后生成 token，返回給用戶，失敗的話 返回錯(cuò)誤信息

簡單的登錄流程簡化成上述 8 個(gè)處理步驟，分析下這八個(gè)步驟，每個(gè)步驟需要的插件可以歸類為：

1. INPUT 接收參數(shù)插件

2. 判斷過濾插件

3. 數(shù)據(jù)格式驗(yàn)證插件

4. 數(shù)據(jù)庫記錄查詢插件

5. 返回信息插件

6. 常量插件

如下圖：

我們看到圖中主要使用了幾種插件，如 INPUT（接收用戶輸入的參數(shù)），配置內(nèi)容如下圖：

增加常量：設(shè)置常量用戶輸出信息，配置如下圖：

過濾插件：判斷字段值，如下圖：

數(shù)據(jù)格式驗(yàn)證：判斷字段值的格式是否符合要求，如下圖：

數(shù)據(jù)查詢插件：查詢數(shù)據(jù)庫表記錄值，如下圖：

輸出內(nèi)容選擇值：選擇需要進(jìn)行下一步操作的字段，如下圖：

現(xiàn)在我們發(fā)現(xiàn)，原本需要進(jìn)行代碼編寫進(jìn)行用戶登錄驗(yàn)證操作的功能，現(xiàn)在只需要?jiǎng)邮峙渲孟戮唧w實(shí)施流程即可，無需編碼，是不是很方便，而且不需要有開發(fā)經(jīng)驗(yàn)的人即可進(jìn)行配置。

如何帶領(lǐng) Java 團(tuán)隊(duì)開發(fā)并效率最大化

項(xiàng)目架構(gòu)師和管理者（最好是同一人，這樣對(duì)項(xiàng)目了解通透）應(yīng)考慮團(tuán)隊(duì)人員的水平情況，并以最新人開發(fā)者為基準(zhǔn)設(shè)計(jì)框架，而不是一味的讓開發(fā)者迎合架構(gòu)師，架構(gòu)師應(yīng)站在產(chǎn)品經(jīng)理的方向上考慮，將開發(fā)者當(dāng)做產(chǎn)品用戶 設(shè)計(jì)出合理的產(chǎn)品給開發(fā)者使用。

另外架構(gòu)師要盡可能的”懶”（這里指通過工具就可以完成工作，而無需大量編碼），只有這樣才能想著如何調(diào)高效率，而不是每日加班來凸顯自己，一直以來我不認(rèn)可加班，沒有什么事情需要一個(gè)加班就處理好，如果需要那也是線上運(yùn)維出現(xiàn)的緊急情況，而不是開發(fā)過程中。

后臺(tái)開發(fā)效率提高取決于以下方面：

1. 人員配置

理論上項(xiàng)目配置越多的開發(fā)人員開發(fā)效率越高，但盲目的增加人員不緊增加管理人員的負(fù)擔(dān)，且軟件工程配置人員有一定規(guī)則，不是開發(fā)人員越多越好。

2. 框架選型

選擇合適框架的前提下能更好的提高開發(fā)效率,但是框架的選型要考慮同組開發(fā)人員的整體水平，框架要約簡單越好，簡而不繁最優(yōu) ，還要兼顧團(tuán)隊(duì)中的測(cè)試 需求等人員，如果框架選型上可以讓測(cè)試和需求人員一同參與開發(fā)（一般只要求測(cè)試人員可以一同開發(fā)，如果框架選型后可以讓需求人員一同參與開發(fā)則最好，畢竟開發(fā)項(xiàng)目時(shí)壓榨人力資源是每個(gè)管理者追求的）。

3. 代碼工作量

項(xiàng)目中編碼必可不少，但如果能盡量減少開發(fā)的代碼量，讓人員有更多時(shí)間關(guān)注業(yè)務(wù)方向（畢竟開發(fā)項(xiàng)目主要還是與業(yè)務(wù)相關(guān)聯(lián)緊密），既然不想寫多余代碼，自然而然想到通過可視化操作來實(shí)現(xiàn)（現(xiàn)在 APP 開發(fā)都可視化，幾分鐘就可以生成一個(gè)），架構(gòu)師就主要考慮開發(fā)出可以讓開發(fā)人員可視化工作的框架。

詳細(xì)效率：

人員配置方面，我所在項(xiàng)目目前配備人員：

架構(gòu)師兼開發(fā)工程師（A），開發(fā)工程師（1-2 名，B 和 C）無開發(fā)經(jīng)驗(yàn)或從測(cè)試組以及其他部門借調(diào)（沒辦法，公司不給多配人），測(cè)試人員以及需求人員和其他組公用。

鑒于以上人員組合，如果選用 Spring MVC 等框架的情況下，只有A有能力快速開發(fā)且需要編寫大量代碼，B 和 C 需要先提前對(duì)其進(jìn)行培訓(xùn)，培訓(xùn)結(jié)束后開始開發(fā)，效率肯定不如有經(jīng)驗(yàn)的開發(fā)人員，即使 B 和 C 是同 A 一樣的開發(fā)能力，三人同時(shí)開發(fā)編碼量也比較大。

此時(shí)如果 A 開發(fā)一工具可以讓 B 和 C 可視化編程操作，如當(dāng)前所在項(xiàng)目使用的架構(gòu)，通過工具 T_VISUAL（A 開發(fā)出來的可視化工具），B 和 C 完全可以在無基礎(chǔ)開發(fā)能力的情況完成功能開發(fā)，如下圖：

這是參考開源軟件 ETL 工具 KETTLE 實(shí)現(xiàn)模式，開發(fā)了一條后臺(tái)程序流程工具，比如界面上 VALI_LOGIN_CHECK 這個(gè)表示一個(gè)功能塊，該功能可以作為一個(gè)簡單判斷功能塊，其中 INPUT 插件表示接收 WEB REQUEST 請(qǐng)求的參數(shù)，如下圖：

這三個(gè)參數(shù)是從頁面請(qǐng)求傳入，后續(xù)步驟分別判斷用戶名密碼驗(yàn)證是否符合驗(yàn)證要求。

用以上工具此時(shí) A 只需全力開發(fā)需要的功能插件，而 B 與 C 只需要規(guī)劃業(yè)務(wù)功能塊，比如項(xiàng)目中需要的登錄、注冊(cè)、獲取用戶信息、獲取產(chǎn)品列表等功能模塊，只需要?jiǎng)?chuàng)建對(duì)應(yīng)的功能模塊即可。B 和 C 無需編碼，只需可視化設(shè)計(jì)流程即可，后續(xù)只需安排好模塊功能，人員安排可以成幾何倍擴(kuò)展，而無需擔(dān)心開發(fā)人員能力問題，借助工具，只需要基礎(chǔ)開發(fā)人員，具有一定的邏輯能力即可。

如果架構(gòu)師沒有開發(fā)出對(duì)應(yīng)的可視化工具，則建議架構(gòu)師設(shè)計(jì)時(shí)應(yīng)盡量先將各單元操作類獨(dú)立成單個(gè)插件（類似于上圖工具的插件步驟），這樣編寫代碼的時(shí)候，無需編寫功能塊的詳細(xì)內(nèi)容，只需編寫功能流程，即編寫時(shí)。

如下圖：

其中 A 只需要編寫功能塊的內(nèi)容，B 和 C 只需要調(diào)用功能塊重的模塊類進(jìn)行拼接。項(xiàng)目難點(diǎn)在功能塊實(shí)現(xiàn)上，而具體模塊實(shí)現(xiàn)功能無需考慮具體功能實(shí)現(xiàn)，只需考慮業(yè)務(wù)流程即可，對(duì)開發(fā)能力要求較低，這樣 A 就可以帶領(lǐng) B 和 C 進(jìn)行開發(fā)，且 A 不需要對(duì) B 和 C 進(jìn)行詳細(xì)指導(dǎo)，只需要再他們覺得有問題的時(shí)候進(jìn)行解答即可。每個(gè)人都可以更加專注，如果后續(xù)功能模塊需要增加的話，只需要增加和 B、C 同等水平的即可，而無需增加 A 類工程師。大大降低人員成本，開發(fā)效率上也有高效率。

Web 框架上選用 Spring MVC 雖然符合主流，但對(duì)人員要求比較高，為了兼顧團(tuán)隊(duì)整體可以考慮一些輕量化框架如 JFinal（現(xiàn)在項(xiàng)目所用），對(duì)人員要求較低，且適合初級(jí)開發(fā)人員。

以上是本人總結(jié)的一些經(jīng)驗(yàn)以及個(gè)人帶領(lǐng)團(tuán)隊(duì)開發(fā)中總結(jié)的一些方法，主要兼顧下團(tuán)隊(duì)中的其他人員，畢竟高大上的框架看上去完美，但是確是開發(fā)人員的噩夢(mèng)，尤其是要在編寫代碼量巨大的份上。

后續(xù)

多年的開發(fā)經(jīng)驗(yàn)總結(jié)下來就是，程序員需要懶，因?yàn)橹挥袘胁拍荛_發(fā)出高效的工具以及流程，你看一個(gè)開發(fā)人員每日編程 代碼量巨大，看似勤奮，但是卻比不上一個(gè)使用工具的開發(fā)人員一半的工作量，有時(shí)候開發(fā)停下來要思考下如何將當(dāng)前的工作流程簡化，編寫的代碼可以盡可能的小而精，從而開發(fā)出可以復(fù)用的工具。

最后附上我的個(gè)人公眾號(hào)：