及時交付嵌入式軟件的最大障礙之一是代碼的結構質量。嵌入式開發項目中的代碼質量通常在開始時還不錯，但是當團隊急于盡快實現功能時，質量會迅速下降。以兩個團隊為例：

　　l 團隊A專注于快速實現特性，很少關注結構化代碼的質量

　　l 團隊B關注結構質量，不太強調快速交付。

　　隨著時間的推移，交付的功能數量可能如下圖所示

　　在項目開始時，團隊A似乎是英雄，他們快速實現和交付特性，超過了團隊B。然而，團隊A的低結構代碼質量很快妨礙了他們交付更多特性。每一個新特性都需要花費更多的時間和巨大的努力來實現。結果，團隊A停滯不前，因為每次添加新功能時，他們都會陷入大量的調試活動中。

　　另一方面，B隊雖然看起來起步較慢，但卻穩步前進。隨著時間的推移，他們花在調試和處理代碼結構上的時間越來越少。與團隊A相比，他們最終會達到生產力和成本拐點。團隊B繼續前進，創造新的功能，這導致了兩個團隊之間的功能差距。

　　你希望你的團隊表現得像團隊B，而不是團隊A。評估你的代碼質量可以而且應該在整個嵌入式開發過程中進行。這里有三個評估嵌入式軟件代碼質量的技巧。

　　技巧1——分析你的軟件依賴性

　　高結構代碼質量的一個特點是軟件的高內聚和低耦合。內聚力指一個模塊內部的元素屬于一起的程度。高內聚意味著模塊中的一切都支持模塊在軟件中服務的功能，僅此而已。例如，一個USART模塊也不會支持CRC。雖然CRC可能用于傳遞給USART外設的串行數據，但計算CRC不屬于USART模塊。

　　耦合是軟件模塊之間的相互依賴程度;緊密相連的兩個模的度量。模塊之間的耦合度越高，依賴性就越大。在具有高結構質量的軟件中，軟件模塊具有最小數量的依賴性。低耦合是高結構質量的標志。模塊耦合得越緊密，一個模塊中的變化對另一個模塊的影響就越大。如果一個團隊不小心，他們的軟件結構可能會變成一個“大泥球”。

　　大泥球

　　通過對軟件進行依賴性分析，很容易識別出一大團泥巴。下面是一個大泥球的例子:

　　分析相關性

　　嵌入式開發團隊在開發軟件時應該分析他們的軟件架構和相關性。如果他們這樣做了，他們就可以在早期識別潛在的耦合問題，并在它們演變成問題之前解決它們。

　　技巧2——測量函數長度

　　評估代碼質量的一個簡單方法是測量代碼庫中每個函數的長度。從統計上看，大型函數包含bug的概率更高。在許多情況下，長函數表明該函數不符合單一責任原則!每個功能應該只做一件事，并且只負責做一件事。(注意:這個原則通常應用于類或模塊級別，但在C中，它也可以應用于函數級別)。

　　大型函數通常做得太多，這表明代碼質量存在潛在問題。分析代碼可以指出潛在的問題。例如，在下圖中，你可以看到示例代碼庫中最大的函數和文件。代碼中最重要的函數有5000多行代碼(LOC)!另一方面，有一個接近18,000 LOC的模塊!

　　每個功能的LOC度量可以識別在分析代碼庫時可能存在問題的模塊。當識別出這樣的代碼時，它們是高優先級的函數、文件和模塊，需要重構并分解成更有意義的單元。例如，一個5000行的函數可能被分解成50個更清晰、更易維護的輔助函數。但是，像這樣的大型函數通常幾乎無法測試!

　　技巧# 3——每個代碼單元都應該有測試

　　測試，尤其是單元測試，對于確保代碼的高質量至關重要。嵌入式開發人員測試驗證該功能是否滿足該功能應該做什么的要求。如果你沒有對你的函數進行測試，那么你就沒有辦法驗證該函數是否做了它應該做的事情!此外，當代碼更改時，沒有辦法知道你是否破壞了任何東西，除非有測試來驗證該函數仍然按預期運行。

　　測試可以是代碼結構質量的最大指示器。這是因為在編寫單元測試時，開發人員經常被迫管理依賴關系，最小化耦合，抽象他們的接口，并執行許多其他最佳實踐。因此，結構質量低的代碼通常難以測試。相反，具有高結構質量的代碼易于測試。

　　評估代碼質量結論

　　結構化代碼的質量可以與團隊是否能在預算內按時交付軟件聯系起來。高結構代碼質量將導致一致的特性交付，實現高質量的結構化代碼不是偶然發生的事情，團隊必須建立過程和程序來評估和監控他們的軟件。質量問題更容易處理，因為它們發生了，而不是等到項目結束時，最簡單的事情就是重新開始。(這通常會導致同樣的問題再次出現)。

　　在今天的文章中，我們探討了如何衡量代碼質量的三個容易實現的技巧，如果你從這些技巧開始，你就能理解在嵌入式開發過程中你的嵌入式軟件中的缺陷和潛在問題。一旦你能看到并理解，只有這樣你才能開始你的行動計劃來提高你的軟件結構質量。