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

1

else不處理

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

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

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

2

可視化日志

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

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

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

3

bug與代碼要匹配

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

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

4

常回頭看看

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

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

5

不要你認為

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

經常有朋友在解決bug的過程中抱著猜一猜的心態，這樣是非常不專業的。

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

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

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

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

6

假如XXX會怎樣

寫軟件的朋友，腦袋瓜子相對比較靈活，這都是多年訓練的結果。

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

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

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

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

審核編輯 ：李倩