注釋寫的少,踩坑少不了

程式設計師最討厭的四件事：寫注釋、寫文檔、別人不寫注釋、別人不寫文檔……

一定要養成寫注釋的習慣,每個方法是做什麼的,方法入參是什麼都要寫清楚,利人利己。不寫注釋害人害己,從自己做起將不寫注釋的風氣扼殺在項目組中。

拷貝方法時候,修改後記得把注釋也同步修改
每個方法每個類每個入參都要做到有注釋

冪等並發是伴隨項目的從生到老的問題

不遇則已,一遇到就是生死優化問題,尤其金融相關場景。

小編之前在某支付公司,開發一個大型活動要給用戶瓜分三千萬,用戶可以搶紅包。為了削減流量洪峰,我們做了層層的削峰,但是最後卻出現了並發問題,大部分的並發冪等問題被入口和帳務攔截，但是出現了幾個非常巧合的兩個場景,沒有攔截住導致最後給2個用戶多發放了兩次紅包。

所以每個涉及到數據變更的接口都有必要做冪等和放重判斷。

下面例子①查詢資料庫狀態,如果資料庫狀態無變更就執行,否則就被冪等校驗住了。這種方式似乎能滿足冪等判斷,但是在高並發場景很容易都進來了,因為①和④並不是原子性操作。

所以我們得出結論:

冪等和防重判斷邏輯一定要保證原子性,否則無效.

那麼應該如何解決呢?上圖的代碼不用改變只是要新加並發和防重的判斷即可。另外sql要加鎖操作這是必須的,除非說重複修改資料庫狀態沒有影響。具體怎麼做,小編上一篇文章提到了幾種解決方案

正確對待基本類型的包裝類

基本類型都會有初始化默認值
包裝類沒有,包裝類默認值可能為null

案例一. 這是個老生常談的問題,當用第一個test時候,a和b如果小於127那麼判斷沒有毛病，如果大於127那麼就有問題，這個具體什麼原因不多說了，想強調一點的是注意是所有的包裝類型都是內部Cache類,

比如: IntegerCache,LongCache,ByteCache類,所以要注意數值判斷

案例二. 包裝類默認值可能為null

當integer為null時候就會出現NPE異常。

領域模型的處理

業務邏輯到底應該寫哪裡,DDD的設計思路每個項目有不同的認識,只要項目組能達成一致形成規範,應該都沒有啥大問題。但是業務邏輯千萬不要寫到攔截器或者過濾器中。這裡說一下親身經歷的案例。

業務系統遷移問題注意點

當我們對業務系統進行遷移,時候一定要與原系統開發人員核對清楚,功能清單及代碼邏輯。有一個血淋淋的例子。我們對業務系統進行功能遷移,不是寫代碼，而是把原來的代碼作為標準應用打成jar包, 在我們應用中引用使用,上線完成後通過自動化腳本跑,一切正常,接口返回都正常。但是凌晨突然接到電話,所有的接口調用後,前端某個功能不能使用。經前端排查是後端接口某一個返回值沒有返回。但是我們的接口代碼沒有改，引用之前的jar包,為什麼會出現參數不完整呢？經過排查之前的標準應用把部分業務代碼寫到了攔截器中，而我們的新應用沒有對應的攔截器所以導致攔截器中的代碼都沒有實現。從而導致問題。