為什么我總寫 Bug ？

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

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

常見 Bug 誘因匯總

中文編碼

以java為例，下面是兩行最最最簡單的 Java 代碼，上面的代碼能運行，下面的代碼會報錯：

// 教程中的，能運行
System.out.println("Hello!");
// 我寫的，會報錯
System.out.println("Hello!")；

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

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

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

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

代碼不規(guī)范

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

但后來因為變量命名太過隨意，導(dǎo)致自己寫的代碼自己都看不懂，更別提其他人來閱讀和協(xié)作開發(fā)了。

就連之前粗心拼錯的變量名也根本不敢亂改，生怕漏改了一個地方，就會報找不到變量的錯誤了！

復(fù)制粘貼

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

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

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

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

硬編碼

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

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

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

這樣雖然簡單粗暴，但假如哪一天這些死值需要修改了，就得從所有文件中一個個去找用到這些值的代碼，再一個個改掉，不僅麻煩，還很容易出現(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)驗的同學(xué)都可能會犯這個錯，因為不釋放資源并不會功能的可用性，而且不壓測的話很難發(fā)現(xiàn)這個 Bug。

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

圈復(fù)雜度過高

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

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

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

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

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

依賴沖突

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

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

比如我給類庫 A 引入了類庫 C 的 1.0 版本，類庫 B 引入了類庫 C 的 2.0 版本，那如果項目要同時引入類庫 A 和類庫 B，到底該用類庫 C 的哪個版本呢？

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

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

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

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

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

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

不做自測

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

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

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

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

不做評估

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

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

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

自作主張

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

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

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

文檔讀不全

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

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

結(jié)果呢，因為盲目自信，很多文檔中重點強(qiáng)調(diào)的注意事項沒有看到，導(dǎo)致了很多傻不拉幾的低級 Bug，還在網(wǎng)上到處搜解決方案，浪費時間。

版本號錯誤

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

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

不了解需求

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

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

不做設(shè)計

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

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

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

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

往期推薦

1、我用一根網(wǎng)線，控制了整棟樓的網(wǎng)絡(luò)

2、這20個Pandas函數(shù)，堪稱"數(shù)據(jù)清洗"殺手！

3、再見 CSV，速度提升 150 倍！

4、如何找出 Python 程序中最慢的那行代碼？

5、國內(nèi)網(wǎng)友開發(fā)了個“在線黃圖檢測器”，把我看懵了

今天因為您的點贊和在看，讓我元氣滿滿！