隨著技術(shù)的不斷進(jìn)步，客戶期望越來(lái)越高，嵌入式設(shè)備變得越來(lái)越智能，對(duì)應(yīng)的嵌入式系統(tǒng)和軟件也變得越來(lái)越復(fù)雜，同時(shí)產(chǎn)品的開發(fā)周期變得越來(lái)越短。如何在短時(shí)間內(nèi)開發(fā)出高質(zhì)量的軟件對(duì)產(chǎn)品的成功起著決定性的作用。提高代碼質(zhì)量是一個(gè)系統(tǒng)工程，本文主要介紹開發(fā)人員如何在日常開發(fā)過(guò)程中提高代碼質(zhì)量。

01

什么是代碼質(zhì)量？

代碼質(zhì)量一般用于衡量代碼的“好”和“爛”：“好”代碼表示代碼質(zhì)量高，“爛”代碼表示代碼質(zhì)量低。雖然目前代碼質(zhì)量沒有一個(gè)單一客觀的定義，但是代碼質(zhì)量一般可以通過(guò)一些指標(biāo)來(lái)衡量：

可讀性(Readability)：“好”代碼應(yīng)該易于閱讀和理解。

可靠性(Reliability)：“好”代碼應(yīng)該是可靠的(Bug越少，代碼質(zhì)量越高)。

可測(cè)試性(Testability)：“好”代碼應(yīng)該易于測(cè)試。

可重用性(Reusability)：“好”代碼應(yīng)該易于在不同項(xiàng)目里面重用。

可維護(hù)性(Maintainability)：“好”代碼應(yīng)該易于修改和維護(hù)。

可擴(kuò)展性(Extensibility)：“好”代碼應(yīng)該易于擴(kuò)展。

可移植性(Portability)：“好”代碼應(yīng)該易于在不同的平臺(tái)上移植。

02

如何提高代碼質(zhì)量？

提高代碼質(zhì)量不是一項(xiàng)一次性任務(wù)，而是一項(xiàng)需要長(zhǎng)期堅(jiān)持的實(shí)踐。下面是目前常用的一些提高代碼質(zhì)量的實(shí)踐：

遵循編碼標(biāo)準(zhǔn)：編碼標(biāo)準(zhǔn)是前輩總結(jié)的一些編碼最佳實(shí)踐和經(jīng)驗(yàn)教訓(xùn)。編碼標(biāo)準(zhǔn)一般分為公司內(nèi)部編碼標(biāo)準(zhǔn)(比如代碼風(fēng)格和命名規(guī)則等)和行業(yè)編碼標(biāo)準(zhǔn)(比如MISRA， CERT和CWE等)。

靜態(tài)代碼分析：靜態(tài)代碼分析可以幫助檢查代碼是否遵循相關(guān)編碼標(biāo)準(zhǔn)。

單元測(cè)試：?jiǎn)卧獪y(cè)試主要是功能測(cè)試，可以幫助測(cè)試代碼是否符合對(duì)應(yīng)的設(shè)計(jì)，確保代碼功能的正確性。

代碼審查：代碼審查可以加強(qiáng)開發(fā)者之間的協(xié)作，幫助檢查代碼中潛在的邏輯問題。

使用版本控制：使用版本控制可以管理代碼變更歷史，同時(shí)方便團(tuán)隊(duì)協(xié)作。

CI/CD：CI/CD可以實(shí)現(xiàn)自動(dòng)化構(gòu)建、靜態(tài)代碼分析和單元測(cè)試。

03

為什么需要在日常開發(fā)過(guò)程中提高代碼質(zhì)量？

下面是Capers Jones 的著作“Applied Software Measurement: Global Analysis of Productivity and Quality”里面關(guān)于Bug引入、檢測(cè)和修復(fù)成本的一張圖：

絕大部分Bug是在日常開發(fā)編碼階段引入的。

Bug發(fā)現(xiàn)的越早，越容易修復(fù)，修復(fù)成本越低；反之Bug發(fā)現(xiàn)的越晚，越難修復(fù)，修復(fù)成本越高。

在日常開發(fā)編碼階段過(guò)程中提高代碼質(zhì)量，可以盡早發(fā)現(xiàn)代碼中的Bug，盡快修復(fù)代碼中的Bug，大大降低修復(fù)Bug的成本。

04

如何在日常開發(fā)過(guò)程中提高代碼質(zhì)量？

前面介紹了提高代碼質(zhì)量的一些通用實(shí)踐，下面具體介紹開發(fā)人員如何在日常開發(fā)過(guò)程中提高代碼質(zhì)量。

構(gòu)建0 Error和0 Warning

在構(gòu)建的時(shí)候，開發(fā)人員會(huì)做到0 Error (因?yàn)镋rror會(huì)導(dǎo)致構(gòu)建失敗)。但是很多時(shí)候沒有做到0 Warning (因?yàn)閃arning不會(huì)導(dǎo)致構(gòu)建失敗)。但是Waring有可能是潛在的隱藏的Bug。

下面是一個(gè)經(jīng)典的編譯器Warning：提示應(yīng)該使用比較運(yùn)算符==而不是賦值符=：

修改之后重新構(gòu)建：0 Error和0 Warning:

靜態(tài)代碼分析

構(gòu)建0 Error和0 Warning之后，建議先做靜態(tài)代碼分析，因?yàn)殪o態(tài)代碼分析不需要運(yùn)行代碼，分析起來(lái)比較方便快捷，而且靜態(tài)代碼分析能檢測(cè)出一些常見的代碼錯(cuò)誤。

在IAR Embedded Workbench當(dāng)中，只需要先勾選對(duì)應(yīng)的C-STAT靜態(tài)代碼檢查規(guī)則：

就可以使用C-STAT對(duì)整個(gè)工程進(jìn)行靜態(tài)代碼分析：

也可以使用C-STAT對(duì)單個(gè)文件進(jìn)行靜態(tài)代碼分析：

分析完成后，對(duì)應(yīng)C-STAT Messages窗口會(huì)顯示對(duì)應(yīng)檢查結(jié)果，雙擊對(duì)應(yīng)信息可以定位到源代碼位置：

如果不太熟悉對(duì)應(yīng)檢查規(guī)則，可以按F1，會(huì)彈出對(duì)應(yīng)幫助文檔(包含對(duì)應(yīng)檢查規(guī)則的描述，對(duì)應(yīng)編碼標(biāo)準(zhǔn)以及違反和遵循對(duì)應(yīng)規(guī)則的代碼示例等)來(lái)幫助快速定位和解決問題：

根據(jù)幫助文檔中的信息，推測(cè)需要將代碼里面的4u改成(int32_t) 4。修改代碼之后重新進(jìn)行靜態(tài)代碼分析，之前的違反修復(fù)了：

使用IAR C-STAT可以非常方便地進(jìn)行靜態(tài)代碼分析并且迅速得到反饋，以確保代碼符合相應(yīng)的編碼標(biāo)準(zhǔn)。

單元測(cè)試

在靜態(tài)代碼分析之后，建議做單元測(cè)試。因?yàn)殪o態(tài)代碼分析只能檢查代碼是否遵循相關(guān)編碼標(biāo)準(zhǔn)，代碼的功能測(cè)試還需要單元測(cè)試。IAR本身沒有提供單元測(cè)試工具，IAR有很多提供單元測(cè)試工具的合作伙伴。同時(shí)IAR里面的C-RUN動(dòng)態(tài)代碼分析可以幫助在單元測(cè)試時(shí)發(fā)現(xiàn)一些潛在的問題。

在IAR Embedded Workbench當(dāng)中，只需要勾選對(duì)應(yīng)的C-RUN動(dòng)態(tài)代碼檢查規(guī)則：

重新構(gòu)建，編譯器會(huì)在有可能出現(xiàn)違反的地方自動(dòng)插入對(duì)應(yīng)的測(cè)試代碼。

在運(yùn)行的時(shí)候C-RUN會(huì)檢測(cè)是否有對(duì)應(yīng)的違反，比如下面C-RUN Messages提示訪問越界：

分析發(fā)現(xiàn)對(duì)應(yīng)數(shù)組的大小是4，但是錯(cuò)誤地引用了[4]( [4]是數(shù)組的第5個(gè)元素)，導(dǎo)致訪問越界。修改代碼之后重新測(cè)試OK (C-RUN Messages窗口沒有對(duì)應(yīng)違反)：

代碼審查 在單元測(cè)試完成之后，建議邀請(qǐng)同伴做代碼審查(為了提高代碼審查的效率，建議在構(gòu)建、靜態(tài)代碼分析和單元測(cè)試完成之后再做代碼審查)。

CI/CD

在代碼審查完成之后，建議上傳代碼到服務(wù)器進(jìn)行自動(dòng)化工作流。

IAR提供了對(duì)應(yīng)的自動(dòng)化工具IAR Build Tools可以通過(guò)命令行的方式進(jìn)行自動(dòng)化構(gòu)建、靜態(tài)代碼分析和下載調(diào)試(用于單元測(cè)試)：

05

總結(jié)

在與用戶的交流中，我們欣喜地發(fā)現(xiàn)越來(lái)越多的公司和開發(fā)人員意識(shí)到代碼質(zhì)量的重要性，但同時(shí)也發(fā)現(xiàn)了一些問題：

有些公司居然沒有對(duì)代碼進(jìn)行靜態(tài)代碼分析、單元測(cè)試和代碼審查，代碼的正確性和質(zhì)量完全依靠最后的產(chǎn)品測(cè)試。

有些公司購(gòu)買了非常好的靜態(tài)代碼分析和單元測(cè)試工具，但是遺憾的是這些工具并沒有被開發(fā)人員在日常開發(fā)過(guò)程中充分使用，而是等到發(fā)布軟件版本之后才對(duì)整個(gè)工程進(jìn)行靜態(tài)代碼分析和單元測(cè)試。

有些公司還沒有部署自動(dòng)化工作流(開發(fā)人員的時(shí)間非常寶貴，要盡量對(duì)代碼進(jìn)行自動(dòng)化構(gòu)建、靜態(tài)代碼分析和單元測(cè)試，這樣開發(fā)人員就可以盡快收到反饋，提高代碼質(zhì)量的同時(shí)也提升研發(fā)效率)。

本文以IAR Embedded Workbench和IAR Build Tools(包含C-STAT靜態(tài)代碼分析和C-RUN動(dòng)態(tài)代碼分析)為例介紹了開發(fā)人員如何在日常開發(fā)過(guò)程中提高代碼質(zhì)量。

需要注意的是，文中的IAR Embedded Workbench和IAR Build Tools(包含C-STAT靜態(tài)代碼分析和C-RUN動(dòng)態(tài)代碼分析)只是工具示例，文中的策略也適用于其它工具。

選擇對(duì)應(yīng)的工具很重要，但是更重要的是：開發(fā)人員需要在日常開發(fā)過(guò)程中充分利用好對(duì)應(yīng)的工具來(lái)提高代碼質(zhì)量。因?yàn)榻^大部分Bug是在日常開發(fā)編碼階段引入的，Bug發(fā)現(xiàn)的越早，越容易修復(fù)，修復(fù)成本越低；反之Bug發(fā)現(xiàn)的越晚，越難修復(fù)，修復(fù)成本越高。

更多關(guān)于IAR Embedded Workbench和Build Tools(包含C-STAT靜態(tài)代碼分析和C-RUN動(dòng)態(tài)代碼分析)的信息，可以參考：

https://www.iar.com/zh/products/architectures/arm/iar-embedded-workbench-for-arm/

https://www.iar.com/zh/products/architectures/arm/iar-build-tools-for-arm/

https://www.iar.com/zh/products/c-stat

https://www.iar.com/zh/products/c-run