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

「改完代碼，自測一下」 是每位程序員必備的基本素養(yǎng)。尤其不要抱有這種僥幸「心理：我只是改了一個變量或者我只改了一行配置代碼，不用自測了」。改完代碼，盡量要求自己都去測試一下哈，可以規(guī)避很多不必要bug的。

2. 方法入參盡量都檢驗

入參校驗也是每個程序員必備的基本素養(yǎng)。你的方法處理，「必須先校驗參數」。比如入參是否允許為空，入參長度是否符合你的預期長度。這個盡量養(yǎng)成習慣吧，很多「低級bug」都是「不校驗參數」導致的。

如果你的數據庫字段設置為varchar(16),對方傳了一個32位的字符串過來，你不校驗參數，「插入數據庫直接異常」了。

3. 修改老接口的時候，思考接口的兼容性。

很多bug都是因為修改了對外老接口，但是卻「不做兼容導致」的。關鍵這個問題多數是比較嚴重的，可能直接導致系統發(fā)版失敗的。新手程序員很容易犯這個錯誤哦~

所以，如果你的需求是在原來接口上修改，，尤其這個接口是對外提供服務的話，一定要考慮接口兼容。舉個例子吧，比如dubbo接口，原本是只接收A，B參數，現在你加了一個參數C，就可以考慮這樣處理。

//老接口
void?oldService(A,B);{
??//兼容新接口，傳個null代替C
??newService(A,B,null);
}

//新接口，暫時不能刪掉老接口，需要做兼容。
void?newService(A,B,C);

4.對于復雜的代碼邏輯，添加清楚的注釋

寫代碼的時候，是沒有必要寫太多的注釋的，好的方法變量命名就是最好的注釋。但是，如果是「業(yè)務邏輯很復雜的代碼」，真的非常有必要寫「清楚注釋」。清楚的注釋，更有利于后面的維護。

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.代碼采取措施避免運行時錯誤（如數組邊界溢出，被零除等）

日常開發(fā)中，我們需要采取措施規(guī)避「數組邊界溢出，被零整出，空指針」等運行時錯誤。

類似代碼比較常見：

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

所以，應該「采取措施，預防一下數組邊界溢出」，正例：

if(CollectionsUtil.isNotEmpty(list)&&?list.size()>1){
??String?name?=?list.get(1).getName();?
}

7.盡量不在循環(huán)里遠程調用、或者數據庫操作，優(yōu)先考慮批量進行。

遠程操作或者數據庫操作都是「比較耗網絡、IO資源」的，所以盡量不在循環(huán)里遠程調用、不在循環(huán)里操作數據庫，能「批量一次性查回來盡量不要循環(huán)多次去查」。（但是呢，也不要一次性查太多數據哈，要分批500一次醬紫）

正例：

remoteBatchQuery(param);

反例：

for(int?i=0;i??remoteSingleQuery(param)
}

8.寫完代碼，腦洞一下多線程執(zhí)行會怎樣，注意并發(fā)一致性問題

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

反例如下：

if(isAvailable(ticketId){?
????1、給現金增加操作?
????2、deleteTicketById(ticketId)?
}else{?
????return?"沒有可用現金券";
}

為了更容易理解它，看這個流程圖吧：

• 1.線程A加現金
• 2.線程B加現金
• 3.線程A刪除票標志
• 4.線程B刪除票標志

顯然這樣存在「并發(fā)問題」，正例應該「利用數據庫刪除操作的原子性」，如下：

if(deleteAvailableTicketById(ticketId)?==?1){?
????1、給現金增加操作?
}else{?
????return?“沒有可用現金券”?
}

因此，這個習慣也是要有的，「寫完代碼，自己想下多線程執(zhí)行，是否會存在并發(fā)一致性問題」。

9.獲取對象的屬性，先判斷對象是否為空

這個點本來也屬于「采取措施規(guī)避運行時異?！?/strong>的，但是我還是把它拿出來，當做一個重點來寫，因為平時空指針異常太常見了，一個手抖不注意，就導致空指針報到生產環(huán)境去了。

所以，你要獲取對象的屬性時，盡量不要相信「理論上不為空」，我們順手養(yǎng)成習慣判斷一下是否為空，再獲取對象的屬性。正例：

if(object!=null){
???String?name?=?object.getName();
}

10.多線程異步優(yōu)先考慮恰當的線程池，而不是new thread,同時考慮線程池是否隔離

為什么優(yōu)先使用線程池？使用線程池有這幾點好處呀

• 它幫我們管理線程，避免增加創(chuàng)建線程和銷毀線程的資源損耗。
• 提高響應速度。
• 重復利用。

同時呢，盡量不要所有業(yè)務都共用一個線程池，需要考慮「線程池隔離」。就是不同的關鍵業(yè)務，分配不同的線程池，然后線程池參數也要考慮恰當哈。

11. 手動寫完代碼業(yè)務的SQL，先拿去數據庫跑一下，同時也explain看下執(zhí)行計劃。

手動寫完業(yè)務代碼的SQL，可以先把它拿到數據庫跑一下，看看有沒有語法錯誤嘛。有些小伙伴不好的習慣就是，寫完就把代碼打包上去測試服務器，其實把SQL放到數據庫執(zhí)行一下，可以規(guī)避很多錯誤的。

同時呢，也用「xeplain看下你Sql的執(zhí)行計劃」，尤其走不走索引這一塊。

explain?select?*?from?user?where?userid?=10086?or?age?=18;

12.調用第三方接口，需要考慮異常處理，安全性，超時重試這幾個點。

調用第三方服務，或者分布式遠程服務的的話，需要考慮

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

簡單一個例子，你一個http請求別人的服務，需要考慮設置connect-time，和retry次數。

如果是轉賬等重要的第三方服務，還需要考慮「簽名驗簽」，「加密」等。

13.接口需要考慮冪等性

接口是需要考慮冪等性的，尤其搶紅包、轉賬這些重要接口。最直觀的業(yè)務場景，就是「用戶連著點擊兩次」，你的接口有沒有hold住。

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

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

• 查詢操作
• 唯一索引
• token機制，防止重復提交
• 數據庫的delete刪除操作
• 樂觀鎖
• 悲觀鎖
• Redis、zookeeper 分布式鎖（以前搶紅包需求，用了Redis分布式鎖）
• 狀態(tài)機冪等

14. 多線程情況下，考慮線性安全問題

在「高并發(fā)」情況下，HashMap可能會出現死循環(huán)。因為它是非線性安全的，可以考慮使用ConcurrentHashMap。所以這個也盡量養(yǎng)成習慣，不要上來反手就是一個new HashMap();

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

15.主從延遲問題考慮

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

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

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

通俗點說，我們使用緩存就是為了「查得快，接口耗時小」。但是呢，用到緩存，就需要「注意緩存與數據庫的一致性」問題。同時，還需要規(guī)避緩存穿透、緩存雪崩和緩存擊穿三大問題。

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

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：