多版本軟體構建策略分析

來源:互聯網
上載者:User

主要分析存在多個版本特性時的軟體構建策略。多個版本特性在有些情況下僅僅對應於軟體的本地化,複雜的情況就是不同版本中模組的商務邏輯、呈現策略都不相 同。這不僅在產品開發過程中增加成本,更多的成本將在維護階段體現出來。因此,選擇一個合適的構建策略對降低開發與維護成本都是非常重要的。

一、傳統軟體構建策略

不同的版本採用不同的代碼,通過派生或直接使用不同的代碼實現。每個版本都會對應到一份的這個版本相關的代碼。在代碼發布成產品時,我們還需要一個build過程,將源碼打包發布成可執行檔。

這裡體現多版本特性的代碼可能簡單可能複雜,關鍵要看軟體整體的設計對多版本的支援。

1.1 採用strategy模式實現

模組A能訪問到本地策略,根據不同版本的差異實現Local1、Local2來實現具體的使用者需求。

這裡存在幾個問題。
一、系統中的階層很複雜,如果模組E同樣也需要根據版本特性來確定自己的行為,這時可能有兩種方式:將ILocal層層傳遞,從A到C再到E;採用singleton模式。不過這兩種方式都破壞了對象的封裝性。
二、ILocal中的方法會非常多。系統中所有的版本差異都將放到ILocal的方法中,很快這些方法就會失去控制。那是否可以對特性分類處理呢,將某一類特性放到一個介面中可以降低ILocal的管理成本,但沒有從本質上解決問題。
三、Local實作類別會隨著項目的推進,或者在維護過程中變得臃腫。在項目過了幾年之後,這點就成為頑疾了。

1.2 使用編譯指令

編譯指令是一個非常輕便的方式。在很多著名的商業化產品中都會出現,尤其是在處理作業系統不同版本的時候。

使用編譯指令不會出現strategy模式中出現的問題,但是需要小心控制它的使用範圍。更加嚴重的一個問題是,版本非常多的時候(比如幾十個)編譯指令就成了可讀性的殺手。同時增加了build過程的成本與錯誤率。總之,選擇這種方式之前必須謹慎考慮。

二、基於配置的軟體構建策略

不同的版本採用同一份代碼 ,build後得到可執行檔檔案。但這裡得到的可執行檔並不是最終的發布產品。可執行檔加上配置資訊才能符合使用者的需求。這種情況下,開發人員不僅需要開發代碼,而且需要設計設定檔的格式(模組的可配置能力)。

基於配置的軟體構建同樣需要在整體設計上的考慮。並且有多種實現方式。

2.1 採用Local類

Local類讀取設定檔,將設定檔中的配置元素返回給程式模組。這種處理方式遇到的問題與採用strategy模式時非常類似。另外,採用Local類只能處理相對簡單的邏輯,例如控制介面顯示等。

2.2 基於外掛程式的實現方式

外掛程式是將代碼與配置分離的一種有效方式。與上面的Local類相比,外掛程式的機制將配置粒度更加細化。

可以將外掛程式系統的配置按照功能分為兩大類:結構化配置、差異化配置。

結構化配置指定外掛程式與外掛程式之間的關係,外掛程式之間相互協作。差異化配置體現單個外掛程式的可配置能力。系統分為多個“代碼+外掛程式”的可執行模組。

2.3 代碼與配置的權衡

在基於配置的軟體構建模型中,代碼和配置之間存在著一個分水嶺。如何劃分代碼配置的界限影響到所有模組的詳細設計。

配置的目的是什麼,我們想要達到什麼效果?在分析這些問題之前,先說明一下使用設定檔的兩個極端。

“配置必須配置的點”是設定檔的最低限度。判斷是否達到了這個最低標準的方式非常簡單,就是觀察系統中是否存在因多版本特性而引起的多份代碼。
“配置能配置的所有點”是另外一個極端,達到的最終效果就是完成了一個配置語言啟動並執行環境。

居於左側的模組複用度低,但設定檔簡單,易於維護。居於右側的模組複用度高,設定檔複雜。具體的項目需要在這兩個極端之間找到一個平衡點。

2.4 設計的一致性

一、怎樣找到代碼與配置之間的平衡點,最好的情況是由架構師定下一個判斷原則,指導設計人員進行詳細設計。這對於維持產品的設計一致性非常關鍵。

二、在配置度高的情況下,不同的模組定義了特有的設定檔規則。這些規則的統一對保證一致性也是一個挑戰。

三、加入工具支援

好的工具可以提高生產效率,降低重複性勞動的成本。

3.1 傳統軟體構建策略

在基與多版本的代碼開發時,工具能做的是代碼產生工作。包括架構代碼以及簡單的控制碼。更多的情況下仍然需要手工修改源碼檔案。

關於代碼產生技術,在.Net架構中提供了一系列的類來完成(System.CodeDom namespace等),可以參考相關資料。這種技術自己實現比較簡單的情況也並不複雜。

3.2 基於配置的軟體構建策略

在基與配置的軟體構建策略中,工具的主要目標可以放在設定檔的管理與產生上。代碼由開發人員編寫,工具組建組態檔案後經過測試就發行就緒。

這裡代碼與配置的分界線會影響到工具的複雜度。需要協調代碼編寫、設定檔管理、工具編寫這幾方面的成本與收益。

四、加入動態語言

將動態語言技術加到系統中,代碼與配置的界限就變得模糊了。使用動態語言作為設定檔的形式可以充分利用它的語言特性提高配置能力,省去了自己設計配置格式與解析配置的過程。

上面說模組自訂的配置規則多的情況下,將破壞系統設計的一致性。如果採用某種動態語言,那麼這種規則實際上就是這種語言的文法,有助於開發人員理解各個模組。但這時候的產生工具複雜度就增加了,本質上已經成為動態語言的代碼產生器。

 

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.