Python實戰社羣php
Java實戰社羣linux
長按識別下方二維碼，按需求添加git
掃碼關注添加客服程序員
進Python社羣▲github
掃碼關注添加客服web
進Java社羣▲數據庫
做者丨撿田螺的小男孩
來源丨撿田螺的小男孩
前言
每個好習慣都是一筆財富，本文整理了寫代碼的16個好習慣，每一個都很經典，養成這些習慣，能夠規避多數非業務的bug！但願對你們有幫助哈，謝謝閱讀，加油哦~編程
github地址，感謝每顆starc#
❝https://github.com/whx123/JavaHomewindows
❞
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){
一、給現金增長操做
二、deleteTicketById(ticketId)
}else{
return "沒有可用現金券";
}
爲了更容易理解它，看這個流程圖吧：
1.線程A加現金
2.線程B加現金
3.線程A刪除票標誌
4.線程B刪除票標誌
顯然這樣存在「併發問題」，正例應該「利用數據庫刪除操做的原子性」，以下：
if(deleteAvailableTicketById(ticketId) == 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。
程序員專欄 掃碼關注填加客服 長按識別下方二維碼進羣
近期精彩內容推薦：
在看點這裏好文分享給更多人↓↓