一個優秀的程序員，往往有著良好的代碼習慣，每個好習慣都是一筆財富。在寫代碼的時候，注意這些細節，可以讓你的bug減少很多，快來學學吧！
1. 代碼自測
在完成代碼的時候，有些初級程序員往往會偷懶，不去檢查自己的代碼，結果一跑起來問題多多。對于項目來說，即使修改了一行很小的代碼，都有可能出現各種各樣的問題，所以自測一下非常重要。
入參校驗是每個程序員的必備素養，很多低級bug都是不校驗參數導致的。舉個例子：如果你的數據庫字段設置為varchar(16)，對方傳了一個32位的字符串過來，你不校驗參數，「插入數據庫直接異常」了。
在修改老接口時，一定要思考接口的兼容性，很多新手程序員因為考慮問題太簡單而犯錯，就會導致非常嚴重的后果。
有一定工作經驗的程序員，往往會有個壞毛病，那就是不做注釋。一般的代碼沒必要添加太多注釋，但是，如果是「業務邏輯很復雜的代碼」，真的非常有必要寫「清楚注釋」。清楚的注釋，更有利于后面的維護。
5.使用完IO資源流，需要關閉
應該大家都有過這樣的經歷，windows系統桌面如果「打開太多文件」或者系統軟件，就會覺得電腦很卡。當然，我們linux服務器也一樣，平時操作文件，或者數據庫連接，IO資源流如果沒關閉，那么這個IO資源就會被它占著，這樣別人就沒有辦法用了，這就造成「資源浪費」。
6.避免低級錯誤（如數組邊界溢出，被零除等）
日常開發中，我們需要采取措施規避「數組邊界溢出，被零整出，空指針」等運行時錯誤。
7.盡量不在循環里遠程調用
遠程操作和數據庫操作都是比較消耗資源的，所以盡量不在循環里遠程調用、不在循環里操作數據庫，能「批量一次性查回來盡量不要循環多次去查」。
8.注意并發一致性問題
9.獲取對象的屬性，先判斷對象是否為空
空指針異常是程序員常見問題之一，在想要獲取對象屬性時，要先判斷是否為空，再獲取對象的屬性。
10.多線程異步優先使用線程池
- 它幫我們管理線程，避免增加創建線程和銷毀線程的資源損耗。
- 提高響應速度。
- 重復利用。
同時呢，盡量不要所有業務都共用一個線程池，需要考慮「線程池隔離」。就是不同的關鍵業務，分配不同的線程池，然后線程池參數也要考慮恰當哈。
11. 手動寫完代碼業務的SQL，先拿去數據庫跑一下，同時也explain看下執行計劃。
手動寫完業務代碼的SQL，可以先把它拿到數據庫跑一下，看看有沒有語法錯誤嘛。有些小伙伴不好的習慣就是，寫完就把代碼打包上去測試服務器，其實把SQL放到數據庫執行一下，可以規避很多錯誤的。
12.調用第三方接口，需要考慮異常處理，安全性，超時重試這幾個點。
調用第三方服務，或者分布式遠程服務的的話，需要考慮
- 異常處理（比如，你調別人的接口，如果異常了，怎么處理，是重試還是當做失敗）
- 超時（沒法預估對方接口一般多久返回，一般設置個超時斷開時間，以保護你的接口）
- 重試次數（你的接口調失敗，需不需要重試，需要站在業務上角度思考這個問題）
13.接口需要考慮冪等性
接口是需要考慮冪等性的，尤其搶紅包、轉賬這些重要接口。最直觀的業務場景，就是「用戶連著點擊兩次」，你的接口有沒有hold住。
14. 多線程情況下，考慮線性安全問題
在「高并發」情況下，HashMap可能會出現死循環。因為它是非線性安全的，可以考慮使用ConcurrentHashMap。所以這個也盡量養成習慣，不要上來反手就是一個new HashMap();
15.主從延遲問題考慮
先插入，接著就去查詢，這類代碼邏輯比較常見，這「可能」會有問題的。一般數據庫都是有主庫、從庫的。寫入的話是寫主庫，讀一般是讀從庫。如果發生主從延遲，很可能出現你插入成功了，但是卻查詢不到的情況。
16.使用緩存的時候，考慮緩存跟DB的一致性，還有（緩存穿透、緩存雪崩和緩存擊穿）
通俗點說，我們使用緩存就是為了「查得快，接口耗時小」。但是呢，用到緩存，就需要「注意緩存與數據庫的一致性」問題。同時，還需要規避緩存穿透、緩存雪崩和緩存擊穿三大問題。
云和數據作為一個深耕IT職業教育多年的教育者，目前的課程涵蓋云計算、大數據、人工智能、虛擬現實、軟件工程、用戶體驗設計、網絡安全、電子商務等八大方向，結合企業實際用人需求，只為培養更多高端IT技術人才。
