在上文《嵌入式軟件開發(fā)的十二大基本要素（四）：調(diào)試》中，我們分析了如何減少調(diào)試時間，提升工作效率。

本文為白皮書系列第五部分，將分析代碼質(zhì)量是如何影響企業(yè)的投資回報率（ROI）和總擁有成本（TCO）。

平均來說，根據(jù) Steve McConnell 的《Code Complete》，一個開發(fā)人員每寫 1000 行代碼會產(chǎn)生 70 個 Bug。其中大約 20%，即每 1000 行代碼中的 15 個 Bug 會被客戶發(fā)現(xiàn)。更糟的是，修復(fù)一個Bug 要比寫一行代碼多花 30 倍的時間。

通過在開發(fā)周期的早期引入代碼質(zhì)量控制，可以將錯誤的影響和消除錯誤的工作量降到最低。在每個開發(fā)人員的電腦上提供靜態(tài)分析，并有明確的編碼標準，可以幫助他們在開發(fā)過程中發(fā)現(xiàn)源代碼中的問題，在此階段犯錯的成本比發(fā)布產(chǎn)品后才發(fā)現(xiàn)要小得多。

此外，很多人都在談?wù)撛O(shè)計他們的代碼以便重用，但軟件估算模型表示重用的代碼所占的工作量至少是編寫新代碼的 50%。

如上圖所示的 Boehm 的 COCOMO 方法，估計了編寫代碼的相對成本是如何被對虛線中的重用軟件所做修改而影響的。X 軸是對打算重用的代碼所做修改的百分比，而Y 軸代表了寫新代碼的百分比。請注意，對于三個數(shù)據(jù)樣本中的兩個代碼，不需要對所謂的重用代碼做太多的修改，就可以突然跳到從頭開始重寫代碼的 50% 的工作量。AAM（自適應(yīng)調(diào)整修改器）線顯示，對重用產(chǎn)品中的小修改可以產(chǎn)生不成比例的大成本。這里的關(guān)鍵點是，如果真的想重復(fù)使用代碼，它必須具有非常高的質(zhì)量和良好的設(shè)計，以達到成本效益。

提高代碼質(zhì)量的最快方法是使用代碼分析工具。事實上，如果正在創(chuàng)建一個功能安全認證的應(yīng)用，你甚至會被強制要求使用靜態(tài)分析工具。這些類型的工具可以幫助你找到代碼中最常見的缺陷來源，也可以幫助你找到開發(fā)人員在試圖編寫代碼時往往不會考慮的問題，特別是當他們?yōu)榱俗屇承┕δ苓\行而加入支撐代碼時。靜態(tài)分析工具確實能幫助你開發(fā)出更好的代碼，因為它們強制執(zhí)行編碼標準。根據(jù)你的靜態(tài)分析解決方案的質(zhì)量，它們可以在你還在寫代碼的時候檢查出許多其它潛在的問題。

有幾個原因能夠證明代碼質(zhì)量是一個大問題。首先，根據(jù)開發(fā)組織的成熟度，開發(fā)人員可以把 90% 的時間花在調(diào)試上。如果能在缺陷進入正式構(gòu)建之前快速隔離它們，你就會有較低的缺陷注入率，這意味著可以更快地達到組織的質(zhì)量指標。其次，這也意味著你的代碼總體上有較少的剩余缺陷，這使得它成為重用的合適候選者，因為再次使用該代碼時，發(fā)現(xiàn)先前未被發(fā)現(xiàn)的缺陷的機會較低。高質(zhì)量的代碼由于缺陷較少而更容易維護，而且如果它遵循良好的軟件工程原則，它將更容易擴展，因此重用它確實能提升后續(xù)項目的速度。

為什么質(zhì)量很重要？

有趣的是，每個階段的每個缺陷的成本都如預(yù)期的那樣上升，但總成本卻在下降，就像 Capers Jones 的《Estimating Software Costs》一書中所示，缺陷數(shù)量在減少。在實踐中，發(fā)現(xiàn)和修復(fù)每個階段的錯誤并不需要更長的時間，但是盡管數(shù)量減少了，成本仍然存在。值得注意的是，隨著產(chǎn)品的成熟運行，由于服務(wù)于現(xiàn)場產(chǎn)品的影響，每個缺陷的維護成本要高很多。其他無形成本，如對品牌的損害和未來客戶和收入的損失，也仍然是需要考慮的因素。

那么，考慮到這些因素，投資的回報是什么呢？靜態(tài)分析可以減少軟件開發(fā)中各個階段的錯誤數(shù)量。一個簡單的分析是利用上圖中的數(shù)據(jù)來減少錯誤的數(shù)量。鑒于這種在開發(fā)過程中引入的錯誤的減少，我們可以看到成本的顯著降低。

這個簡單的分析得出每個 Bug 可以節(jié)省大約 126 美元，即假設(shè)在開發(fā)過程中每 1000 行代碼平均有 15 個 Bug，則轉(zhuǎn)化為每 1000 行代碼節(jié)省 1900 美元。當然，結(jié)果會基于其他因素，如勞動率、缺陷檢測和修復(fù)時間，以及缺陷密度，會有所不同。但由于許多系統(tǒng)使用 10 到 100 KLOC 或更多，因此靜態(tài)分析的商業(yè)案例顯而易見。

提高編碼技能

此外，在 Dr. Dobbs 所做的另一項研究中，認為它將缺陷注入率降低了 41%，這節(jié)省了大量測試時間，既縮短了工程時間，還加速了上市時間。

在這項研究中，每個月的缺陷注入率是相當穩(wěn)定的，直到該組織引入編碼標準，然后缺陷率急速下降。隨著開發(fā)人員對標準越來越熟悉，偏差越來越少，缺陷率直線下降。

Google 在 ACM 出版物上發(fā)表了一篇文章，探討了代碼分析的優(yōu)點。雖然文章對他們的整個代碼庫，包括 C、C++ 和 Java 進行了全面的考察，但結(jié)果非常明顯：“在開發(fā)過程的早期就能發(fā)現(xiàn)編譯器錯誤，并且能夠整合到開發(fā)人員的工作流程中。我們發(fā)現(xiàn)擴大編譯器的檢查集對提高 Google 的代碼質(zhì)量是有效的。”作者表示，將靜態(tài)分析檢查整合到編譯器工作流程并使其作為錯誤出現(xiàn)，極大地提高了開發(fā)人員對工具信息的關(guān)注，最終大幅提升代碼質(zhì)量。

再往下看，他們談到了向最近遇到編譯時間錯誤的開發(fā)人員和已經(jīng)收到修復(fù)同一問題的補丁的開發(fā)人員發(fā)出的調(diào)研。

“Google 的開發(fā)人員認為，在編譯時標記的問題（相對于檢查過的代碼的補丁）能捕捉到更重要的錯誤；例如，調(diào)研參與者認為 74% 在編譯時標記的問題屬于真正的問題，而在檢查過的代碼中發(fā)現(xiàn)的問題只有 21%。”

此外，文章還談到了將代碼分析整合到工作流程的重要性，指出當他們通過靜態(tài)分析工具自動運行提交的代碼并邀請工程師查看分析結(jié)果時，很少有工程師跟進。但是，如果在編譯過程中就能得到即時反饋，那么就會讓更多人使用靜態(tài)分析，且分析結(jié)果也更難被忽視。因此，Google 選擇在每個人的工作流程中默認集成靜態(tài)分析。他們認為要推廣代碼分析工具，開發(fā)人員必須感到能從中受益，并且喜歡使用這些工具。從中可以看出，編碼標準確實對開發(fā)工作有影響。