在進行嵌入式軟件開發(fā)過程中，產(chǎn)生一些bug是難免的，工作年限比較長的朋友應(yīng)該都會有這樣的感受:"有一定規(guī)模的軟件工程幾乎不可能沒有bug"，軟件邏輯不可能那么天衣無縫，軟件測試也不會百密沒有一疏，代碼和bug就是一個此消彼長、相互依賴的過程。 經(jīng)常聽一些朋友說道:"你寫的代碼沒有bug，那你離丟飯碗不遠了"，又或者代碼中故意保留一些bug來增強自己在團隊中的存在感，這樣就變得無可替代了,怎么說呢，雖然這些觀點有些不道德，但也從側(cè)面透露出打工人的辛酸與無奈。 據(jù)觀察，大部分的工程師都是“七分寫，三分調(diào)”，當然有些人該反駁了，"我怎么感覺是三分寫，七分調(diào)嗎？"，如果你是這樣的狀態(tài)去編寫和調(diào)試你的代碼，我至少會認為你不專業(yè)或者編碼能力不夠，思維邏輯能力不行～ 一個經(jīng)驗老道的軟件工程師調(diào)試代碼的時間都是非常短的，甚至可以一把搞定。 這樣看來對于一般工程師們，調(diào)試所占據(jù)的比例還是比較高的，當然調(diào)試過程并不一定全是解決bug，特別是在嵌入式領(lǐng)域，一方面要適配硬件平臺，甚至還要協(xié)助硬件排查硬件相關(guān)的問題；另一方面才是前期編碼所導(dǎo)致的一些程序bug。 然而調(diào)試結(jié)束后，與bug之間的斗爭遠遠沒有結(jié)束，當把第一個版本提交給測試，就意味著后面會有N個版本，測試過程中、用戶使用中、增加新需求時、修護原有bug時等等都可能引入新的bug。 所以bug基本上伴隨著你整個產(chǎn)品的迭代過程，這或許也是你作為一個程序員存在的理由。 這樣看來，bug一直有，那產(chǎn)品是不是么辦法做好了？其實隨著bug的消滅，產(chǎn)品的“相對穩(wěn)定性”是不斷增強的，也就意味著以后的bug沒那么致命、沒那么容易出現(xiàn)、客戶的使用也并不會觸發(fā)等等。 如果這個時候你說這個軟件沒有bug了，至少我不會相信。 既然大家都一直與bug糾纏，是不是應(yīng)該有一些經(jīng)驗了呢？知己知彼才能百戰(zhàn)百勝。 所以bug菌這里把最近所想到的、非常有意義的部分記錄了一下分享給諸位：

1

else不處理

工作這么多年，我算是看過很多人寫代碼了，經(jīng)常有同事寫if容易丟掉else，其實這是一個非常不好的習(xí)慣。

如果在編碼的時候else部分不需要處理，倒無傷大雅，但else部分存在一些相關(guān)變量需要置位或者釋放等，而你沒有else處理，便會引入bug。

所以我的習(xí)慣就是即使else不需要處理也會保留下來，并且在其中進行相關(guān)注釋，以提醒自己這一塊是有邏輯處理的。

2

可視化日志

相信很多朋友都有看到過類似的文章。比如什么串口打印日志技巧、easylog等開源日志庫、離線日志記錄工具等等，這些東西都是圍繞著一個主題為程序員提供一個可視化的日志信息展示。

因為大部分人的暫態(tài)大容量記憶能力是較弱的，這樣會導(dǎo)致我們對于一些邏輯中狀態(tài)的梳理處于劣勢，特別是一些復(fù)雜的邏輯處理和梳理，使得最終編寫的代碼容易引入邏輯問題。

所以通過可視化日志的方式輔助程序員進行程序相關(guān)狀態(tài)的記錄，從而便捷的定位問題，解決bug。

3

bug與代碼要匹配

經(jīng)?？蛻艋蛘邷y試反饋一些bug，有些朋友收到就立馬一頭扎進最新的代碼中進行查證，其實這個問題的出現(xiàn)是老版本上，導(dǎo)致自己忙前忙后還找不到問題的根源，所以軟件的版本管控是非常重要的，這樣才能對癥下藥。

以前去過一家公司，軟件方面沒人管控，代碼隨便改，其中一個代碼改了10幾遍，版本號什么的一直不變，這樣的話一旦有問題，這個真的是一件頭疼的事情。

4

?；仡^看看

這種方式主要是應(yīng)對一些新增需求導(dǎo)致的軟件bug，以前版本運行好幾個月都沒有問題，而更新到新版本沒多久就產(chǎn)生了故障，此時需要做的就是對比之前的代碼來進行修改點的查驗和評估。

在軟件中比較模棱兩可的位置，多看看歷史版本對其的設(shè)計和所考慮的問題，防止修改以后引入新的問題。

5

不要你認為

以前非常有意思的一句話:"我不要你認為，我要我認為"，這句話確實有點狂妄自大之感，但是在"標準"面前就是這么現(xiàn)實。

經(jīng)常有朋友在解決bug的過程中抱著猜一猜的心態(tài)，這樣是非常不專業(yè)的。

對于軟件運行本身是沒有bug這一說法的，程序都是按照你寫的代碼序列在運行著，之所以稱軟件有bug，無非就是它沒有按照你想要的邏輯運行罷了。

那這個問題并不是在軟件本身而是你自身的編碼能力，如果對于你所寫的代碼問題都還是猜一猜的方式去解決問題，那這個bug估計會越滾越大。

所以怎么算解決bug呢？一定要分析bug產(chǎn)生的前因后果，而不是“我把下面這行代碼屏蔽了問題就不出現(xiàn)”等等不負責任的方式。

當然有時候你有這樣的做法，我也能理解，畢竟有時候客戶可耗不起你分析的時間，設(shè)備停機1個小時10來w，你看著賠償就好了～

6

假如XXX會怎樣

寫軟件的朋友，腦袋瓜子相對比較靈活，這都是多年訓(xùn)練的結(jié)果。

在設(shè)計軟件的時候應(yīng)該多做一些假設(shè)，比如程序中等待兩個信號到來便會進行相應(yīng)的處理，此時此刻你就需要考慮其中有一個信號遲遲沒有到來超時了程序會怎么樣？

或者兩個信號接收的順序是否會對程序造成影響之類的問題？

解析一些通信數(shù)據(jù)，不可能每次都那么穩(wěn)定的傳輸，如果存在粘包、斷包、錯誤包該如何處理等等？

當你在寫代碼的過程中面面俱到，這樣寫出來的程序才會相對更加穩(wěn)定，當然要做到這種境界也得一日之寒，需要不斷的積累和理解。

審核編輯 ：李倩