裝備研制的代碼質量提高方法研究

葛學仕，陳書恒

裝備研制的代碼質量提高方法研究

葛學仕，陳書恒

良好的代碼質量在裝備研制中十分重要，論文從架構、編碼、測試等環節分析了武器裝備軟件模塊可能存在的代碼質量問題，提出了具體可行的軟件開發準則，為較好保證軟件代碼質量打下堅實基礎。

代碼質量；軟件架構；軟件測試

0 引言

隨著武器裝備的現代化、信息化、智能化，各類武器裝備的研制需要大量的軟件設計工作。當前，對武器裝備軟件的關注主要側重于功能性方面，但對軟件本身的設計、編碼質量并不關注。然而在武器裝備不斷更新換代的背景下，軟件的設計、編碼質量是不可忽視的，它將極大影響軟件的運行效率、可靠性、維護成本、兼容性和擴展性。

以2007年豐田踏板門事件為例，由于豐田汽車動力控制軟件結構設計不合理、函數復雜度高、開發過程不規范，導致軟件缺陷不能被及時發現，造成其在緊急情況下不能正常制動。最終，該事件造成高達16億美元的損失[1]。

因此良好的代碼質量在裝備研制中是十分重要。良好的軟件代碼質量主要依賴于簡潔合理的架構設計、整潔干凈的編碼風格、覆蓋全周期的軟件測試，它們不僅是武器裝備軟件設計應該遵循的標準，也是軟件設計過程中具有極高可操作性的具體步驟。

1 簡潔合理的架構設計

軟件架構設計是指對系統功能模塊的合理劃分，對功能模塊間耦合關系的明確定義，對外部預留接口的準確規劃。無論是基于對象還是基于流程的軟件設計，這些都是其中的關鍵問題。合理的架構可以使軟件充分復用已有的資源，使軟件健壯地在各個平臺上運行，使軟件適應不斷的升級需求，同時降低開發周期、維護成本甚至決定整個項目的成敗。

設計模式是一套被反復使用、多數人知曉的、經過分類編目的代碼設計經驗總結。對重要設計模式的合理使用可以有效提高架構設計的質量，避免架構設計常見的錯誤。經典的設計模式有23種，如工廠模式、單實例模式、適配器模式、代理模式、觀察者模式等[2]。根據裝備研制中交聯設備多、遺留代碼多、升級改裝頻繁、控制流程復雜等特點，適配器模式、外觀模式等設計模式尤其值得重視：

1.1 適配器模式

在裝備研制中，往往需要與許多外部資源或系統集成進行數據交互或提供服務。例如，當飛機導航系統需要獲取慣導系統數據時，通常的做法是由慣導系統來提供一系列固定的對外接口，導航系統通過直接調用這些接口來獲實時數據。雖然這樣做能夠很好地完成功能性要求，但會造成系統的不良耦合。當導航系統需要被移植到使用其他慣導系統的飛機上時，就可能造成導航系統需要修改大量的代碼的問題甚至重新開發，因為對慣導數據獲取可能出現在導航系統的任何地方。

適配器模式為此提供了較好的解決方案，如圖1所示：

圖1 原系統獲取導航數據方式

當任務系統需要獲取慣導數據時，它并不需要知道任何外部細節，而是給出它所需要的接口定義。由適配器通過組合調用慣導系統接口等方式來實現任務系統所定義的接口。在使用該模式后，如圖2所示：

圖2 適配器模式下獲取導航數據方式

對于不同的慣導系統只需要更新適配器的實現，而任務系統不會受到任何影響。

1.2 外觀模式

裝備研制中，軟件系統大多較為復雜，擁有較多的子系統和外部系統，通過對它們的組合、協作，來完成軟件需要實現的功能。但在這類軟件設計過程中，大多存在子系統或外部系統暴露過多的細節，耦合度較高的問題。以某系統的硬件初始化過程為例，通常的設計是，系統的初始化函數會依次調用ARC 429總線、內部串行總線、北斗、GPS等模塊的端口設定、初始化命令發送、地址注冊等函數，如圖3所示：

圖3 原系統初始化過程

但對于系統初始化過程的業務邏輯來說，各個硬件模塊的初始化細節并不應該是關注的重點，逐一調用各個模塊的初始化函數會使系統與它們都發生耦合，導致各個子系統的初始化過程與系統本身的初始化邏輯混雜在一起，不利于核心業務邏輯的維護。因此，合理的設計模式是增加HardWare這個硬件外觀類來屏蔽核心業務與各個子系統的耦合，在系統的初始化函數中，只需要調用HardWare類封裝的Init函數來實現各個模塊的初始化工作，如圖4所示：

圖4 外觀模式下初始化過程

雖然上述設計模式僅是經典設計模式中的很小一部分，但從兩個范例中已經可以看出它們在架構設計中的作用，如果在架構設計中能夠合理準確地使用所有的設計模式，不僅會使軟件設計變得非常容易，研發效率大幅提高，也是高質量代碼的有力保障。

2 整潔干凈的編碼

武器裝備的軟件開發周期短，穩定性要求高，開發人員在開發過程中往往僅重視軟件的功能與性能指標，忽視軟件的代碼質量。較差的源碼雖然不會直接影響軟件的使用特性，但對軟件的升級維護、功能擴展、測試驗證會帶來較大的影響。尤其是維護歷史久遠、編寫不良的軟件，其成本不亞于完全新編寫[3]。編寫整潔的代碼應該具有可讀性性好、邏輯清晰、擴展簡易的特點。為了達到這些目標，以下準則是編寫代碼過程中必須遵守的。

2.1 合理的命名

源碼中變量、函數、類、文件都需要名字，命名的合理性是代碼可讀性的關鍵因素。不合理的命名會使代碼變得雜亂，使閱讀者無法在短時間內理解。使代碼命名變得合理應該遵循以下的命名規則：

1）名副其實，名字應能夠不借助注釋準確描述變量、函數的功能。

正面例子：

TimeSinceStartUp

反面例子：

T//開機至今的時間

2）避免名字中的誤導信息，對變量做有意義的區分，尤其應避免數字在命名中出現如N1、N2。在命名時同樣應避免INFO、DATA等沒有區分度的單詞，因為看到一個ProductInfo變量，讀者并不能從命名中得知這個變量包含的究竟是什么信息。

3）使用可以被讀出來且易于檢索的名字。

4）避免思維映射和雙關語

2.2 合理的注釋量

注釋在程序運行時不起任何作用，但它卻是優秀代碼的關鍵因素之一。合理的注釋不僅能夠幫助讀者理解程序的設計原理，幫助程序員記錄開發時的思想，也是測試人員進行白盒測試的重要依據。但注釋的數量并非越多越好，過多的依賴注釋會使程序員忽視代碼本身的可讀性，注釋僅應該在說明函數輸入輸出要求、說明文件或類的功能、說明重要模塊思想等時刻出現，注釋過多一般是添加了不必要的說明，或是代碼可讀性太差不得不使用注釋說明。

2.3 函數長度與參數量

函數是程序實現某項單一功能的最小模塊，函數設計應遵循精簡復用的原則。一般來說設計合理的函數代碼函數不應超過20行，函數的輸入參數不超過3個。過長的函數或過多的輸入參數往往意味著函數違背了單一功能的原則，這不僅會使函數本身的實現晦澀難懂，還會嚴重影響函數的復用性，使代碼變得冗長影響維護成本和效率。另一方面，過長的函數和過多的參數輸入會大大提高函數的單元測試的難度。為了實現相同的測試覆蓋度，每增加一行代碼、增加一個輸入參數，對應的測試用例需要幾何級數的增加。

實現整潔干凈的代碼風格需要程序員從編寫代碼的每一個細節入手，提高代碼的可讀性，使代碼結構變得合理。但這并不意味著維護良好的代碼風格會影響裝備軟件的開發進度，相反的可讀性較好的代碼可以大量減少文檔維護的需求、降低后續維護的時間成本、降低測試的難度并減少錯誤發生的概率，從而大大提升開發效率。

3 覆蓋全周期的測試設計優秀的源碼，測試是必不可少的組成部分，測試不僅可以驗證程序正確性，也是程序設計思想的體現。在編寫程序之前相應的測試用例就應編制完成，因為程序運行的各種可能出現的異常情況，在設計時就應被充分考慮，而編寫測試用例能夠很好的幫助程序員思考各種極端情況下程序的運行狀態，減少設計缺陷發生的概率[4]。

測試用例的編制依據應是軟件需求而非代碼本身和測試覆蓋度。無論代碼是否運行良好，違背需求設計的程序都是存在嚴重設計缺陷的。當然，測試的對象并不僅是代碼，軟件需求、數據庫設計、人機界面設計同樣需要測試。如軟件需求的測試就要對需求的完備性、無二異性、正確性、可實現性進行考察，該測試一般采用結對評審的方式經行，業務流程和狀態建模可作為測試的輔助手段。

軟件測試不是萬能的，它只能盡可能地發現代碼中存在的缺陷，但更多的時候還是需要程序員通過良好的編碼習慣來避免缺陷的發生，因為對于缺陷的修正往往會引入新的缺陷，尤其是在編碼風格不良的代碼上進行修改。

4 總結

本文從軟件架構、編碼、測試等環節分析了武器裝備研制中軟件編碼質量的重要性，并對如何提高軟件代碼質量提出了具體的、具有可操作性的建議與方法。使用合理的設計模式、遵循規范的編碼原則、借助覆蓋全周期的測試手段，可以大幅提升軟件代碼的質量，從而降低升級維護成本、控制潛在缺陷的發生率。

[1] 鄒德萍. 豐田召回事件的警示 [J]. 資源與人居環境. 2010 (07)76-78.

[2] 楊莉萍. 面向對象的方法和設計模式 [J]. 計算機應用與軟件. 2006 (03):36-38.

[3] robert c. Martin.clean code［M］.北京：電子工業出版社，2012.

[4] 蔣曉陽. 武器軟件的測試與維護[J]. 火力與指揮控制2005(30).200-201.

Research on Improving Coding Quality in Armament Software Development

Ge Xueshi, Chen Shuheng
(Naval Academy of Armament, Shanghai 200436, China)

The code-quality plays an important role in development of armament. In this paper, possible code-quality related problems in architect design, coding and testing are well analyzed. Then corresponding software development rules are proposed. And solid foundation ensuring better code-quality in future software development can be established by these rules.

Coding quality; Software architect; Software testing

TP393

A

1007-757X(2016)010-0059-02

2016.08.29）

作者信息：葛學仕（1987-），海軍裝備研究院，碩士研究生，研究方向：軟件工程，流媒體技術與應用，雷達與電子對抗技術，上海 200436

陳書恒（1984-），海軍裝備研究院，工程師，研究方向：航空電子總體，上海 200436