前言
每一個好習慣都是一筆財富，本文整理了寫程式碼的16個好習慣，每個都很經典，養成這些習慣，可以規避多數非業務的bug！希望對大家有幫助哈，謝謝閱讀，加油哦~
1. 修改完程式碼，記得自測一下
「改完程式碼，自測一下」 是每位程式設計師必備的基本素養。尤其不要抱有這種僥幸 「心理：我只是改了一個變量或者我只改了一行配置程式碼，不用自測了」 。改完程式碼，盡量要求自己都去測試一下哈，可以規避很多不必要bug的。
2. 方法入參盡量都檢驗
入參校驗也是每個程式設計師必備的基本素養。你的方法處理， 「必須先校驗參數」 。比如入參是否允許為空，入參長度是否符合你的預期長度。這個盡量養成習慣吧，很多 「低階bug」 都是 「不校驗參數」 導致的。
❝
如果你的資料庫欄位設定為varchar(16),對方傳了一個32位元的字串過來，你不校驗參數， 「插入資料庫直接異常」 了。
❞3. 修改老介面的時候，思考介面的相容性。
很多bug都是因為修改了對外老介面，但是卻 「不做相容導致」 的。關鍵這個問題多數是比較嚴重的，可能直接導致系統發版失敗的。新手程式設計師很容易犯這個錯誤哦~
所以，如果你的需求是在原來介面上修改，，尤其這個介面是對外提供服務的話，一定要考慮介面相容。舉個例子吧，比如dubbo介面，原本是只接收A，B參數，現在你加了一個參數C，就可以考慮這樣處理。
//老介面
void oldService(A,B);{
//相容新介面，傳個null代替C
newService(A,B,null);
}
//新介面，暫時不能刪掉老介面，需要做相容。
void newService(A,B,C);
4.對於復雜的程式碼邏輯，添加清楚的註釋
寫程式碼的時候，是沒有必要寫太多的註釋的，好的方法變量命名就是最好的註釋。但是，如果是 「業務邏輯很復雜的程式碼」 ，真的非常有必要寫 「清楚註釋」 。清楚的註釋，更有利於後面的維護。
5. 使用完IO資源流，需要關閉
應該大家都有過這樣的經歷，windows系統桌面如果 「開啟太多檔」 或者系統軟體，就會覺得電腦很卡。當然，我們linux伺服器也一樣，平時操作檔，或者資料庫連線，IO資源流如果沒關閉，那麽這個IO資源就會被它占著，這樣別人就沒有辦法用了，這就造成 「資源浪費」 。
所以使用完IO流，可以使用finally關閉哈
FileInputStream fdIn = null;
try {
fdIn = new FileInputStream(new File("/jay.txt"));
} catch (FileNotFoundException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}finally {
try {
if (fdIn != null) {
fdIn.close();
}
} catch (IOException e) {
log.error(e);
}
}
JDK 7 之後還有更帥的關閉流寫法， 「try-with-resource」 。
/*
* 關註公眾號，撿田螺的小男孩
*/
try (FileInputStream inputStream = new FileInputStream(new File("jay.txt")) {
// use resources
} catch (FileNotFoundException e) {
log.error(e);
} catch (IOException e) {
log.error(e);
}
6.程式碼采取措施避免執行時錯誤（如陣列邊界溢位，被零除等）
日常開發中，我們需要采取措施規避 「陣列邊界溢位，被零整除，空指標」 等執行時錯誤。
類似程式碼比較常見：
String name = list.get(1).getName(); //list可能越界，因為不一定有2個元素哈
所以，應該 「采取措施，預防一下陣列邊界溢位」 ，正例：
if(CollectionsUtil.isNotEmpty(list)&& list.size()>1){
String name = list.get(1).getName();
}
7.盡量不在迴圈裏遠端呼叫、或者資料庫操作，優先考慮批次進行。
遠端操作或者資料庫操作都是 「比較耗網路、IO資源」 的，所以盡量不在迴圈裏遠端呼叫、不在迴圈裏操作資料庫，能 「批次一次性查回來盡量不要迴圈多次去查」 。（但是呢，也不要一次性查太多數據哈，要分批500一次醬紫）
正例：
remoteBatchQuery(param);
反例：
for(int i=0;i<n;i++){
remoteSingleQuery(param)
}
8.寫完程式碼，腦洞一下多執行緒執行會怎樣，註意並行一致性問題
我們經常見的一些業務場景，就是先查下有沒有記錄，再進行對應的操作（比如修改）。但是呢，(查詢+修改)合在一起不是原子操作哦，腦洞下多執行緒，就會發現有問題了，
反例如下：
if(isAvailable(ticketId){
1、給現金增加操作
2、deleteTicketById(ticketId)
}else{
return"沒有可用現金券";
}
為了更容易理解它，看這個流程圖吧：
1.執行緒A加現金
2.執行緒B加現金
3.執行緒A刪除票標誌
4.執行緒B刪除票標誌
顯然這樣存在 「並行問題」 ，正例應該 「利用資料庫刪除操作的原子性」 ，如下：
if(deleteAvailableTicketById(ticketId) == 1){
1、給現金增加操作
}else{
return 「沒有可用現金券」
}
因此，這個習慣也是要有的， 「寫完程式碼，自己想下多執行緒執行，是否會存在並行一致性問題」 。
9.獲取物件的內容，先判斷物件是否為空
這個點本來也屬於 「采取措施規避執行時異常」 的，但是我還是把它拿出來，當做一個重點來寫，因為平時空指標異常太常見了，一個手抖不註意，就導致空指標報到生產環境去了。
所以，你要獲取物件的內容時，盡量不要相信 「理論上不為空」 ，我們順手養成習慣判斷一下是否為空，再獲取物件的內容。正例：
if(object!=null){
String name = object.getName();
}
10.多執行緒異步優先考慮恰當的執行緒池，而不是new thread,同時考慮執行緒池是否隔離
為什麽優先使用執行緒池？使用執行緒池有這幾點好處呀
它幫我們管理執行緒，避免增加建立執行緒和銷毀執行緒的資源損耗。
提高響應速度。
重復利用。
同時呢，盡量不要所有業務都共用一個執行緒池，需要考慮
「執行緒池隔離」
。就是不同的關鍵業務，分配不同的執行緒池，然後執行緒池參數也要考慮恰當哈。
11. 手動寫完程式碼業務的SQL，先拿去資料庫跑一下，同時也explain看下執行計劃。
手動寫完業務程式碼的SQL，可以先把它拿到資料庫跑一下，看看有沒有語法錯誤嘛。有些小夥伴不好的習慣就是，寫完就把程式碼打包上去測試伺服器，其實把SQL放到資料庫執行一下，可以規避很多錯誤的。
同時呢，也用 「explain看下你Sql的執行計劃」 ，尤其走不走索引這一塊。
explain select * from user where userid =10086 or age =18;
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。
如喜歡本文，請點選右上角，把文章分享到朋友圈
如有想了解學習的技術點，請留言給若飛安排分享
因公眾號更改推播規則，請點「在看」並加「星標」 第一時間獲取精彩技術分享
·END·
相關閱讀：
作者：撿田螺的小男孩
來源：撿田螺的小男孩
版權申明：內容來源網路，僅供學習研究，版權歸原創者所有。如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝!
架構師
我們都是架構師！
關註 架構師(JiaGouX)，添加「星標」
獲取每天技術幹貨，一起成為牛逼架構師
技術群請 加若飛： 1321113940 進架構師群
投稿、合作、版權等信箱： [email protected]
