修改完程式碼，記得自測一下

「改完程式碼，自測一下」是每位程式設計師必備的基本素養。尤其不要抱有這種僥倖「心理：我只是改了一個變數或者我只改了一行配置程式碼，不用自測了」。改完程式碼，儘量要求自己都去測試一下哈，可以規避很多不必要bug的。

方法入參儘量都檢驗

入參校驗也是每個程式設計師必備的基本素養。你的方法處理，「必須先校驗引數」。比如入參是否允許為空，入參長度是否符合你的預期長度。儘量養成習吧，很多「低階bug」都是「不校驗引數」導致的。

如果你的資料庫欄位設定為varchar(16),對方傳了一個32位的字串過來，你不校驗引數，「插入資料庫直接異常」了。

修改老介面的時候，思考介面的相容性。

很多bug都是因為修改了對外老介面，但是卻「不做相容導致」的。關鍵這個問題多數是比較嚴重的，可能直接導致系統發版失敗的。

所以，如果你的需求是在原來介面上修改，，尤其這個介面是對外提供服務的話，一定要考慮介面相容。

對於複雜的程式碼邏輯，新增清楚的註釋

寫程式碼的時候，是沒有必要寫太多的註釋的，好的方法變數命名就是最好的註釋。但是，如果是「業務邏輯很複雜的程式碼」，真的非常有必要寫「清楚註釋」。清楚的註釋，更有利於後面的維護，以及新手閱讀。

儘量不在迴圈裡遠端呼叫、或者資料庫操作，優先考慮批量進行。

遠端操作或者資料庫操作都是「比較耗網路、IO資源」的，所以儘量不在迴圈裡遠端呼叫、不在迴圈裡操作資料庫，能「批量一次性查回來儘量不要迴圈多次去查」

寫完程式碼，腦洞一下多執行緒執行會怎樣，注意併發一致性問題

我們經常見的一些業務場景，就是先查下有沒有記錄，再進行對應的操作（比如修改）。但是呢，(查詢+修改)合在一起不是原子操作，腦洞下多執行緒，就會發現有問題了，

手動寫完程式碼業務的SQL，先拿去資料庫跑一下，同時也explain看下執行計劃。

手動寫完業務程式碼的SQL，可以先把它拿到資料庫跑一下，看看有沒有語法錯誤嘛。不好的習慣就是，寫完就把程式碼打包上去測試伺服器，其實把SQL放到資料庫執行一下，可以規避很多錯誤的。

同時，也用「explain看下你Sql的執行計劃」，尤其走不走索引這一塊。

介面需要考慮冪等性

介面是需要考慮冪等性的，尤其搶紅包、轉賬這些重要介面。最直觀的業務場景，就是「使用者連著點選兩次」，看介面有沒有hold住。