為什么我總寫 Bug ？

總結(jié)常見的 Bug，幫大家避坑

大家好，我是魚皮。

寫代碼的過程中，難免會(huì)出現(xiàn)各種各樣的 Bug。但實(shí)際上，很多 Bug 產(chǎn)生的原因是類似的。于是我總結(jié)了一些自己學(xué)編程時(shí)寫 Bug 的誘因，希望大家引以為戒，在以后寫代碼的時(shí)候能更多注意。

常見 Bug 誘因匯總

中文編碼

下面是兩行最最最簡(jiǎn)單的 Java 代碼，上面的代碼能運(yùn)行，下面的代碼會(huì)報(bào)錯(cuò)：

// 教程中的，能運(yùn)行
System.out.println("Hello!");
// 我寫的，會(huì)報(bào)錯(cuò)
System.out.println("Hello!")；

明明我的代碼和教程中的一模一樣，為啥就是運(yùn)行不了呢？

這是初學(xué)編程的同學(xué)總會(huì)遇到的一個(gè)問題，仔細(xì)一看，原來是行尾的分號(hào)誤用成中文的了。。。

這種 Bug 往往都是由于剛開始學(xué)編程時(shí)不注意或不習(xí)慣輸入法的切換而導(dǎo)致的，不過寫一段時(shí)間代碼后，就會(huì)好很多。而且一般編輯器是能夠識(shí)別出錯(cuò)誤位置的，根據(jù)報(bào)錯(cuò)信息去修改就好了。

此外，有時(shí)我不小心把項(xiàng)目文件名從英文改成了中文，也會(huì)出現(xiàn)亂碼、無法讀取文件之類的問題。

代碼不規(guī)范

我以前不注意代碼規(guī)范，覺得反正是我自己寫的代碼，寫的快、寫的爽就完事了，管那么多干嘛？

但后來因?yàn)樽兞棵^隨意，導(dǎo)致自己寫的代碼自己都看不懂，更別提其他人來閱讀和協(xié)作開發(fā)了。

就連之前粗心拼錯(cuò)的變量名也根本不敢亂改，生怕漏改了一個(gè)地方，就會(huì)報(bào)找不到變量的錯(cuò)誤了！

復(fù)制粘貼

復(fù)制粘貼可以說是我寫代碼時(shí)用的最多的技能了。

正常操作是：3 秒粘貼一個(gè)文件，隨便改兩下，代碼能跑就行。

復(fù)制粘貼雖然好，但稍有不注意，可能就會(huì)漏修改一些變量名或注釋，比如下圖的 student ：

這樣的次數(shù)多了，往往會(huì)導(dǎo)致整個(gè)項(xiàng)目中出現(xiàn)很多相同的變量，其他同學(xué)要引入時(shí)，根本不知道應(yīng)該選哪個(gè)！

硬編碼

寫代碼時(shí)經(jīng)常會(huì)用到一些常量，就是固定的值，比如網(wǎng)站的地址、最大最小值、機(jī)器的 IP 地址等。

有時(shí)，為了圖省事，我就是不單獨(dú)為這些值定義變量。哪里用到這些值，我就復(fù)制粘貼一遍，直接寫死到代碼里，比如：

// 連接數(shù)據(jù)庫，IP 寫死
DB db = new DB("10.0.0.1");

這樣雖然簡(jiǎn)單粗暴，但假如哪一天這些死值需要修改了，就得從所有文件中一個(gè)個(gè)去找用到這些值的代碼，再一個(gè)個(gè)改掉，不僅麻煩，還很容易出現(xiàn)遺漏，從而產(chǎn)生 Bug。

未釋放資源

想從數(shù)據(jù)庫中獲取數(shù)據(jù)，就要先和數(shù)據(jù)庫建立連接，占用連接資源。

拿到需要的數(shù)據(jù)后呢，我就忘了要把資源進(jìn)行釋放（close），結(jié)果導(dǎo)致數(shù)據(jù)庫連接很快被占滿，其他程序想訪問都訪問不了，導(dǎo)致很多功能失效。

不僅是新手，甚至有幾年編程經(jīng)驗(yàn)的同學(xué)都可能會(huì)犯這個(gè)錯(cuò)，因?yàn)椴会尫刨Y源并不會(huì)功能的可用性，而且不壓測(cè)的話很難發(fā)現(xiàn)這個(gè) Bug。

此外，還有 HTTP 連接、文件輸入輸出流，這些都是資源，都要注意是否需要手動(dòng)釋放，稍有不慎，就會(huì)導(dǎo)致資源泄露的 Bug。

圈復(fù)雜度過高

圈復(fù)雜度是衡量代碼復(fù)雜度的標(biāo)準(zhǔn)，簡(jiǎn)單地說，if / else 分支越多，圈復(fù)雜度越大，往往表示代碼越復(fù)雜。

記得我就寫過一個(gè)特別復(fù)雜的邏輯，幾十個(gè)分支語句一層套一層：

if (xxx) {
} else if (xxx) {
    if (xxx) {
        if (xxx) {
       } else if (xxx) {
      if (xxx) {
        ??
     }
           }
    }
}

起初是懶得去優(yōu)化代碼，但等到后來意識(shí)到情況不妙，想優(yōu)化代碼時(shí)，卻發(fā)現(xiàn)這屎山已經(jīng)動(dòng)不得了。不光別人看不懂，我自己都看不懂了！

這種代碼一旦要加增改邏輯，就很容易出現(xiàn) Bug。所以建議在寫復(fù)雜邏輯前先畫流程圖，理清楚代碼、多寫注釋，還可以適當(dāng)?shù)赜贸橄蟆⒎庋b、設(shè)計(jì)模式之類的技術(shù)來減少代碼的圈復(fù)雜度。

依賴沖突

依賴 是指我們項(xiàng)目中要用到的框架、類庫等等別人寫好的代碼和工具。

像我以前做項(xiàng)目圖省事，要用到什么庫都往項(xiàng)目里塞，而且都用最新版本的。直到工作后才發(fā)現(xiàn)，對(duì)于一個(gè)大項(xiàng)目，很多人同時(shí)開發(fā)，往往要引入很多很多依賴，稍有不慎就產(chǎn)生 依賴沖突 。

比如我給類庫 A 引入了類庫 C 的 1.0 版本，類庫 B 引入了類庫 C 的 2.0 版本，那如果項(xiàng)目要同時(shí)引入類庫 A 和類庫 B，到底該用類庫 C 的哪個(gè)版本呢？

依賴沖突的后果往往就是項(xiàng)目起不來，更嚴(yán)重的是直到項(xiàng)目執(zhí)行到?jīng)_突的函數(shù)時(shí)才突發(fā) Bug。

不區(qū)分環(huán)境

以前，我做網(wǎng)站時(shí)為了方便，在自己電腦上開發(fā)時(shí)，和已上線的項(xiàng)目用的是同一套環(huán)境，連接的是同一個(gè)數(shù)據(jù)庫。

結(jié)果有一天，我就忘記了這個(gè)事，在開發(fā)時(shí)造了一條假的不行的假數(shù)據(jù)，還不小心上傳了我的玉照：

結(jié)果大意了，這條數(shù)據(jù)實(shí)際上被插入到了線上的數(shù)據(jù)庫中，導(dǎo)致線上幾萬個(gè)用戶全都能看見。

這還是小事，萬一你在本地開發(fā)時(shí)寫了個(gè) Bug，不小心把線上數(shù)據(jù)全給刪了，那真的是要欲哭無淚了！

不做自測(cè)

企業(yè)開發(fā)中，測(cè)試是很重要的。一般情況下，除了測(cè)試同學(xué)要設(shè)計(jì)用例外、開發(fā)同學(xué)也要寫單元測(cè)試來自測(cè)。

像我以前就很自信，自己寫好的代碼能跑就行，從來不測(cè)試，就是一把梭！

但進(jìn)入企業(yè)工作后，我發(fā)現(xiàn)不寫單元測(cè)試真的很容易出現(xiàn)各種細(xì)節(jié)問題?？赡芟聜€(gè)版本改了行代碼，之前正常的功能就突然報(bào)錯(cuò)了。

而且越往后發(fā)現(xiàn)問題，修改的成本就越大，要花更多時(shí)間去排查和修改 Bug，加班也在所難免。

不做評(píng)估

以前在學(xué)校寫代碼，我一般就是學(xué)什么技術(shù)就用什么、會(huì)什么就用什么，也不去管是否能滿足性能、數(shù)據(jù)量的要求。

進(jìn)入大公司后，才意識(shí)到系統(tǒng)評(píng)估和技術(shù)選型的重要性。一般要評(píng)估系統(tǒng)的并發(fā)量、數(shù)據(jù)的量級(jí)、接口時(shí)延等，根據(jù)這些來選擇合適的技術(shù)。

比如公司有一個(gè)千萬數(shù)據(jù)量的項(xiàng)目，如果我不做評(píng)估和選型，無腦用 MySQL 數(shù)據(jù)庫、并且不做任何優(yōu)化，那這個(gè)系統(tǒng)估計(jì)分分鐘掛掉。

自作主張

在學(xué)校的時(shí)候習(xí)慣了單兵作戰(zhàn)，想改什么代碼就改什么，也不去思考對(duì)現(xiàn)有系統(tǒng)、對(duì)其他系統(tǒng)的影響。

但在企業(yè)中，尤其是調(diào)用關(guān)系很復(fù)雜的鏈路系統(tǒng)中，如果你修改了接口的返回值，或者改變了接口的并發(fā)量、返回時(shí)長(zhǎng)等。分分鐘，依賴你接口的同事就都來登門拜謝了。

為了預(yù)防這種情況，建議整理下自己的接口依賴哪些接口、又被哪些接口調(diào)用。在你需要改動(dòng)代碼時(shí)，需要評(píng)估改動(dòng)對(duì)于其他系統(tǒng)的影響，并且及時(shí)通知相關(guān)負(fù)責(zé)人。而不是自作主張，只關(guān)注自己的一畝三分地。

文檔讀不全

現(xiàn)在的技術(shù)框架啥的，一般都提供了非常詳細(xì)的使用文檔。

但我以前讀文檔時(shí)，為了追求效率，只要看到有自己需要的函數(shù)，立刻就直接復(fù)制過來用了，而不是選擇把文檔完整讀完。

結(jié)果呢，因?yàn)槊つ孔孕?，很多文檔中重點(diǎn)強(qiáng)調(diào)的注意事項(xiàng)沒有看到，導(dǎo)致了很多傻不拉幾的低級(jí) Bug，還在網(wǎng)上到處搜解決方案，浪費(fèi)時(shí)間。

版本號(hào)錯(cuò)誤

讀文檔和看教程學(xué)技術(shù)可不一樣，不要盲目追求最新的，而是要根據(jù)實(shí)際情況，選擇和自己項(xiàng)目中引入一致的版本。

記得我剛開始跟著文檔學(xué)編程時(shí)，寫的很多 Bug 都是因?yàn)殚喿x文檔前沒有注意版本號(hào)，導(dǎo)致很多使用到的語法不是被淘汰了就是還不支持，然后就會(huì)懷疑人生。

不了解需求

寫代碼之前，一定要了解需求，就是要做什么？為什么要做？

否則就會(huì)像我剛進(jìn)入公司時(shí)，有個(gè)功能點(diǎn)沒搞懂，也不去問、不敢問產(chǎn)品同學(xué)，全靠自己自由發(fā)揮。就最后哪怕我的代碼能運(yùn)行、沒 Bug，但并不是用戶想要的，那不就表示：我程序的存在本身就是個(gè) Bug？

不做設(shè)計(jì)

寫代碼和蓋房子一樣，一定要先想好怎么寫代碼，再去寫。

尤其是業(yè)務(wù)流程復(fù)雜的時(shí)候，不要仗著自己聰明或者經(jīng)驗(yàn)豐富，就不寫方案、不做設(shè)計(jì)，而是直接打開編輯器就寫代碼。

這樣做很容易遺漏一些要考慮的關(guān)鍵點(diǎn)，說不定直到最后，才發(fā)現(xiàn)有大問題，結(jié)果整段邏輯都要全部刪掉重新寫！效率反而更低。

最后，一定要記?。∠雽W(xué)好編程，就要多寫代碼、多試錯(cuò)、多解決 Bug、多積累總結(jié)。幾年之后，再來看當(dāng)時(shí)的翻車經(jīng)歷，也是寶貴的財(cái)富啊。

以上就是本期分享，我是魚皮，求個(gè) 點(diǎn)贊 + 在看 ，這將是我持續(xù)創(chuàng)作的最大動(dòng)力，謝謝 ??