canonical

   單元測試隨著agile的流行已經家喻戶曉了，這正反映了軟件的一個本質特征：軟件是Man-Made的，而人是不可靠的。軟件出錯的高頻率必然導致控制 間隔的縮短。我最早是在編寫matlab程序的時候獨立的發(fā)現(xiàn)了單元測試的作用。因為matlab是弱類型的，橫縱矢量也不區(qū)分，很容易犯錯誤，我就為每 一個matlab函數(shù)編寫了測試腳本，約定了命名規(guī)范為xxx_test.m, 在測試的時候通過 can_assert來做出判斷而不是輸出變量內容進行人工檢查。 每次作了修改的時候，運行一下can_test_all.m就自動搜索測試腳本并運行一遍。 后來xp出現(xiàn)了， 我也第一次聽說了單元測試這回事，看來英雄所見略同吧 ^_^
   單元測試可以看作是對編譯器的補充。編譯器只能進行語法檢查（形式），而單元測試可以進行語義檢查(內容），它其實維護了程序的一個語義框架。如果單元測 試程序編寫出來了，即使一行業(yè)務實現(xiàn)代碼也沒編寫，我們手中也已經擁有了一筆寶貴的財富，因為程序的語義已經在某種意義下確定下來了。重構一般是在維護單 元測試不變的情況下進行的。即我們發(fā)現(xiàn)在維護語義不變量的情況下，系統(tǒng)具有相當?shù)恼{整余地。
   堅持單元測試的另一個好處是它傾向于良好分離的模塊，因為高內聚低耦合的模塊才更容易進行測試。為了測試，我們會在不知不覺中在對象職責的分離上投注更多 的心力。在witrix平臺中，雖然基于EasyMock提供了mock支持，在實際中卻很少使用，因為模塊功能一般很獨立，不需要復雜的mock對象， 而對于一般的對象，eclipse有代碼生成功能，可以非常輕易的生成簡單的測試對象。
   雖然JUnit非常流行，我們的單元測試也是基于JUnit進行的，但是我們還是進行了一個簡單的封裝，將JUnit框架的特定要求與具體測試代碼剝離開來。具體的，測試類從
   test.UnitTest繼承，而不是從JUnit的TestCase繼承。使用Debug.check()來做判斷，而不是JUnit的assertEquals等。
   class MyTest extends UnitTest{
      public MyTest(String caseName){ super(caseName); }

      public void testMy(){
          MyObject my = new MyObject();
          Object value = myObject.myFunc();
          Debug.check(value.equals("aa"));
          // 可以同時提供一個出錯消息
          Debug.check(value.equals("aa"),"myFunc return invalid : "+value);
      }

      public static void main(String[] args){
        // 不需要IDE或者其他外部的支持就可以直接調用測試代碼，將會自動輸出運行時間等
        UnitTest.exec(new MyTest("testMy"));
      }
   }

   關系數(shù)據(jù)庫提供的是集合存儲模型， query(fields, condition) ==> list of records, 可以從條件集合映射到記錄集合。
當condition退化為單一的key, 而fields采用默認值的時候，我們就退化到Map語義, 從key對象映射到value對象，而不是從集合映射到集合。
很 多時候我們只需要這種簡單Map語義的存儲模型，例如用戶偏好設置的存儲。在這種受限的模型下我們也可以更直接的實現(xiàn)cache支持。如果我們希望在 Map的基礎上稍微擴展一些集合操作的特性，可以通過key的結構擴展來實現(xiàn)。即規(guī)定key采用類似url格式的字符串，實現(xiàn)key空間的樹形結構。在 witrix平臺中，這種樹形結構的映射關系通過IVarValueSet接口來實現(xiàn)。
　interface IVarValueSet{
     IVariant getVar(String name);

     // 得到前綴為prefix的所有變量構成的子集合，注意這里自然退化的特點
     IVarValueSet getSubSet(String prefix);
  }
變量名的格式規(guī)定為　a.b.c 或者/a/b/c. 這種變量結構的組織和劃分方式其實與JBoss項目中的TreeCache結構類似。

    級列設計理論中我們談到一般和特殊的關系, 但這是否指的是“相對抽象” 以及 “相對具體”之間的關系, 而“一般”到“特殊”和“特殊”到“一般”這兩個方向是否指的是具化過程和抽象泛化過程? 我猜測有這種想法的人大概是受到軟件設計中所謂抽象封裝思想的影響. 很顯然, 我并不是這樣認為的. 一般性(普遍性)與抽象性是不同的概念. 在物理學中相對論是比Newton力學更加一般性的理論，但它和Newton力學一樣都是關于我們這個世界的真實的理論，都是非常具體的。雖然我們有的時 候會說相對論更加抽象一些，這不過是暗示這個理論所描述的情形與我們的日常經驗距離遙遠而已,并不意味著它是某種只存在于概念空間的東西。實際上我很少談 到抽象與泛化過程，這對于物理學而言并不是一個合適的命題.

    有些人認為"service層, data object層,  dao層只是對程序職責的描述并不是實現(xiàn)，在實現(xiàn)中應該根據(jù)實際情況進行合并與取舍"。在我看來, 持有這種看法的人已經把自己的思想限定在了某一個復雜性層次上, 認為這些職責是天然的,必然的存在于程序中的. 但實際上, 我們肯定可以想見更加復雜的情形, 僅僅三層并不足以充分表達程序的結構, 而另一方面, 在極端簡單的情形下, 例如只有一個數(shù)據(jù)庫,只有CRUD操作, 此時根本就不存在這種職責. 一種所謂的職責從來就不曾存在過，我們自然也不應先把東西搞復雜起來，再合并取舍回去。

    級列理論是分析學中常見的一個思維框架，我只是把它從我最熟悉的物理學中借用到軟件設計領域而已， 它本身并不是我所創(chuàng)造的一種概念（創(chuàng)造是艱難的）。在某些領域，這一分析框架可以表現(xiàn)出完美的數(shù)學特性，如時頻分析領域的小波分析(wavelet), 統(tǒng)計學習理論中的支持向量機(Support Vector Machine), 分子動力學中的BBGKY級列等等。在其他一些領域它的精確性可能要弱很多，但其思想內核是一致的.
    
    級列理論的基本內容如下:
    http://canonical.blogdriver.com/canonical/562888.html

    首先, 級列理論需要定義一個最一般的普遍模型, 但這并不意味著對系統(tǒng)的一種過分的限制. 實際上, 我們所討論的任何問題都有一個總體的框架限制,  它的作用只在于揭示出我們所研究的問題的基本要素并勾勒出一幅全景式的圖像. 最一般的情況與我們的求解能力的距離可以是非常遙遠的，例如真正實作的時候在物理中往往我們只是研究一階或者二階情況。而在計算機領域也是存在著最一般的 模型的, 那就是Turing Machine. 在一般情況下, 我們是能夠建立一個足夠普遍的模型以囊括絕大多數(shù)變化可能的, 雖然我們極有可能沒有能力去求解這個模型.
    對于系統(tǒng)的完備性, 物理學與數(shù)學的態(tài)度是有著深刻區(qū)別的. 在物理學中我們只需要在研究問題的范疇內維持概念的穩(wěn)定性即可, 這往往意味很多簡化與隱含條件,并不是一種終極的完備性. 而在另一方面, 數(shù)學的完備性并不能保證它描述現(xiàn)實世界的完備性. 最明顯的, 從經典力學到狹義相對論, 再到廣義相對論, 在每一個層次上都是存在著非常完美的數(shù)學描述的, 其數(shù)學空間都是完備的, 但是很顯然, 即使是廣義相對論, 它也不是對于物理世界的完備描述. 目前物理學界仍然在量子引力的黑暗中摸索. 所有這一切都不影響我們在建筑工程中以足夠高的精度應用力學原理.

    級列理論所描述的絕不是一種從一般到特殊的思想的應用, 而是同時包含著從一般到特殊和從特殊到一般兩個方向. 在級列理論中, 我們首先研究的一般是最特殊的情況, 即最簡單, 對稱性最高的情況. 此時模型中特征元素個數(shù)很少, 而且界限分明, 很少交互或者發(fā)生關聯(lián). 我們得到簡單模型的解之后, 就可以將其作為初始解去求解更高階的模型. 這是從特殊到一般的一種進展. 而在另一方面, 我們可能以創(chuàng)造性的方式得到某個更高階模型的解, 此時我們需要研究高階模型與較低階模型之間的關聯(lián), 考察當更高階的模型退化到低階模型的時候, 它們的解是如何自然的實現(xiàn)退化的.  雖然迭代這個名詞在當前軟件工程領域如日中天, 但我想很多開發(fā)人員卻從未花上一刻時間去真正的體味這個概念本身的內涵, 而陷入了人云亦云的窘境. 從數(shù)學上說, 迭代過程的基本問題是收斂問題, 而且往往收斂過程中的控制策略要遠比迭代初始值的選擇更重要. 那么什么樣的控制策略才是保持探索性但又傾向于收斂的呢? 連續(xù)性是最基本的要求. 參見 反問題的級列求解 http://canonical.blogdriver.com/canonical/974280.html.

    級列理論最關鍵的部分其實是兩個存在性: 一是復雜性級列的客觀存在, 二是級列之間連續(xù)性的客觀存在. 注意到級列理論所描述的只是存在性，在一般情況下， 我們并不能直接得到從低階解推導出高階解的構造方法。而復雜性的級列的存在意味著總存在超越我們當前認知范圍的信息， 從低復雜性層次上升到高復雜性層次可能是需要非凡的創(chuàng)造力的， 決不是顯然的。此時我們唯一的選擇只能是從后驗的角度去檢驗這種存在性。模型的可退化性正是連續(xù)性的一種自然推論。這在物理學中是一件不言而喻的事情也是 一種強制性的要求：狹義相對論可以在低速情況下退化為Newton力學，而廣義相對論可以在引力均勻的情況下退化為狹義相對論。在軟件領域， 似乎只是到了近幾年， 可退化性才得到了一些重視，至今很多人對它的思想實質仍然沒有充分的了解。退化是否是指系統(tǒng)中不同職責部分的合并但是這些職責依然存在? NO, NO, NO. 精簡機構的原因難道是為了裁減人手,增大人均工作量嗎? 精簡的原因首先在于人浮于事, 本身就沒有那么多的職責, 卻要生造出那么多的處理步驟來. 我們或者合并部門，或者干脆撤銷部門，一些專門因為內部協(xié)調而生的部分更是要被毫不留情的裁減掉。在常見的軟件開發(fā)中, 明明是非常簡單的數(shù)據(jù)庫訪問操作, 偏偏要在service層, data object層, dao層都把同樣的接口代碼重復一遍, 美其名曰多層體系架構, 可以保持系統(tǒng)的靈活性. 可是誰需要這種靈活性, 它到底是設計的靈活性還是設計的脆弱性? 在簡單的情況下, 選擇meta driven的方案,從描述文件直接驅動多個層次的運作往往能夠極大的提高系統(tǒng)的穩(wěn)定性和靈活性.

    假設現(xiàn)在有一個網絡應用, 我們首先考慮最簡單的情況, 例如我們假設只存在一種通信協(xié)議:打電話. 我們可以通過電話通知另一方的接線員, 讓他把信息記錄下來再錄入系統(tǒng)當中,以此維持系統(tǒng)的運轉. 如果永遠都只有一個固定的接線員X通過唯一的一部電話M來完成通信過程, 則系統(tǒng)中的多個概念就會發(fā)生簡并: 通信將等價于打電話,等價于打電話給X, 等價于使用電話機M打電話給接線員X. 隨著系統(tǒng)的復雜性逐漸增大, 系統(tǒng)的對稱性出現(xiàn)破缺, 原本被認為同一的概念出現(xiàn)了微妙的不同, 并可能演變成差異巨大的兩個分支. 假設現(xiàn)在多了另外一種通信協(xié)議:硬盤交換. 我們可以把數(shù)據(jù)拷貝到一塊硬盤上, 然后攜帶到遠處的機房, 在那里把數(shù)據(jù)導入系統(tǒng), 以維持系統(tǒng)的運轉. 如果我們的系統(tǒng)演化到了這個階段是否意味著我們原先的軟件模型已經徹底崩潰了? 并不是如此的, 在一個宏觀的粒度上, 我們的系統(tǒng)所需要的可能只是一種端到端的通信手段, 只是現(xiàn)在通信這一更高層的抽象概念不再等同于更加細節(jié)化的具體通信手段(打電話)了. 如果原先系統(tǒng)設計中的各個主要模塊之間只存在高層抽象之間的依賴, 則只需要增加一些數(shù)據(jù)導入導出模塊, 我們的系統(tǒng)就可以平滑(連續(xù))的接納一種新的通信協(xié)議. 一種宏觀的高層視圖如果直接映射到某種實現(xiàn), 則它所對應的就是一種最簡單的系統(tǒng)模型. 系統(tǒng)的不斷發(fā)展相當于是給這個最簡單的模型不斷補充細節(jié), 使它不斷的復雜化. 這種變化是有脈絡可尋的, 很多時候是局部的, 輕微的. 當然, 持續(xù)累積下去, 也許有一天我們會突然發(fā)現(xiàn)系統(tǒng)已經面目全非了, 甚至原先的高層視圖(簡單模型)也無法維持了. 但是即使這樣, 是否意味著我們原先的設計失敗了呢? 答案仍然是否定的. 軟件系統(tǒng)如同其他系統(tǒng)一樣, 處在不斷的演化狀態(tài)當中, 但是什么叫做系統(tǒng)的演化? 很多人有一種錯覺, 以為軟件結構完全不變, 完全不需要源代碼級別的修改, 只需要通過外部配置導入擴展對象的設計才是好設計, 才是成功的可擴展設計. 這是以一種靜態(tài)的僵化態(tài)度來看待程序的演化, 沒有理解演化的實質.  演化(evolution)首先是一種變化(variation). 按照級列設計理論, 當系統(tǒng)沿著復雜性的級列發(fā)生演化的時候, 因為不同復雜性層次之間存在著本質性差異, 我們不能奢望現(xiàn)在的簡單設計能夠一直包容越來越復雜的模型, 更加現(xiàn)實的態(tài)度是能否在未來的復雜的模型中為現(xiàn)在的簡單設計找到位置. 我們不預言未來, 也無法保證我們現(xiàn)在的行為能夠容納將來的選擇. 在適度重構的意義下實現(xiàn)部分重用已經是我們能夠做到的最好程度了. 我們需要理解世界本身是在變遷的, 即使現(xiàn)在我們能夠預測到未來, 現(xiàn)在就為其作準備也未必是適當?shù)? 因為現(xiàn)在的最優(yōu)不等價于將來的最優(yōu), 同樣將來的最優(yōu)也不等價于現(xiàn)在的最優(yōu).     在上文中的網絡應用的例子中, 也許系統(tǒng)最終發(fā)展成為一個非常龐大的系統(tǒng), 而我們最初設計的功能成為了該系統(tǒng)的一個子模塊, 這不是完美的可擴展性嗎?   http://canonical.blogdriver.com/canonical/1002861.html


    級列理論的思想是非常通俗的, 并沒有絲毫神秘的地方. 復雜性的級列可以在空間中呈現(xiàn)出一種復雜性遞增的形態(tài)，也可以沿著時間軸展開，構成發(fā)展的形態(tài)。在傳統(tǒng)設計理論中也在頻繁的處理著這些問題, 因而可以看到很多相近的思想, 但是我們也需要注意到一些細節(jié)性的不同.  傳統(tǒng)的設計中也講層次，但是多半說的是stratify而不是hierachical，是同一時刻可以看到的一種層次堆壘關系，而不是在不同復雜性層次上 才揭示出的級列關系. 傳統(tǒng)設計中也講高級抽象與低級抽象之間的關系，但沒有提供級列理論中完整的視圖, 也很少強調每個層次上元素之間的連續(xù)性。

    關于級列設計理論在軟件設計中的適用性, 我只想提一下witrix平臺中的jsplet開發(fā)框架,  參見
       從級列理論看MVC架構 http://canonical.blogdriver.com/canonical/579747.html
       jsplet:對Model 2模式的批判 http://canonical.blogdriver.com/canonical/591479.html
    在2002年左右, 我是先得到級列設計理論, 然后才根據(jù)其思想設計的jsplet框架. 在整個witrix平臺的設計中, 級列設計理論也是重要的指導思想. 不過, 以我的經驗來看, 一般人是很難理解他人的思想的, 即使是對別人的想法有些興趣, 實際思考的東西與作者的原意往往也有著很大的差異.  http://canonical.blogdriver.com/canonical/1014773.html
    
    最后我還是強調一下一件最最基本的事情, 一件每個人都應該時刻牢記的事情: 不要孤立的看待問題, 而是尋求一種概念之間的連續(xù)性.  http://canonical.blogdriver.com/canonical/1016684.html

    近代數(shù)學和物理學的發(fā)端是從微積分的發(fā)現(xiàn)開始的，人類第一次系統(tǒng)化的將連續(xù)性的思想推向了極限，也開創(chuàng)了嶄新的思維方式。記得高中自學微積分的時候我也花 了很多時間去思考連續(xù)性的問題，但是后來漸漸習以為常了。研究生的時候重新開始考慮連續(xù)性的問題，只是關注的方向是概念體系中的連續(xù)性。
    all or nothing是我們的思維中經常出現(xiàn)的一個誤區(qū)。很多時候我們的討論局域在一個封閉的既定的體系中，最后的結論也是在原地轉圈圈。就像是“人性本善”與 "人性本惡"的爭論一樣，數(shù)千年無所結論。也許我們真正的問題應該是豬有善惡嗎，猩猩有善惡嗎，何謂小善，何謂大惡？
    有些時候，某些簡單的概念被其復雜的外表所遮蔽。例如提起網格(grid), 很多人的第一印象大概是高深，是一個宏大的體系架構。但是我說如果現(xiàn)在只允許你寫下1000行代碼，你打算為網格寫些什么。我們在網格出現(xiàn)之前所作的工作 與網格之間有什么關系，將所有的概念逐個從網格這個體系中剝離出去之后，最后會剩下些什么。
    我們需要對概念有一個連續(xù)性的理解，而不是將它們作為一個不可破的黑箱來看待。這是分析學的基本態(tài)度。

    敏捷思想的流行使得很多人對可擴展設計產生了一種懷疑的態(tài)度。這有幾方面的原因，一方面是J2EE平臺本身提供的分布式機制等技術因素很容易誘導你定義不 必要的擴展需求，第二是基于目前的技術手段對于程序結構的分解仍然有著很大限制，具體的程序實現(xiàn)中往往會引入某種強制依賴，削弱了潛在的可擴展性，第三則 是設計者本身對于技術和業(yè)務的把握不夠深入，在考慮設計的可擴展性時經常做出錯誤的判斷。但是一個只滿足當前需求的系統(tǒng)一般不是個好系統(tǒng)，也很難在多次迭 代生命周期后繼續(xù)生存。XP(extreme programming)強調簡單化，其實質在于簡單的東西可以在未來被重構(refactor)，從而適應未知的變化，它本身并不排斥可擴展設計。
    從基本的常識出發(fā)，我們都知道現(xiàn)在應該為將來做些事情，準備些資本。可擴展設計的價值觀不應是現(xiàn)在解決將來的問題，而是尋求未來發(fā)展之后現(xiàn)在的解是否仍然 部分有效，是否仍然可以部分被繼承。即我們考慮的不是將未來的解納入到現(xiàn)在的體系中，而是考慮現(xiàn)在的解在未來的體系中的位置。不是在現(xiàn)在如何支持我們所預 想到的幾種未來的擴展方式，而是無論未來如何變化，怎樣才能保證現(xiàn)在工作的有效性。這里所關注的重點是現(xiàn)在而不是將來!面對演化我們所能采取的最好的策略 就是盡量有所積累，盡量不放棄我們的過去，而不是把寶押在對未來的準確預測上。一個厚重的設計往往在后期會因為預料的太多反而在遭遇未預料到的變化時不知 所措，結果造成系統(tǒng)整體架構的失效，必須做更多的工作打補丁來使得它勉強工作。象EJB這樣distribution ready的技術現(xiàn)在已經公認有過度設計之嫌，因為這些已經ready的特性一般并不會被應用但是我們卻不得不為這些無用的特性付出代價。
    
    可擴展設計所依賴的基本原則之一是IoC(Inversion of Control)。IoC是目前輕量級容器(lightweight container)的核心設計思想，但其實它的應用遠不止在輕量級容器這一領域。基于IoC設計，大量的知識（依賴）被剝離出業(yè)務對象本身，對象對于其 生存環(huán)境和應用場景的假設大大減弱，而我們的期望正在于無論未來的應用環(huán)境如何變化，只要提供必要的知識，業(yè)務對象就能工作。可以說，IoC是可擴展性的 一種基本要求。
   
    可擴展設計所依賴的另一個原則是連續(xù)性(continuous), 這可比IoC要復雜和深刻的多了。如果說現(xiàn)代設計的核心觀念是演化(evolution), 那么在我們的思想中演化到底有著什么樣的圖景？ 至少需要一個方向加上一條連續(xù)的途徑,evolution才能發(fā)生。在級列設計中，一個簡單的系統(tǒng)架構需要能夠scale up，而一個復雜層次上的系統(tǒng)架構也需要能夠以優(yōu)雅的方式scale down。這種變化是自然的因為它們是連續(xù)的。

    實際觀測到的結果是系統(tǒng)內在結構的外在表現(xiàn)，而軟件開發(fā)是從需求分析開始，經歷系統(tǒng)分析，設計并實現(xiàn)的過程，即從用戶需求逆推出軟件的結構。這種根據(jù)外在 表現(xiàn)求解內部結構的模型的過程，在數(shù)學上稱為反問題(inverse problem)。關于反問題，一個眾所周知的難點在于解的不適定性。因為不同的結構可以有類似的外在表現(xiàn)，因而反問題的解是不穩(wěn)定的。在一個既定的情況 下，我們按照某種粗略的外在度量標準，從反問題的眾多近似解中選擇了一個。但是當所需的外在表現(xiàn)發(fā)生微小變化后，我們第一次選擇出來的結構可能無法適應這 一微擾，而我們再次求解出來的結構可能與原先的結構有著巨大的差別。因而原先選擇的解在結構上是不穩(wěn)定的。在數(shù)學上，我們稱之為奇異解（singular solution)。在數(shù)學上，在求解反問題的時候為了避免選擇到奇異解，經常采用的技術手段就是類似于級列理論的所謂鎮(zhèn)定方法。即我們提出一系列的模 型，對它們進行一維參數(shù)化。當參數(shù)較大時相當于對原有模型的一種近似，原有模型的細節(jié)被淹沒在正定泛函的大范圍結構中，整體呈現(xiàn)出一種簡單的結構，而當參 數(shù)越來越小時，原有模型的細節(jié)被逐漸識別出來，整體模型逐漸復雜化，最終參數(shù)為0時恢復到原始情況。常見的模擬退火算法（simulated annealing)就屬于這一策略族。通過模型的連續(xù)性，我們建立了一個復雜模型與一個簡單模型（因而物理意義明確）之間的一條連續(xù)的紐帶，沿著這條可 退化的途徑，我們才有可能回避奇異解，保證復雜模型的物理有效性。
    在軟件設計中，我所提出的級列設計思想正是這樣一種漸進演化的設計思想。我們極力維護模型的可退化性，保證復雜的模型不至于鎖定在錯誤的角落中。而基于模型的連續(xù)性，我們對于未來的發(fā)展進行外推才有了一定的根據(jù)。

    架構的可退化性(degragation)指的是架構的結構可以從元素比較豐富,層次比較多,比較復雜的情況退化到比較簡單的情況, 而架構的無侵入性(non-invasive)指的是架構對于外部接入對象沒有特殊的形式要求, 一般通過依賴注入(dependency injection)向接入的外部對象推送信息. 這兩個概念之間存在著緊密的關聯(lián), 但并不等同. 無侵入性可以看作是架構的一種局部可退化性, 例如一個業(yè)務對象在正常工作的時候需要是完整的EJB對象形態(tài), 而在編寫的時候退化到普通的java對象(POJO). 架構的可退化性是一個比無侵入性更加廣泛的概念:一個架構對外可以是無侵入性的, 但是它的實現(xiàn)本身可能相當復雜, 是不能退化的. 例如在一般的web表現(xiàn)層設計中, 很多人都試圖提供一個RPC層, 將Web請求解析后映射為對java對象方法的調用. 通過一系列的描述文件, java對象本身可以完全不知道web層的存在, 因而這種設計在某種程度上可以看作是無侵入性的. 但是假如現(xiàn)在出現(xiàn)了性能問題,或者RPC層本身出現(xiàn)一些bug, 或者我們需要一些RPC層很難有效實現(xiàn)的映射規(guī)則, web層設計應該允許我們越過RPC層, 很方便的直接處理request和response, 這意味著在我們的架構設計中需要把邊界劃在web接口上(需要在這里定義基本的交互規(guī)范),而不僅僅是對象接口上.如果一個架構設計強制規(guī)定了一個不可越 過的RPC層, 則意味著該架構在這一點上是不可退化的.

    架構的可退化性是級列設計理論的一個自然推論, 它是對架構整體的要求, 需要同時考慮到架構本身實現(xiàn)的復雜性以及與外部接口的復雜性, 而不是僅僅考慮到對外部接入對象的復雜性的要求. 整個架構需要能夠沿著復雜性級列scale down, 而不僅僅是scale up!

    系統(tǒng)架構通俗的說起來就是系統(tǒng)的結構組織方式.原則上說, 架構只有好壞之分,而不存在有無的問題. 軟件的體系架構可以直接體現(xiàn)為代碼的類結構, 也可以表現(xiàn)為文檔性的編碼規(guī)范和全局約定等. 如果軟件架構中能夠抽象出一些穩(wěn)定的元素, 那我們就可能得到一些所謂的框架代碼. 一般業(yè)務架構是很難重用的, 目前常見的框架代碼所描述的多半是與業(yè)務無關的技術架構.
    
    良好的系統(tǒng)架構應該體現(xiàn)出應用本身的結構要求. 所謂各個為自己, 架構為大家. 只要各個局部符合規(guī)格, 應該由架構負責在合適的時刻按照合適的方式把它們組裝在一些. 一個良好的架構中, 應該很少出現(xiàn)結構性的if語句, 不需要應用代碼自己通過動態(tài)判斷來定義某個特殊的觸發(fā)時刻. 架構是一種規(guī)范, 當然也就是一種局限. 架構的可退化性是非常重要的, 否則一旦出現(xiàn)抽象泄露, 需要超出原有架構設計做出編碼補充的時候, 往往無法將代碼自然的融入原有的框架結構, 則整個框架出現(xiàn)大面積的失效情況. 而有的時候更糟糕的情況是一些關鍵性的資源處在原有技術架構的私有控制之中, 我們?yōu)榱丝朔軜嬒拗撇坏貌徊捎酶鞣Ntrick來hack原有框架, 造成錯誤的累加和傳播, 而補丁的補丁是最難維護的.

    架構問題并不是一成不變的. 在一些情形下無關緊要的問題在另一種情形下可能會成為災難性的架構問題. 例如在多層B/S架構下, 如果現(xiàn)在要求為每一個表增加一個對應的歷史表, 并對其進行查看和維護操作. 為了最大限度的重用代碼, 這要求我們的多層結構中的每一層都能夠參數(shù)化, 這樣我們才能用同樣的代碼處理不同的數(shù)據(jù)表. 如果我們的money很足, 小弟夠多, 有足夠的人月砸上去, 那么我們完全可以把業(yè)務表和歷史表分開處理, 但如果反之,我們就會遇到一個典型的架構問題.

    架構師未必有自己的框架, 因為設計不等價于創(chuàng)造, 架構師只要知道如何把系統(tǒng)中的各種元素按照可行的方式組裝在一起就可以了. 但是一個架構設計是非常依賴于我們所能采用的技術手段的, 當現(xiàn)有各種可用的技術元素都無法滿足我們的需求的時候, 某些架構師可能會選擇創(chuàng)造一種技術元素. 當然, 創(chuàng)造是艱難的, 它所要求的甚至是不同的技能. Sun的Green項目創(chuàng)造了java語言, 從而開啟了一個偉大的時代, 這絕對不會是大多數(shù)架構設計師的選擇(有趣的是,Green項目本身失敗了). EJB現(xiàn)在還有多少人在真正使用, 想想當年多少架構師在吹噓這些東西. 他們對于技術的把握真的就那么幼稚嗎? 架構設計并不是憑空出現(xiàn)的, 當時可選的東西就是如此, 而spring和hibernate這些都不屬于架構設計本身的內容.它們是一種創(chuàng)造.
    
    架構師未必是團隊的領導者. 確實,他的工作類似于編劇, 負責執(zhí)行的一般是導演. 事實上,一個建筑設計師是極少直接領導一個工程隊的.架構師也未必比高級程序員要高明, 他們負責的是不同的內容. 至于產品的"商標及商標的相關元素"和"技術市場架構"等也不屬于架構師的工作范疇, 他不能去搶產品經理的飯碗. 當然,在國內的現(xiàn)實情況下, 很多所謂的架構師所做的最重要的工作可能是公關工作, 向客戶秀出所謂的理念, 與實際開發(fā)是不搭嘎的.     
    
    理論上說, 架構師可以不是編程的強者, 也可以不決定一些具體數(shù)據(jù)結構的選擇, 但他不能不了解各種技術抉擇潛在的影響. 這就如同一個建筑設計師可以不精通工程力學,但是他不能愚蠢到藐視重力, 設計出倒三角式的大廈. 與建筑不同的是, 在軟件中我們所面臨的不是一種"凝固的藝術", 我們無法以完全靜態(tài)的方式理解代碼,而必須在頭腦中把它們運行起來. 架構師應該寫下一些實際的代碼, 以檢驗各個接口的可配合性并獲得對于代碼結構的直接感覺. 實際上, 按照現(xiàn)在軟件業(yè)的成熟度, 一般我們無法實現(xiàn)建筑中建筑設計師與土木工程師的分工, 很多時候軟件架構師都需要直接面對實現(xiàn)的細節(jié). 如果組內缺乏非常強悍的coder, 有編程能力的架構師親自操刀實現(xiàn)關鍵性代碼的時候也是很多的.

    架構師必須有經驗, 但他所依賴的不能只是經驗. 只要算一算架構師的年紀, 就會知道以他們在這個世界上的存在時間, 并不足以使得他們經歷各種技術細節(jié). 架構設計更多的是依賴我們對于系統(tǒng)結構原理的理解, 而經驗可以讓我們規(guī)避那些原理失效的地方(例如系統(tǒng)級bug). 君子非異能也, 善假于物也. 很多時候,我們更應該從有經驗的朋友或者技術支持那里搜集技術細節(jié), 以確保它們能夠滿足我們在架構上的原理性需求. Know Why而不僅僅是Know How是非常重要的. 一個農民發(fā)明家也許可以得到某個巧妙的機械設計, 但是沒有系統(tǒng)的掌握工程力學, 他們是無法去開發(fā)精密的導彈控制系統(tǒng)的.當然, 軟件開發(fā)還處在非常原始的階段, 掌握一些設計原理和設計模式多半也不過是五十步笑百步而已, 經驗的地位是無可替代的.

    架構師不是預言家. 在多變的業(yè)務環(huán)境中, 架構師的目標不應該是預測到所有的變化可能, 并把它們表達到系統(tǒng)架構中. 這個世界上不乏一些耗資數(shù)十億,設計三四年,但最終每個談到它的人都要說一句shit的產品開發(fā)項目. 架構設計所能做到的最好的程度是自然的標注出系統(tǒng)的結構邊界,成功的delay各種技術抉擇.

    架構師不是超人, 他所考慮的東西也許要遠一些, 所需要平衡的利益也許要多一些, 但是單獨一個人是無法對整個產品或者項目的成敗負責的. 如果ThoughtWorks的Martin Follower來處理國內的某些項目, 我估計他會死得很難看.架構師也是人, 也會犯錯誤,甚至是很低級的錯誤, 而每個人都會有一些獨特的想法. 經歷的多了, 你就會回歸到終極的認識, 一切都只是浮云, 只有money才是硬道理.

    現(xiàn)在MDA建模的宣傳多集中于可視化的表現(xiàn)形式, 鼓吹通過平面圖標的擺放來傳達信息. 圖形的方式是否一定比文本表現(xiàn)要優(yōu)越呢?  圖形的表現(xiàn)能力確實是要強于普通文本的.文本對于信息的組織方式基本上是一維的, 而平面圖形本質上是二維的(如果考慮顏色因素, 平面圖形可以說是2.5維的). 人的視覺對于圖形有著天然的并行處理能力, 通過圖形我們有可能更有效的獲得信息. 但是程序中細節(jié)的關聯(lián)可能是復雜的, 多維的, 二維圖形同樣難以直接描述這些關聯(lián), 而一維的文本對于所有維度的描述是對稱的, 可能在描述多維關系時更加容易維持簡單性和一致性. 當描述復雜的關聯(lián)時, 我們不可避免的需要采取多層次封裝的方式, 在圖形界面上我們可能要通過多次點擊才能到達某一細節(jié)層面, 這樣反而不如純文本方式更加"并行化": 在純文本方式下, 我們在一個文件中能夠同時看到所有高層次和低層次的信息, 并能夠通過查找和翻頁沿著一個固定的維度迅速定位到所需要的章節(jié)處. 受限于人類視野的大小, 我們所看到的圖形不能過大也不能過小, 這樣在一定程度上也限制了圖形方式所能夠傳遞的信息量. 有的時候圖形上標注了過多的關聯(lián)反而使我們更加迷惑.  所謂可執(zhí)行的UML要真的運行起來, 需要大量的信息隱蔽在圖形表象之下, 在我看來這是一個沒有什么實際意義的概念.