(精)多版本軟件構建策略分析

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

一、傳統軟件構建策略

不同的版本採用不同的代碼,通過派生或直接使用不同的代碼實現。每個版本都會對應到一份的這個版本相關的代碼。在代碼發佈成產品時,我們還需要一個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 基於配置的軟件構建策略

在基與配置的軟件構建策略中,工具的主要目標可以放在配置文件的管理與生成上。代碼由開發人員編寫,工具生成配置文件後經過測試就可以發佈。


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

四、加入動態語言

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


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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章