正文

在進(jìn)行嵌入式軟件開發(fā)過程中，產(chǎn)生一些bug是難免的，工作年限比較長的朋友應(yīng)該都會(huì)有這樣的感受:"有一定規(guī)模的軟件工程幾乎不可能沒有bug"，軟件邏輯不可能那么天衣無縫，軟件測試也不會(huì)百密沒有一疏，代碼和bug就是一個(gè)此消彼長、相互依賴的過程。

經(jīng)常聽一些朋友說道:"你寫的代碼沒有bug，那你離丟飯碗不遠(yuǎn)了"，又或者代碼中故意保留一些bug來增強(qiáng)自己在團(tuán)隊(duì)中的存在感，這樣就變得無可替代了,怎么說呢，雖然這些觀點(diǎn)有些不道德，但也從側(cè)面透露出打工人的辛酸與無奈。

據(jù)觀察，大部分的工程師都是“七分寫，三分調(diào)”，當(dāng)然有些人該反駁了，"我怎么感覺是三分寫，七分調(diào)嗎？"，如果你是這樣的狀態(tài)去編寫和調(diào)試你的代碼，我至少會(huì)認(rèn)為你不專業(yè)或者編碼能力不夠，思維邏輯能力不行～ 一個(gè)經(jīng)驗(yàn)老道的軟件工程師調(diào)試代碼的時(shí)間都是非常短的，甚至可以一把搞定。

這樣看來對于一般工程師們，調(diào)試所占據(jù)的比例還是比較高的，當(dāng)然調(diào)試過程并不一定全是解決bug，特別是在嵌入式領(lǐng)域，一方面要適配硬件平臺(tái)，甚至還要協(xié)助硬件排查硬件相關(guān)的問題；另一方面才是前期編碼所導(dǎo)致的一些程序bug。

然而調(diào)試結(jié)束后，與bug之間的斗爭遠(yuǎn)遠(yuǎn)沒有結(jié)束，當(dāng)把第一個(gè)版本提交給測試，就意味著后面會(huì)有N個(gè)版本，測試過程中、用戶使用中、增加新需求時(shí)、修護(hù)原有bug時(shí)等等都可能引入新的bug。

所以bug基本上伴隨著你整個(gè)產(chǎn)品的迭代過程，這或許也是你作為一個(gè)程序員存在的理由。

這樣看來，bug一直有，那產(chǎn)品是不是么辦法做好了？其實(shí)隨著bug的消滅，產(chǎn)品的“相對穩(wěn)定性”是不斷增強(qiáng)的，也就意味著以后的bug沒那么致命、沒那么容易出現(xiàn)、客戶的使用也并不會(huì)觸發(fā)等等。

如果這個(gè)時(shí)候你說這個(gè)軟件沒有bug了，至少我不會(huì)相信。 既然大家都一直與bug糾纏，是不是應(yīng)該有一些經(jīng)驗(yàn)了呢？知己知彼才能百戰(zhàn)百勝。

所以bug菌這里把最近所想到的、非常有意義的部分記錄了一下分享給諸位：

1

else不處理

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

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

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

2

可視化日志

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

因?yàn)榇蟛糠秩说臅簯B(tài)大容量記憶能力是較弱的，這樣會(huì)導(dǎo)致我們對于一些邏輯中狀態(tài)的梳理處于劣勢，特別是一些復(fù)雜的邏輯處理和梳理，使得最終編寫的代碼容易引入邏輯問題。

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

3

bug與代碼要匹配

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

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

4

常回頭看看

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

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

5

不要你認(rèn)為

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

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

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

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

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

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

6

假如XXX會(huì)怎樣

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

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

或者兩個(gè)信號(hào)接收的順序是否會(huì)對程序造成影響之類的問題？

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

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

審核編輯：劉清