《架構整潔之道》讀後感之一：元件設計變化的一個例子

在設計、劃分軟體元件時，需要平衡元件複用、元件釋出、元件維護更新等多方面因素，最終得結果是各個方面平衡得結果,并且随着項目的變化，需要進行演化。

在設計、劃分軟體元件時，需要平衡元件複用、元件釋出、元件維護更新等多方面因素，最終得結果是各個方面平衡得結果，可能從某一方面看并不完美。

在Bob大叔的《架構整潔之道》中給出了與建構元件相關的基本原則：

REP:複用/釋出等同原則

CCP:共同閉包原則

CRP:共同複用原則

在實際決策中，往往會發現很難同時遵守上面的原則，需要根據具體情況會有取舍；很多的情況是，在設計時隻是考慮到其中的某一個方面，或者随着項目的進展，情況發生了變化，需要修改當初的設計。這裡舉一個DNN（DotNetNuke）子產品的開發中，我遇到過的元件設計問題。

我從2004年開始從事DotNetNuke的子產品開發（ZLDNN.COM），開發的子產品在DNNStore(從前叫做Snowcovered.com)中進行銷售。其中，從2006年開始開發的DNNArticle是一個比較成功的産品，在開發後來的新子產品産品時，發現DNNArticle中的很多功能子產品是可以供這些新産品使用的，為了減少新産品開發的工作量，我把這些公共功能抽提出來，形成一個公共的類庫，在開發新産品時供自己和開發合作夥伴使用。最初，這樣做的效果很好，提高了新産品的開發效率，很多新子產品使用這個公共類庫，依賴這個公共類庫。這種依賴帶來的耦合性，埋下了問題的隐患。公共類庫被打包到産品子產品的安裝包中，在安裝時由DNN的安裝向導進行安裝，為了友善使用者，減少安裝步驟，每個産品子產品中都包括了公共類庫。随着時間的推移，一些新的功能增加到類庫中，類庫中原有的bug被修改，新的類庫随子產品的新版本釋出。我們考慮到了産品更新可能帶來的問題，比如使用者購買了DNNArticle和Advanced Business Directory, 這兩個子產品都使用了公共類庫，當DNNArticle更新時，公共類庫被更新了，Advanced Business Directory仍然可以正常工作。我們使子產品不依賴于公共類庫的具體版本，進而確定舊的子產品可以與新的類庫共同工作而不需要重新編譯。但我們沒有考慮到的是，使用新類庫的子產品不能與老的公共類庫一起工作，是以問題發生了，開始有使用者抱怨購買了兩個子產品，安裝完一個後，另一個子產品不能工作了，類似的抱怨越來越多。問題出在公共類庫上：一個子產品用到了新版本的類庫，另一個子產品使用的是老的類庫，使用者在安裝時，先安裝了新版本類庫的子產品，在安裝另一個子產品時，老的類庫覆寫了新的類庫，導緻了這個問題。這種問題出現時，類庫已經在很多産品中使用了，并且已經有相當多的版本釋出了，為了快速解決問題，采用了比較笨的辦法，舍棄複用性，将公共類庫的代碼轉移到各個産品中，這樣各個産品不會因為公共類庫産生耦合，也就不會在部署中産生問題。

是否有更好的辦法呢？有個辦法是将公共庫單獨打包，在部署時，單獨部署，如果已經有高版本存在，則不進行部署，這個辦法最好，但增加了使用者部署産品的步驟，使用者總是希望更少的部署步驟。對于隻購買一個産品的使用者來說，更是如此。從産品的競争力考慮，這個方案被否定了。 那麼采用公共庫的設計思路是不是完全不正确呢？應該也不是，在開始階段，公共庫的使用提高了新産品的開發速度，産生了新的銷售收入，問題的出現畢竟是一年多以後的事情。也可以這樣說，元件的劃分不是一成不變的，随着環境的變化，考慮的重點會發生變化，元件的設計也會變化。

用《架構整潔之道》第13章 元件聚合的小結作為結束： “在決定将哪些類歸為同一個元件時，必須要考慮到研發性與複用性之間的沖突，并根據應用程式的需要來平衡這兩個沖突，這是一件很不容易的事。而且，這種平衡本身也在不斷變化。也就是說，當下适用的分割方式可能明年就不再适用了。是以，元件的構成安排應随着項目重心的不同，以及研發性與複用性的不同而不斷演化。”

本文來自部落格園，作者：尋找無名的特質，轉載請注明原文連結：https://www.cnblogs.com/zhenl/p/10093598.html