程序代碼可控性研究

邵改革

摘要摘要：程序代碼編寫不規范、缺乏可擴展性和可維護性，將導致代碼可控性較差，嚴重影響軟件產品的持久更新升級。從代碼質量控制角度出發，通過對程序代碼的可控性進行研究，提出代碼可控性評價標準，并給出改進措施。代碼的可控性有助于緩解程序擴展和修改壓力，形成代碼更新迭代的良性循環。

關鍵詞關鍵詞：程序可控性；代碼可量測；代碼質量評價

DOIDOI：10.11907/rjdk.162173

中圖分類號：TP319文獻標識碼：A文章編號文章編號：16727800（2017）001012402

引言

隨著用戶需求的不斷變化，軟件結構日益復雜，開發周期越來越短，如何按時交付高質量的產品成為軟件開發工作的一個難點。提高軟件質量和開發效率關乎軟件企業競爭力，也是每個信息化企業不懈追求的目標。軟件研發是一項系統性工程，包括需求分析、系統設計、系統實現、測試等環節[1]。針對研發過程，國內外專家學者結合具體實踐，從不同角度提出了提高軟件質量的方法和模型。雖然軟件開發具有諸多過程管理方法和經驗，如CMM（Capability Maturity Model for Software）、PMBOK（項目管理知識體系）、敏捷開發等，但目前軟件質量依然不容樂觀。軟件質量水平不高是由很多方面因素所致，其中最主要的原因之一在于程序代碼缺乏可控性。

以筆者所在單位的部分產品代碼為例，整個產品線包括較為完善的單元測試、集成測試、系統測試和性能測試，但對程序代碼層面的問題關注較少，沒有形成一套完整的代碼質量評價體系。代碼中仍然存在命名規范差、重復代碼、長方法、大類、長參數列表、濫用設計模式等問題，初期表現為程序代碼可讀性差。隨著軟件產品根據用戶需求不斷修改升級和不同版本累積，程序的可控性逐漸變差，代碼變得難以理解和修改，軟件產品版本維護越來越困難。

1代碼質量控制

軟件質量是指軟件產品滿足預定需求的程度。Boehm等[2]提出了軟件質量評價的概念，并使用定量公式用于評價軟件質量。McCall和Waters[3]提出了從軟件質量要素、準則到度量的三層次質量度量模型。ISO提出的質量度量模型由高層軟件質量需求評價準則、中層軟件質量評價設計準則和底層軟件質量度量評價準則3個層次組成。代碼質量評價指標一般包括正確性、規范性、可讀性、有效性、可擴展性、可重用性、可維護性、安全性等[4]。上述評價指標從不同層面對代碼進行了評估，但缺乏具體的評價標準和方法，代碼評價指標在實際操作中難以適用。比如可讀性指標，代碼“可讀性”與“不可讀性”的界限比較模糊，但具有良好可讀性的代碼一定具有注釋、規范的命名和適當的結構等特征[5]。命名規范有很多種，但良好的規范性代碼往往遵循統一的命名方法。

提高代碼質量是軟件企業增強競爭力的重要策略之一，更是以軟件產品為主導型信息企業長久發展的基石。但由于種種原因，程序代碼質量并未達到理想的目標，代碼質量不高的原因主要有：

（1）缺乏頂層設計理念。任何一種設計或架構方案，都需要一個良好的控制機制來實現，不能將設計與實現脫節。系統總體設計不僅僅是一個圖形或文檔，需要融入到程序結構和具體的代碼實現過程之中。

（2）缺乏中間代碼結構的設計過程。頂層設計需要中間代碼結構設計才能過渡到具體的代碼實現，該過程由設計方案變成軟件架構，是軟件開發比較重要的一次模式轉換。缺少此過程，將會導致頂層設計和實現代碼之間的割裂。

（3）開發人員水平參差不齊和代碼版本差異大。開發人員基礎較差、缺乏經驗加上對設計方案的理解程度不同，在對程序代碼的維護中往往加入“壞味”代碼較多。并且一個產品線有時需要維護不同的代碼版本，而不同版本在演化過程中相差會越來越大，代碼中存在大量的交叉和重復。

（4）代碼質量檢查環節薄弱。產品測試只注重單元測試、集成測試、系統測試和性能測試，忽略了代碼質量檢查。這些測試只保證了代碼的外在表現，未能體現代碼的內在質量。“壞味”代碼一旦進入版本庫，會產生一系列程序問題，增加軟件維護工作量。

上述問題的存在導致代碼的可控性越來越低，后期更新維護成本越來越高。程序代碼的可控性主要是指對于代碼需要修改和擴展的可量測性大小，它是代碼質量評價的主要指標之一，在以產品為主導的開發中格外重要。具有良好可控性代碼的程序可以有效應對變化，各環節之間的影響程度是可以界定的。它有助于合理調配資源，優化開發工作流程，減輕維護人員工作量，利于產品代碼的重構和版本演化。

2代碼可控性評價

（1）需求改變導致的代碼修改具有明確的范圍。用戶需求日益個性化、精細化，軟件領域用戶需求變化成為了一種客觀規律。一旦用戶需求發生變更，程序代碼就要作出相應調整。在這種變化常態下，如何減少需求改變帶來的代碼修改是程序面臨的難題。具有良好可控性的程序代碼，如遇需求更改，可快速定位代碼修改范圍，待修改的類和方法是明確的。這就要求程序開發中需要將業務流程與具體實現進行分離，代碼邏輯結構劃分清晰。業務流程是抽象的，如果將抽象的業務處理融合在大篇幅的代碼之中，一旦需求改變，整個代碼都要修改，無疑增大了工作量。封裝變化是可控性代碼的重要特征，在將需求轉變成設計方案的過程中，要分析出哪些是變化的，哪些是不變的，并對變化的部分進行封裝。在對需求和現有代碼全面掌握的基礎上，明確影響范圍，有效應對需求改變導致的代碼修改。

（2）擴展和修改的代碼內容可量測。具有良好可控性的代碼，遇用戶新增或改變需求，在確定修改范圍之后，可以預估出需擴展和修改的代碼量，即具有代碼的可量測性。程序代碼除具有較好的可擴展性和可維護性，還需要將這種可能性量化，至少評估出按照“堆砌原則”需要增加或修改的代碼量。這種可量測性是在第一步明確修改范圍的基礎上，繼續對代碼修改的內容作出評估，提出將代碼維護工作可度量化，并能夠預測可能發生的變化。代碼中應盡可能提高復用率，減少重復代碼，避免硬編碼。可控性要求將代碼之間的耦合性降到最低，拒絕大段瀑布流式的編程實現。程序中具有“原子性”功能的實現是可抽離的，不依賴于業務邏輯和其它“原子性”功能，且這種實現的代碼可以量化。可控性差的程序代碼必然針對修改或擴展的代碼量無法作出評估，不能給出具體的工作量，也不能實現對任務的合理分配，增加軟件開發項目的進度管控風險。

（3） 所有的代碼修改應在本層為止，否則就要變更設計。隨著軟件版本的演變，對代碼進行修改或調整是不可避免的。可控性程序由結構化的代碼構成，即代碼具有明顯的層次劃分。代碼最基礎的層次是類級別，最分明的層次是包（命名空間）級別。軟件系統角度上的層次劃分往往是多級別，并不局限于包或者類，層次劃分可以虛擬化。每個層次是具有獨立功能實現類的集合，各層次之間應存在較為清晰的界限。可控化更加注重總體設計與細節設計之間的模式轉換，強調設計先行的原則。軟件架構設計與模塊設計應充分考慮功能的集合特征，不同層次之間的接口調用應遵循簡潔高效的原則。程序細節設計或實現，可以參考現有設計模式，但不拘泥于設計模式，以方法產生的實際效果為主。設計要充分考慮層次劃分的邊界，無論自上而下還是自下而上，所有的修改應在本層內完成，避免跨層修改，減小代碼波及的范圍。如因需求改變，出現了多層代碼都需要修改，就要考慮原有設計是否合理，然后根據具體情況調整設計方案。

3改進措施

（1）注重頂層設計方案落地。頂層設計是在充分了解用戶需求的基礎上，結合目前產品現狀，給出的最佳解決方案，具有一定的前瞻性。開發核心人員應全程參與產品的設計階段，以確保對設計方案的理解無偏差。一方面加強設計方案的貫通，讓開發人員領會架構的意圖；另一方面加強對實現過程的管控，將方案落到實處。開發團隊應貫徹頂層設計的思想和解決方法，并將總體設計方案落實到代碼實現中。

（2）規范程序中間設計環節。從總體設計方案衍生出來的設計都可以稱為中間設計，如從總體設計到詳細設計。這涉及到一些模式轉換，是一個承上啟下的過程。中間設計需要總體設計方案人員和開發人員參與，并通過相關人員評審，確保中間設計環節不偏離頂層設計。

（3）提高開發人員技能水平。人才是企業的核心競爭力，代碼的問題歸根到底還是人的問題。通過技能培訓或交流，與產品開發相結合，提高開發人員基礎水平。經驗豐富的程序員要發揮帶動作用，促進其他開發人員不斷進步。如今技術革新周期不斷縮短，研發團隊中要形成學習的氛圍，勇于嘗試新技術、新方法。

（4）加強程序代碼質量檢查。代碼質量檢查應列為軟件產品測試的組成部分，其中代碼可控性是軟件產品質量檢查的重要參考指標。代碼質量初步檢查可以使用工具實現自動化或半自動化，如CheckStyle、PMD、FindBugs等[6]。代碼管理人員需要對代碼進行階段性質檢，降低代碼中的潛在風險，保證每個迭代階段提交到版本庫中的代碼質量。