架構如何才能抵制熵增

         首先我們來瞭解一下熵增定律，百度百科的描述是：

　　“孤立系統總是趨向於熵增，最終達到熵的最大狀態，也就是系統的最混亂無序狀態。但是，對開放系統而言，由於它可以將內部能量交換產生的熵增通過向環境釋放熱量的方式轉移，所以開放系統有可能趨向熵減而達到有序狀態。”

         “熵增的熱力學理論與幾率學理論結合，產生形而上的哲學指導意義：事物的混亂程度越高，則其幾率越大。”

         通俗點理解就是系統會隨著時間的推移變得越來越亂。

         具體到軟體系統，隨著時間的推移，無論是開發還是維護，都會增加系統的複雜度，越多的代碼進入，則越容易造成混亂，軟體架構也越容易被破壞。因此，軟體架構在設計時就要考慮如何抵制熵增的問題。

         總體而言，我認為可以從四個方面來減少熵增的產生。

         首先，自然是從架構設計本身出發。架構設計中，要充分考慮未來的可變性，將易變部分進行隔離。利用設計原則和架構方法，從軟體的整體上把握架構的演化方向，從而提前識別開發和維護對架構的影響。

         其次，架構必須要在團隊中取得一致的認識。尤其是技術團隊中，任何一名開發人員都應該充分理解軟體架構，明確自己的代碼在整體中的位置，與其他組件的關係和通訊渠道。無論採用何種開發模型，都不應該因此放棄架構在開發人員認知中的重要性。只有如此，組件開發人員才能在整體架構下進行局部設計，並且能保持架構風格的延續性。否則就易於出現局部結構不符合整體架構，從而引發系統走向混亂。

         再次，設計評審或程式碼檢閱也可以有效減少熵增的發生。設計評審是實現之前的預防，程式碼檢閱是實現中的品質保證，兩者都可以對架構的一致性起到保證作用，而且在具體的實現中可以反作用於架構的調整，是架構師、技術經理經常採用的管理方法。

         最後，就是主動調整架構。架構師不可能預測未來，當變化來臨時，要主動的調整架構以適應變化，而不是被動的遷就，靠代碼技巧來應對變化。那樣的話，就已經從架構上主動進行了熵增，是混亂之源。

         以上四個方面，雖然無法完全抵制熵增，但至少可以減少熵增，值得在架構設計和軟體開發中進行足夠的重視。

——歡迎轉載，請註明出處 http://blog.csdn.net/caowenbin ——