敏捷思想的流行使得很多人對可擴充套件設計產生了一種懷疑的態度。這有幾方面的原因，一方面是j2ee平台本身提供的分布式機制等技術因素很容易誘導你定義不 必要的擴充套件需求，第二是基於目前的技術手段對於程式結構的分解仍然有著很大限制，具體的程式實現中往往會引入某種強制依賴，削弱了潛在的可擴充套件性，第三則 是設計者本身對於技術和業務的把握不夠深入，在考慮設計的可擴充套件性時經常做出錯誤的判斷。但是乙個只滿足當前需求的系統一般不是個好系統，也很難在多次迭 代生命週期後繼續生存。xp(extreme programming)強調簡單化，其實質在於簡單的東西可以在未來被重構(refactor)，從而適應未知的變化，它本身並不排斥可擴充套件設計。
從基本的常識出發，我們都知道現在應該為將來做些事情，準備些資本。可擴充套件設計的價值觀不應是現在解決將來的問題，而是尋求未來發展之後現在的解是否仍然 部分有效，是否仍然可以部分被繼承。即我們考慮的不是將未來的解納入到現在的體系中，而是考慮現在的解在未來的體系中的位置。不是在現在如何支援我們所預 想到的幾種未來的擴充套件方式，而是無論未來如何變化，怎樣才能保證現在工作的有效性。這裡所關注的重點是現在而不是將來!面對演化我們所能採取的最好的策略 就是盡量有所積累，盡量不放棄我們的過去，而不是把寶押在對未來的準確**上。乙個厚重的設計往往在後期會因為預料的太多反而在遭遇未預料到的變化時不知 所措，結果造成系統整體架構的失效，必須做更多的工作打補丁來使得它勉強工作。象ejb這樣distribution ready的技術現在已經公認有過度設計之嫌，因為這些已經ready的特性一般並不會被應用但是我們卻不得不為這些無用的特性付出代價。
可擴充套件設計所依賴的基本原則之一是ioc(inversion of control)。ioc是目前輕量級容器(lightweight container)的核心設計思想，但其實它的應用遠不止在輕量級容器這一領域。基於ioc設計，大量的知識（依賴）被剝離出業務物件本身，物件對於其 生存環境和應用場景的假設大大減弱，而我們的期望正在於無論未來的應用環境如何變化，只要提供必要的知識，業務物件就能工作。可以說，ioc是可擴充套件性的 一種基本要求。
可擴充套件設計所依賴的另乙個原則是連續性(continuous), 這可比ioc要複雜和深刻的多了。如果說現代設計的核心觀念是演化(evolution), 那麼在我們的思想中演化到底有著什麼樣的圖景？ 至少需要乙個方向加上一條連續的途徑,evolution才能發生。在級列設計中，乙個簡單的系統架構需要能夠scale up，而乙個複雜層次上的系統架構也需要能夠以優雅的方式scale down。這種變化是自然的因為它們是連續的。
CSS可擴充套件性
今日在寫pc官網的時候，一直對於html css的結構編寫完全按照自己的思維方式，今天把 交給老大的時候，被他指出很多編寫 的錯誤性，比如 結構，標籤的使用，語義化，css的可擴充套件性，由於 主要還是需要做seo優化，所以在標籤使用上也有些不合理之處，給了我一些建議，自己記錄以下 1 在html標...
設計 C S協議 可擴充套件性
c s架構下，介面返回值定義需要考慮後續的可擴充套件性。這裡是指廣義的客戶端 服務端。原則上，對於協議的返回值，後續的變更只能新增欄位而不能發生結構性的變更 比如修改結構或刪除 否則就無法向前相容。如果非要變更，需要做好相容性處理。分兩種case 1.服務端相容，需要客戶端傳入版本號，服務端根據版本...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...