有一項活動總是占用嵌入式軟件項目的財務(wù)和交付預算：調(diào)試。嵌入式開發(fā)人員平均花費20-40%的時間調(diào)試代碼!但如果你想按時按預算交付，你必須知道如何避免花時間調(diào)試。鑒于當今系統(tǒng)的復雜性，你可能會認為這是不可避免的。在今天的文章中，我們將探討可以用來避免調(diào)試的四種策略。
策略1：使用測試驅(qū)動的開發(fā)
測試驅(qū)動開發(fā)是一種敏捷技術(shù)，開發(fā)人員使用測試來驅(qū)動代碼開發(fā)。開發(fā)人員創(chuàng)建一個測試功能所需的測試列表。有了清單，他們實現(xiàn)了一個測試，然后編寫代碼使其通過。一旦完成，他們就進入下一個測試。這個過程被稱為TDD周期。
TDD周期包括以下步驟：
1.添加一個小測試。
2.運行所有的測試，看到新的測試失敗，甚至可能沒有編譯。
3.進行必要的小更改以通過測試。
4.運行所有測試并查看新測試是否通過。
5.重構(gòu)以消除重復并提高表現(xiàn)力。
目標是在沒有測試驗證的情況下編寫任何生產(chǎn)代碼。編寫代碼以通過匹配的測試可以減少調(diào)試的需要。事實上，如果有bug，你會立刻發(fā)現(xiàn)的!這樣做的好處是，當開發(fā)人員已經(jīng)忘記了代碼區(qū)域時，錯誤不會堆積起來，等待在開發(fā)周期的后期發(fā)現(xiàn)和解決。
策略2：經(jīng)常跟蹤代碼執(zhí)行
團隊在調(diào)試方面花費大量精力的一個領(lǐng)域不一定是功能實現(xiàn)，而是系統(tǒng)性能。嵌入式開發(fā)團隊通常會快速編寫和集成代碼。在此過程中，他們可能不會測量自己的系統(tǒng)性能。畢竟，早期的代碼不會顯示性能問題，因為它可以訪問所有處理器的帶寬。隨著功能的增加，系統(tǒng)會變得遲鈍，或者可能無法滿足其實時性能要求。
防止系統(tǒng)出現(xiàn)性能問題的策略是定期或在可能的情況下不斷測量和監(jiān)控系統(tǒng)性能。追蹤工具可以讓你盡早發(fā)現(xiàn)潛在的問題，并在它們成為重大問題之前解決它們。
策略3：使用斷言
當系統(tǒng)中確實出現(xiàn)錯誤時，通常很難確定原因。你通常必須逐步完成代碼，并嘗試隔離問題發(fā)生的位置。為了盡可能避免這種情況，可以采用的一種策略是使用斷言。斷言是對代碼中某一點的檢查，用于驗證代碼中該點的假設(shè)是否正確。如果斷言不正確，那么這就是一個錯誤!
在嵌入式開發(fā)中，斷言在軟件中有很多用途。例如，使用斷言的常見地方是檢查函數(shù)中的輸入和輸出條件。如果你有一個函數(shù)指定輸入范圍為0到100，并且該函數(shù)的用戶傳入了200，那么這就是一個錯誤!用戶不符合該功能的合同要求。斷言可以停止代碼的執(zhí)行，也可以記錄問題，而不是允許代碼繼續(xù)執(zhí)行。
策略4：實現(xiàn)日志記錄
日志記錄可以幫助你驗證系統(tǒng)是否按預期工作，但它也可以作為跟蹤，幫助你了解是什么導致了系統(tǒng)的錯誤行為。有趣的是，許多日志記錄系統(tǒng)都使用斷言來記錄信息!你可以選擇要記錄的信息，例如系統(tǒng)啟動數(shù)據(jù)、狀態(tài)數(shù)據(jù)、輸入/輸出消息等。
需要注意的是，雖然日志記錄非常有用，但必須保持平衡。過多的日志記錄可能會導致性能問題、存儲問題，以及難以篩選大量數(shù)據(jù)。如果你嘗試日志記錄，請從你認為至關(guān)重要的數(shù)據(jù)開始，然后再添加。
結(jié)論
如果你不小心，調(diào)試軟件很容易消耗你的開發(fā)周期。在這篇文章中，我們探討了幾種可以用來避免調(diào)試的策略。這些策略是唾手可得的成果，可以用最少的努力來實施，但卻能帶來最大的回報。實現(xiàn)這些實踐可以幫助嵌入式開發(fā)人員減少調(diào)試所花費的時間，提高代碼的整體質(zhì)量，使其更加健壯、可讀和可維護。
京公網(wǎng)安備 11010802030320號