邵改革

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

關(guān)鍵詞關(guān)鍵詞：程序可控性；代碼可量測；代碼質(zhì)量評價

DOIDOI：10.11907/rjdk.162173

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

引言

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

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

1代碼質(zhì)量控制

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

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

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

（2）缺乏中間代碼結(jié)構(gòu)的設(shè)計過程。頂層設(shè)計需要中間代碼結(jié)構(gòu)設(shè)計才能過渡到具體的代碼實現(xiàn)，該過程由設(shè)計方案變成軟件架構(gòu)，是軟件開發(fā)比較重要的一次模式轉(zhuǎn)換。缺少此過程，將會導(dǎo)致頂層設(shè)計和實現(xiàn)代碼之間的割裂。

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

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

上述問題的存在導(dǎo)致代碼的可控性越來越低，后期更新維護成本越來越高。程序代碼的可控性主要是指對于代碼需要修改和擴展的可量測性大小，它是代碼質(zhì)量評價的主要指標(biāo)之一，在以產(chǎn)品為主導(dǎo)的開發(fā)中格外重要。具有良好可控性代碼的程序可以有效應(yīng)對變化，各環(huán)節(jié)之間的影響程度是可以界定的。它有助于合理調(diào)配資源，優(yōu)化開發(fā)工作流程，減輕維護人員工作量，利于產(chǎn)品代碼的重構(gòu)和版本演化。

2代碼可控性評價

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

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

（3） 所有的代碼修改應(yīng)在本層為止，否則就要變更設(shè)計。隨著軟件版本的演變，對代碼進行修改或調(diào)整是不可避免的?？煽匦猿绦蛴山Y(jié)構(gòu)化的代碼構(gòu)成，即代碼具有明顯的層次劃分。代碼最基礎(chǔ)的層次是類級別，最分明的層次是包（命名空間）級別。軟件系統(tǒng)角度上的層次劃分往往是多級別，并不局限于包或者類，層次劃分可以虛擬化。每個層次是具有獨立功能實現(xiàn)類的集合，各層次之間應(yīng)存在較為清晰的界限。可控化更加注重總體設(shè)計與細(xì)節(jié)設(shè)計之間的模式轉(zhuǎn)換，強調(diào)設(shè)計先行的原則。軟件架構(gòu)設(shè)計與模塊設(shè)計應(yīng)充分考慮功能的集合特征，不同層次之間的接口調(diào)用應(yīng)遵循簡潔高效的原則。程序細(xì)節(jié)設(shè)計或?qū)崿F(xiàn)，可以參考現(xiàn)有設(shè)計模式，但不拘泥于設(shè)計模式，以方法產(chǎn)生的實際效果為主。設(shè)計要充分考慮層次劃分的邊界，無論自上而下還是自下而上，所有的修改應(yīng)在本層內(nèi)完成，避免跨層修改，減小代碼波及的范圍。如因需求改變，出現(xiàn)了多層代碼都需要修改，就要考慮原有設(shè)計是否合理，然后根據(jù)具體情況調(diào)整設(shè)計方案。

3改進措施

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

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

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

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