零基礎-項目開發經驗分享

前段時間分配到一個支付相關的需求，一個需要和前端對接的項目，需要涉及到前後端對接的問題。爲了可擴展性，決定將支付項目獨立爲一個新的服務。新創建的項目，不熟悉的童鞋可能會遇到一堆的坑，這邊博主簡單分享一下，自己的開發經驗和準則。

確定需求：

在開發之前，我們首先要明確需求，需求中到底涉及到哪些業務，哪些流程。一定要先搞清楚才能進行實際代碼的開發，否則代碼可能有推到重來的風險（那個時候就等着使勁加班吧~）。

理解需求最好的方式就是將需求轉化爲流程圖，這樣可以一目瞭然的知道需要要開發哪些內容。這邊我推薦大家使用viso來畫流程圖，效果圖如下所示：

接口細分：

一般來說公司爲了保證項目的進度，需要指定每一個需求的開發時間。那問題來了，你領導肯定會問你，這個需求大概多久可以開發完成。這個時候你會一臉懵逼，說多了會挨批，說少了又延期。這個時候我們就需要對需求進行細分，最好可以細分到接口級別，然後你根據細分的接口，預估開發時間就可以了。這邊介紹一個面板工具：leangoo

這樣做的好處是：

可以清晰明瞭的知道自己具體要做哪些事情
可以精確的把控自己的開發進度
可以明確整個需求的開發時間

數據庫設計：

需求明確之後，第一步不是進行代碼開發，而是根據需求，進行數據庫的設計。我們可以採用PowerDesigner這種專業的工具，也可以直接在本地的mysql上面進行修改。博主採用的xmind思維導圖來設計自己的表結構（當然設計完畢之後，還是需要在mysql中創建），這樣做的好處是，我可以清晰的知道我要添加哪些表，修改哪些表。如下所示：

前後端對接：

因爲要和前端對接，所以肯定需要一份接口文檔，這邊我採用的是swagger來生成在線文檔。這樣做的好處是：所有接口都是最新的，不需要人工去進行維護。

當然這只是開始，前端對接還需要對每個接口進行詳細的說明，例如：

接口功能表述
接口的請求模式：get、post、delete、put等
參數說明：字段類型、是否必填、字段含義等
返回值說明

包名定義：

項目創建完畢之後，我們的包名要如何規劃呢？爲了規範，我將包名分爲：

config：配置類包
dao/mapper：數據庫操作dao類包
service：服務類包
util：工具類包
constant：常量類包
controller：控制類包
exception：異常類包
mq：mq監聽器類包
model：數據庫映射類、dto、vo等對象包
api：對外api請求類包

當然還有很多包名規範，這個要根據業務而定，博主的業務就比較特殊會涉及到mq、api。將包名規範好，寫代碼的時候就不會懵逼，至少代碼的位置我們都是清晰明瞭的。

創建配置文件：

因爲博主的項目是sprinboot項目，所以在包名確定下來之後，後面一件事情就是將項目運行起來，保證搭建的項目是正常的。單純的項目運行當然很簡單了，但是因爲項目本身涉及很多第三方軟件（redis、rabbitmq、mysql等），所以需要將這些軟件配置搞定。爲了方便後期的開發、測試、生產，我將項目的配置文件分爲：dev、test、pro。

這樣就能保證開發、測試、線上可以互不影響。

數據庫相關代碼生成：

項目可以正常啓動之後，就要正式開始業務代碼的編寫了，業務代碼的本質其實就是對數據庫的增刪改查。所以我們第一步要創建數據庫對應的entity、dao、xml。因爲數據庫框架我這邊採用的是mybatis，所以直接可用mybatis插件自動生成這些代碼。

博主因爲業務基本都是單表操作，所以採用了tk.mybatis插件，通過java代碼快速完成sql業務的操作（有興趣的童鞋可以去學習學習）。

業務代碼編寫：

數據庫相關類、工具類、配置類都搞定之後，就到具體業務的開發了，這個時候有些同學可能會比較懵逼，我代碼應該怎麼寫，控制類裏面寫什麼、service層又應該寫什麼、dao裏面寫什麼，怎麼寫才能避免重複代碼的出現呢？其實這邊博主也沒辦法給出一個具體的規範，只能根據自己多年的開發經驗來分享。如果有誰想自己研究這方面的內容，推薦大家看一下《java編程思想》這本書，寫的非常好。

代碼分層：

控制類中只負責http請求的處理，具體的業務都不在這一層中實現，最多隻是負責一些參數的校驗。
在寫業務之前，我們需求對業務進行細分，像我的原則按照業務類型創建業務服務類，例如支付服務類、交易記錄服務類，這樣的好處就是可以進行復用，儘可能的減少重複代碼的出現。
dao層中只有數據庫的操作，不會對數據進行處理。

案例分析：

可能這樣講會比較抽象，我舉一個例子吧，假如要開發一個套餐的支付（微信支付、支付寶支付）的功能。代碼要分別怎麼寫？最傻的就是創建一個餘額支付服務類、支付寶支付服務類。

我們首先要細分需求，比如兩個支付都會涉及到創建交易訂單和支付成功修改交易訂單部分的功能，所以我們可以分爲：創建交易記錄、支付、修改交易記錄狀態、創建購買的套餐。這樣就可以分爲交易記錄服務類、支付服務類、套餐服務類。這樣我們就可以複用交易記錄服務類和套餐服務類了。

服務類我們要本着功能可複用的原則，但是控制類我的原則是嚴格保持單一，儘量不要用type進行區分，這樣做程序的擴展性和維護性會好很多。這裏我給大家分享一個我寫代碼的技巧，我在寫代碼之前，我會先把業務步驟用註釋的形式寫出來，然後再去寫具體的業務代碼。

開發自測：

代碼開發完畢就到測試環節了，這邊測試有兩種方案，一個是通過swagger頁面直接發起http請求，但是博主不太推薦這種方式，前端可以用這種方式，後端我還是建議使用postman。通過postman工具，我們可以保存每一個接口的請求參數，還可以同步到雲端，下次測試可以直接測試，不需要重新再添加參數。

發佈線上：

數據庫準備：

本地測試完畢之後，我們就可以發佈到測試環境或者線上了，發佈版本之前，我們要保證本地的數據和線上的數據庫一致。因爲本地開發可能不會設置索引，但是線上我們一定要設置每一個表的索引，不然後期添加或者修改的時候，將會對數據庫造成很大的影響。

配置環境準備：

本地的配置我們可以雖然亂寫，但是線上的環境一定要根據具體軟件需求來配置（連接數、超時時間、併發數等）。數據庫、redis、mq這些統統使用內網（如果是同一個網絡），這樣就不會佔用外網資源了。

jvm參數設置：

線上的服務絕對不能默認jvm，因爲這樣只會使用到服務的1/4資源，嚴重情況下可能會導致jvm內存溢出等嚴重問題，所以上線的時候一定要設置好服務jvm參數。

優化升級：

每一個項目剛孵化的時候，肯定都是脆弱的，需要我們不斷的進行完善。那我們要如何進行架構優化呢？一方面收集線上運行數據，另一方面就是對未來流量和數據的預估。像我們這個項目因爲有對外的接口，那就應該進行接口限流操作，防止錯誤的調用導致服務奔潰呢。優化的方面當然有很多，博主這邊也只能範範的給出幾點優化建議：