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

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

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

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

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

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

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

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

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

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

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

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

提高編碼技能

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

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

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

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

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

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