開發(fā)多年總結(jié)

每一個好習慣都是一筆財富润匙,本文整理了寫代碼的16個好習慣,每個都很經(jīng)典,養(yǎng)成這些習慣至朗,可以規(guī)避多數(shù)非業(yè)務(wù)的bug!希望對大家有幫助哈剧浸,謝謝閱讀锹引,加油哦~

1. 修改完代碼矗钟,記得自測一下

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

圖片

2. 方法入?yún)⒈M量都檢驗

入?yún)⑿r炓彩敲總€程序員必備的基本素養(yǎng)碑宴。你的方法處理软啼,「必須先校驗參數(shù)」。比如入?yún)⑹欠裨试S為空延柠,入?yún)㈤L度是否符合你的預(yù)期長度祸挪。這個盡量養(yǎng)成習慣吧,很多「低級bug」都是「不校驗參數(shù)」導(dǎo)致的贞间。

?

如果你的數(shù)據(jù)庫字段設(shè)置為varchar(16),對方傳了一個32位的字符串過來贿条,你不校驗參數(shù),「插入數(shù)據(jù)庫直接異吃鋈龋」了整以。

?

圖片

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

很多bug都是因為修改了對外老接口公黑,但是卻「不做兼容導(dǎo)致」的。關(guān)鍵這個問題多數(shù)是比較嚴重的摄咆,可能直接導(dǎo)致系統(tǒng)發(fā)版失敗的凡蚜。新手程序員很容易犯這個錯誤哦~

所以,如果你的需求是在原來接口上修改吭从,朝蜘,尤其這個接口是對外提供服務(wù)的話,一定要考慮接口兼容涩金。舉個例子吧谱醇,比如dubbo接口,原本是只接收A鸭廷,B參數(shù)枣抱,現(xiàn)在你加了一個參數(shù)C,就可以考慮這樣處理辆床。

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

//新接口,暫時不能刪掉老接口讼载,需要做兼容轿秧。
void newService(A,B,C);
圖片

4.對于復(fù)雜的代碼邏輯中跌,添加清楚的注釋

寫代碼的時候,是沒有必要寫太多的注釋的菇篡,好的方法變量命名就是最好的注釋漩符。但是,如果是「業(yè)務(wù)邏輯很復(fù)雜的代碼」驱还,真的非常有必要寫「清楚注釋」嗜暴。清楚的注釋,更有利于后面的維護议蟆。

圖片

5. 使用完IO資源流闷沥,需要關(guān)閉

應(yīng)該大家都有過這樣的經(jīng)歷,windows系統(tǒng)桌面如果「打開太多文件」或者系統(tǒng)軟件咐容,就會覺得電腦很卡舆逃。當然,我們linux服務(wù)器也一樣戳粒,平時操作文件路狮,或者數(shù)據(jù)庫連接,IO資源流如果沒關(guān)閉蔚约,那么這個IO資源就會被它占著奄妨,這樣別人就沒有辦法用了,這就造成「資源浪費」苹祟。

圖片

所以使用完IO流展蒂,可以使用finally關(guān)閉哈

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 之后還有更帥的關(guān)閉流寫法,「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.代碼采取措施避免運行時錯誤(如數(shù)組邊界溢出,被零除等)

日常開發(fā)中柳骄,我們需要采取措施規(guī)避「數(shù)組邊界溢出团赏,被零整除,空指針」等運行時錯誤耐薯。

類似代碼比較常見:

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

所以,應(yīng)該「采取措施曲初,預(yù)防一下數(shù)組邊界溢出」体谒,正例:

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

圖片

7.盡量不在循環(huán)里遠程調(diào)用、或者數(shù)據(jù)庫操作臼婆,優(yōu)先考慮批量進行抒痒。

遠程操作或者數(shù)據(jù)庫操作都是「比較耗網(wǎng)絡(luò)、IO資源」的颁褂,所以盡量不在循環(huán)里遠程調(diào)用故响、不在循環(huán)里操作數(shù)據(jù)庫傀广,能「批量一次性查回來盡量不要循環(huán)多次去查」。(但是呢彩届,也不要一次性查太多數(shù)據(jù)哈伪冰,要分批500一次醬紫)

正例:

remoteBatchQuery(param);

反例:

for(int i=0;i<n;i++){ remoteSingleQuery(param) }

圖片

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

我們經(jīng)常見的一些業(yè)務(wù)場景贮聂,就是先查下有沒有記錄,再進行對應(yīng)的操作(比如修改)寨辩。但是呢吓懈,(查詢+修改)合在一起不是原子操作哦,腦洞下多線程捣染,就會發(fā)現(xiàn)有問題了骄瓣,

反例如下:

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

為了更容易理解它榕栏,看這個流程圖吧:

16061246-21f66f1a698343c9.png
  • 1.線程A加現(xiàn)金
  • 2.線程B加現(xiàn)金
  • 3.線程A刪除票標志
  • 4.線程B刪除票標志

顯然這樣存在「并發(fā)問題」,正例應(yīng)該「利用數(shù)據(jù)庫刪除操作的原子性」蕾各,如下:

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

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

圖片

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

這個點本來也屬于「采取措施規(guī)避運行時異常」的钧排,但是我還是把它拿出來敦腔,當做一個重點來寫,因為平時空指針異常太常見了恨溜,一個手抖不注意符衔,就導(dǎo)致空指針報到生產(chǎn)環(huán)境去了。

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

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

圖片

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

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

  • 它幫我們管理線程沃缘,避免增加創(chuàng)建線程和銷毀線程的資源損耗躯枢。
  • 提高響應(yīng)速度。
  • 重復(fù)利用槐臀。

同時呢锄蹂,盡量不要所有業(yè)務(wù)都共用一個線程池,需要考慮「線程池隔離」水慨。就是不同的關(guān)鍵業(yè)務(wù)得糜,分配不同的線程池,然后線程池參數(shù)也要考慮恰當哈晰洒。

圖片

11. 手動寫完代碼業(yè)務(wù)的SQL朝抖,先拿去數(shù)據(jù)庫跑一下,同時也explain看下執(zhí)行計劃谍珊。

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

同時呢,也用「explain看下你Sql的執(zhí)行計劃」打掘,尤其走不走索引這一塊华畏。

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

圖片

12.調(diào)用第三方接口,需要考慮異常處理尊蚁,安全性亡笑,超時重試這幾個點。

調(diào)用第三方服務(wù)横朋,或者分布式遠程服務(wù)的的話况芒,需要考慮

  • 異常處理(比如,你調(diào)別人的接口叶撒,如果異常了,怎么處理耐版,是重試還是當做失旍艄弧)
  • 超時(沒法預(yù)估對方接口一般多久返回,一般設(shè)置個超時斷開時間粪牲,以保護你的接口)
  • 重試次數(shù)(你的接口調(diào)失敗古瓤,需不需要重試,需要站在業(yè)務(wù)上角度思考這個問題)

?

簡單一個例子,你一個http請求別人的服務(wù)落君,需要考慮設(shè)置connect-time穿香,和retry次數(shù)。

?

如果是轉(zhuǎn)賬等重要的第三方服務(wù)绎速,還需要考慮「簽名驗簽」皮获,「加密」等。之前寫過一篇加簽驗簽的纹冤,有興趣的朋友可以看一下哈

圖片

13.接口需要考慮冪等性

接口是需要考慮冪等性的洒宝,尤其搶紅包、轉(zhuǎn)賬這些重要接口萌京。最直觀的業(yè)務(wù)場景雁歌,就是「用戶連著點擊兩次」,你的接口有沒有hold住知残。

?

  • 冪等(idempotent靠瞎、idempotence)是一個數(shù)學與計算機學概念,常見于抽象代數(shù)中求妹。
  • 在編程中.一個冪等操作的特點是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同乏盐。冪等函數(shù),或冪等方法扒最,是指可以使用相同參數(shù)重復(fù)執(zhí)行丑勤,并能獲得相同結(jié)果的函數(shù)。

?

一般「冪等技術(shù)方案」有這幾種:

  • 查詢操作
  • 唯一索引
  • token機制吧趣,防止重復(fù)提交
  • 數(shù)據(jù)庫的delete刪除操作
  • 樂觀鎖
  • 悲觀鎖
  • Redis法竞、zookeeper 分布式鎖(以前搶紅包需求,用了Redis分布式鎖)
  • 狀態(tài)機冪等
圖片

14. 多線程情況下强挫,考慮線性安全問題

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

?

  • Hashmap八匠、Arraylist絮爷、LinkedList、TreeMap等都是線性不安全的梨树;
  • Vector坑夯、Hashtable、ConcurrentHashMap等都是線性安全的

?

圖片

15.主從延遲問題考慮

先插入抡四,接著就去查詢,這類代碼邏輯比較常見柜蜈,這「可能」會有問題的仗谆。一般數(shù)據(jù)庫都是有主庫,從庫的淑履。寫入的話是寫主庫隶垮,讀一般是讀從庫。如果發(fā)生主從延遲秘噪,很可能出現(xiàn)你插入成功了狸吞,但是卻查詢不到的情況。

圖片
  • 如果是重要業(yè)務(wù)缆娃,需要考慮是否強制讀主庫捷绒,還是再修改設(shè)計方案。
  • 但是呢贯要,有些業(yè)務(wù)場景是可以接受主從稍微延遲一點的暖侨,但是這個習慣還是要有吧。
  • 寫完操作數(shù)據(jù)庫的代碼崇渗,想下是否存在主從延遲問題字逗。

16.使用緩存的時候,考慮緩存跟DB的一致性宅广,還有(緩存穿透葫掉、緩存雪崩和緩存擊穿)

通俗點說,我們使用緩存就是為了「查得快跟狱,接口耗時小」俭厚。但是呢,用到緩存驶臊,就需要「注意緩存與數(shù)據(jù)庫的一致性」問題挪挤。同時,還需要規(guī)避緩存穿透关翎、緩存雪崩和緩存擊穿三大問題扛门。

  • 緩存雪崩:指緩存中數(shù)據(jù)大批量到過期時間,而查詢數(shù)據(jù)量巨大纵寝,引起數(shù)據(jù)庫壓力過大甚至down機论寨。
  • 緩存穿透:指查詢一個一定不存在的數(shù)據(jù),由于緩存是不命中時需要從數(shù)據(jù)庫查詢爽茴,查不到數(shù)據(jù)則不寫入緩存葬凳,這將導(dǎo)致這個不存在的數(shù)據(jù)每次請求都要到數(shù)據(jù)庫去查詢,進而給數(shù)據(jù)庫帶來壓力室奏。
  • 緩存擊穿:指熱點key在某個時間點過期的時候沮明,而恰好在這個時間點對這個Key有大量的并發(fā)請求過來,從而大量的請求打到db窍奋。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子琳袄,更是在濱河造成了極大的恐慌江场,老刑警劉巖,帶你破解...
    沈念sama閱讀 216,496評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件窖逗,死亡現(xiàn)場離奇詭異址否,居然都是意外死亡,警方通過查閱死者的電腦和手機碎紊,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,407評論 3 392
  • 文/潘曉璐 我一進店門佑附,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人仗考,你說我怎么就攤上這事音同。” “怎么了秃嗜?”我有些...
    開封第一講書人閱讀 162,632評論 0 353
  • 文/不壞的土叔 我叫張陵权均,是天一觀的道長。 經(jīng)常有香客問我锅锨,道長叽赊,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,180評論 1 292
  • 正文 為了忘掉前任必搞,我火速辦了婚禮必指,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘恕洲。我一直安慰自己塔橡,他們只是感情好,可當我...
    茶點故事閱讀 67,198評論 6 388
  • 文/花漫 我一把揭開白布研侣。 她就那樣靜靜地躺著谱邪,像睡著了一般。 火紅的嫁衣襯著肌膚如雪庶诡。 梳的紋絲不亂的頭發(fā)上惦银,一...
    開封第一講書人閱讀 51,165評論 1 299
  • 那天,我揣著相機與錄音末誓,去河邊找鬼扯俱。 笑死,一個胖子當著我的面吹牛喇澡,可吹牛的內(nèi)容都是我干的迅栅。 我是一名探鬼主播,決...
    沈念sama閱讀 40,052評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼晴玖,長吁一口氣:“原來是場噩夢啊……” “哼读存!你這毒婦竟也來了为流?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 38,910評論 0 274
  • 序言:老撾萬榮一對情侶失蹤让簿,失蹤者是張志新(化名)和其女友劉穎敬察,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體尔当,經(jīng)...
    沈念sama閱讀 45,324評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡莲祸,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,542評論 2 332
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了椭迎。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片锐帜。...
    茶點故事閱讀 39,711評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖畜号,靈堂內(nèi)的尸體忽然破棺而出缴阎,到底是詐尸還是另有隱情,我是刑警寧澤弄兜,帶...
    沈念sama閱讀 35,424評論 5 343
  • 正文 年R本政府宣布药蜻,位于F島的核電站,受9級特大地震影響替饿,放射性物質(zhì)發(fā)生泄漏语泽。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,017評論 3 326
  • 文/蒙蒙 一视卢、第九天 我趴在偏房一處隱蔽的房頂上張望踱卵。 院中可真熱鬧,春花似錦据过、人聲如沸惋砂。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,668評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽西饵。三九已至,卻和暖如春鳞芙,著一層夾襖步出監(jiān)牢的瞬間眷柔,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,823評論 1 269
  • 我被黑心中介騙來泰國打工原朝, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留驯嘱,地道東北人。 一個月前我還...
    沈念sama閱讀 47,722評論 2 368
  • 正文 我出身青樓喳坠,卻偏偏與公主長得像鞠评,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子壕鹉,可洞房花燭夜當晚...
    茶點故事閱讀 44,611評論 2 353

推薦閱讀更多精彩內(nèi)容

  • 夜鶯2517閱讀 127,719評論 1 9
  • 版本:ios 1.2.1 亮點: 1.app角標可以實時更新天氣溫度或選擇空氣質(zhì)量剃幌,建議處女座就不要選了聋涨,不然老想...
    我就是沉沉閱讀 6,887評論 1 6
  • 我是一名過去式的高三狗,很可悲负乡,在這三年里我沒有戀愛牛郑,看著同齡的小伙伴們一對兒一對兒的,我的心不好受敬鬓。怎么說呢,高...
    小娘紙閱讀 3,387評論 4 7
  • 這些日子就像是一天一天在倒計時 一想到他走了 心里就是說不出的滋味 從幾個月前認識他開始 就意識到終究會發(fā)生的 只...
    栗子a閱讀 1,620評論 1 3