你寫的每行程式碼都是你的名片

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

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

2. 方法入參儘量都檢驗

入參校驗也是每個程式設計師必備的基本素養。你的方法處理，「必須先校驗引數」。比如入參是否允許為空，入參長度是否符合你的預期長度。這個儘量養成習慣吧，很多「低階bug」都是「不校驗引數」導致的。如果你的資料庫欄位設定為varchar(16),對方傳了一個32位的字串過來，你不校驗引數，異常 com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column

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

很多bug都是因為修改了對外老介面，但是卻「不做相容導致」的。關鍵這個問題多數是比較嚴重的，可能直接導致系統發版失敗的。所以，如果你的需求是在原來介面上修改，尤其這個介面是對外提供服務的話，一定要考慮介面相容

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

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

5. 使用完IO資源流，需要關閉

應該大家都有過這樣的經歷，windows系統桌面如果「開啟太多檔案」或者系統軟體，就會覺得電腦很卡。當然，我們linux伺服器也一樣，平時操作檔案，或者資料庫連線，IO資源流如果沒關閉，那麼這個IO資源就會被它佔著，這樣別人就沒有辦法用了，這就造成「資源浪費」。

6.程式碼採取措施避免執行時錯誤（如陣列邊界溢位，被零除等）

日常開發中，我們需要採取措施規避「陣列邊界溢位，被零整除，空指標」等執行時錯誤

 // 反例：list可能越界，因為不一定有2個元素哈
String name = list.get(1).getName();

 // 正例：做個判斷預防一下陣列邊界溢位
if (CollectionsUtil.isNotEmpty(list) && list.size() > 1) {
  String name 
 
= list.get(1).getName(); 
}

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

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

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

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

9.獲取物件的屬性，先判斷物件是否為空

這個點本來也屬於「採取措施規避執行時異常」的，但是我還是把它拿出來，當做一個重點來寫，因為平時空指標異常太常見了，一個手抖不注意，就導致空指標報到生產環境去了。

所以，你要獲取物件的屬性時，儘量不要相信「理論上不為空」，我們順手養成習慣判斷一下是否為空，再獲取物件的屬性

// 正例
if (object != null) {
   String name = object.getName();
}

10.多執行緒非同步優先考慮恰當的執行緒池，而不是new thread,同時考慮執行緒池是否隔離

為什麼優先使用執行緒池？使用執行緒池有這幾點好處呀

• 它幫我們管理執行緒，避免增加建立執行緒和銷燬執行緒的資源損耗。
• 提高響應速度。
• 重複利用。

同時呢，儘量不要所有業務都共用一個執行緒池，需要考慮「執行緒池隔離」。就是不同的關鍵業務，分配不同的執行緒池，然後執行緒池引數也要考慮恰當

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

手動寫完業務程式碼的SQL，可以先把它拿到資料庫跑一下，看看有沒有語法錯誤嘛。有些小夥伴不好的習慣就是，寫完就把程式碼打包上去測試伺服器，其實把SQL放到資料庫執行一下，可以規避很多錯誤的。同時也用「explain看下你Sql的執行計劃」，尤其走不走索引這一塊

12.呼叫第三方介面，需要考慮異常處理，安全性，超時重試這幾個點

呼叫第三方服務，或者分散式遠端服務的的話，需要考慮

• 異常處理（比如，你調別人的介面，如果異常了，怎麼處理，是重試還是當做失敗）
• 超時（沒法預估對方介面一般多久返回，一般設定個超時斷開時間，以保護你的介面）
• 重試次數（你的介面調失敗，需不需要重試，需要站在業務上角度思考這個問題）

簡單一個例子，你一個http請求別人的服務，需要考慮設定connect-time，和retry次數；如果是轉賬等重要的第三方服務，還需要考慮「簽名驗籤」、「加密」等

13.介面需要考慮冪等性

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

• 冪等（idempotent、idempotence）是一個數學與計算機學概念，常見於抽象代數中。
• 在程式設計中.一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。

一般「冪等技術方案」有這幾種:

• 查詢操作
• 唯一索引
• token機制，防止重複提交
• 資料庫的delete刪除操作
• 樂觀鎖
• 悲觀鎖
• Redis、zookeeper 分散式鎖（以前搶紅包需求，用了Redis分散式鎖）
• 狀態機冪等

14. 多執行緒情況下，考慮線性安全問題

在「高併發」情況下，HashMap可能會出現死迴圈。因為它是非線性安全的，可以考慮使用ConcurrentHashMap。所以這個也儘量養成習慣，不要上來反手就是一個new HashMap();

• Hashmap、Arraylist、LinkedList、TreeMap等都是線性不安全的；
• Vector、Hashtable、ConcurrentHashMap等都是線性安全的

15.主從延遲問題考慮

先插入，接著就去查詢,這類程式碼邏輯比較常見，這「可能」會有問題的。一般資料庫都是有主庫，從庫的。寫入的話是寫主庫，讀一般是讀從庫。如果發生主從延遲，很可能出現你插入成功了，但是卻查詢不到的情況

• 如果是重要業務，需要考慮是否強制讀主庫，還是再修改設計方案。
• 但是呢，有些業務場景是可以接受主從稍微延遲一點的，但是這個習慣還是要有吧。
• 寫完操作資料庫的程式碼，想下是否存在主從延遲問題。

16.使用快取的時候，考慮快取跟DB的一致性，還有（快取穿透、快取雪崩和快取擊穿）

通俗點說，我們使用快取就是為了「查得快，介面耗時小」。但是呢，用到快取，就需要「注意快取與資料庫的一致性」問題。同時，還需要規避快取穿透、快取雪崩和快取擊穿三大問題

• 快取雪崩：指快取中資料大批量到過期時間，而查詢資料量巨大，引起資料庫壓力過大甚至down機
• 快取穿透：指查詢一個一定不存在的資料，由於快取是不命中時需要從資料庫查詢，查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到資料庫去查詢，進而給資料庫帶來壓力
• 快取擊穿：指熱點key在某個時間點過期的時候，而恰好在這個時間點對這個Key有大量的併發請求過來，從而大量的請求打到db

參考文章：https://mp.weixin.qq.com/s/8-9qY42c7PasxwRS11JcIA