【效率專精系列】我有一個夢想：提升開發效率，晚上回家吃雞

以前零零散散寫了幾篇文章，主要是實際開發過程當中一些效率痛點和相應的改善方法。今天抽空溫故知新，把以前的內容串起來，作了個小總結，即《效率專精系列》小系列的總集篇。

回顧項目開發流程

開發一個新項目時，開發流程大概分紅如下幾步：

1. 設計方案，並落地成設計文檔
2. 設計方案評審
3. 任務分拆
4. 和上下游規定接口（服務、先後端等）
5. 代碼開發
6. 開發自測
7. 上下游聯調（服務、先後端等）
8. 提交QA測試

效率可改進的點

S1. 設計方案，並落地成設計文檔

公司內部使用Wiki（XConfluence）管理全部文檔，因爲互聯網產品的大部分開發模式都偏向於面向數據庫編程，設計文檔裏ER圖是展示設計的重要工具。可是繪製ER圖是個挺費勁的活，不是說自帶的draw.io組件很差用，而是說ER圖和代碼（Sql語句或Java代碼）不能互相轉化，二者的內容格式高度重合，卻只能人工轉化。

目前個人方式是先在Intellij Idea中寫好持久化對象（PO），用POJO to Text插件把POJO轉化爲文本並複製到系統剪切板中，而後複製到ER圖裏，節省了重複錄入類名和字段名的時間。

舉個栗子，PO類的自定義文本形式爲「PO \nid \nupdateTime」。

Class PO {
        private int id;
        private Date updateTime;
        //getter/setter
    }

S4. 和上下游規定接口（服務、先後端等）/ S6. 開發自測

上下游服務之間有很完善的並行開發方案，即基於接口的開發，經過帶有版本號的jar包來解耦雙方具體實現的開發。但若是是先後端之間規定接口，通常須要先寫接口文檔，再寫代碼，與上面相似，其中不少內容須要人工重複錄入，好比說URI、Param、Header、Body體等。

利用API統一描述語言OpenAPI和相應的工具Swagger2可在文檔和代碼之間搭起一座橋樑。另外該工具也可節約自測中的部分錄入工做，如錄入URL和Param。

【效率專精系列】善用API統一描述語言提高RestAPI開發效率
5分鐘搞定Swagger2環境配置與使用

考慮到篇幅較長的文檔反覆修改的狀況，要快速找到API修改點比較困難。

目前個人方式是利用版本管理和文本比較功能：比方說把API文檔和代碼一塊兒放在git倉庫，或者使用其餘帶版本管理的文檔庫；使用git倉庫自帶的文本比較功能，或者在線的代碼比較網站。

文本比較網站	去除前導空格	分享給他人	其餘
www.diffnow.com	能夠	能夠	界面風格原始
www.diffchecker.com	不能夠	能夠
www.newjson.com/Static/Tools/Diff.html	能夠	不能夠

S5. 代碼開發

互聯網公司常見的ORM組件再也不是重型的Hibernate，而是輕量級的Mybatis（其實都不算ORM了，最可能是Sql模板）。Mybatis中我認爲最繁瑣的工做就是寫業務Sql了，基本上是getXXXByYYYZZZ這種形式，要麼再加上分頁，類型特徵十分明顯。

目前個人方式是利用Intellij Idea的Mybatis插件，把Mybatis Mapper類中的Java接口轉化成對應的Sql語句。在不考慮優化的狀況下，這種類型的Sql若是能自動生成就能節約很多人力，畢竟Sql語句比Java接口聲明長多了。

【效率專精系列】善用插件提高MyBatis開發效率

S7. 上下游聯調（服務、先後端等）

一般上下游都把本身的分支部署到beta環境來進行聯調，存在分支衝突的風險；並且若是代碼質量不高的話聯調過程當中須要反覆更新代碼，因爲beta環境不支持熱部署，更新代碼的時間成本很高。

目前個人方式是不論是Rpc服務仍是URL，把聯調放在雙方的本地機器上進行，這樣熱更新、熱部署都沒問題了。

【效率專精系列】Beta環境不須要，本地聯調拯救開發效率
【效率專精系列】幾種常見的JVM熱部署技術及實現難點淺談

小詩云

身在互聯網，加班易，不加班難，且行且珍惜。