級列理論是分析學中常見的一個思維框架，我只是把它從我最熟悉的物理學中借用到軟件設計領域而已，
它本身并不是我所創造的一種概念（創造是艱難的）。在某些領域，這一分析框架可以表現出完美的數學特性，如時頻分析領域的小波分析(wavelet),
統計學習理論中的支持向量機(Support Vector Machine),
分子動力學中的BBGKY級列等等。在其他一些領域它的精確性可能要弱很多，但其思想內核是一致的.
級列理論的基本內容如下:
http://canonical.blogdriver.com/canonical/562888.html
首先, 級列理論需要定義一個最一般的普遍模型, 但這并不意味著對系統的一種過分的限制. 實際上,
我們所討論的任何問題都有一個總體的框架限制, 它的作用只在于揭示出我們所研究的問題的基本要素并勾勒出一幅全景式的圖像.
最一般的情況與我們的求解能力的距離可以是非常遙遠的，例如真正實作的時候在物理中往往我們只是研究一階或者二階情況。而在計算機領域也是存在著最一般的
模型的, 那就是Turing Machine. 在一般情況下, 我們是能夠建立一個足夠普遍的模型以囊括絕大多數變化可能的,
雖然我們極有可能沒有能力去求解這個模型.
對于系統的完備性, 物理學與數學的態度是有著深刻區別的.
在物理學中我們只需要在研究問題的范疇內維持概念的穩定性即可, 這往往意味很多簡化與隱含條件,并不是一種終極的完備性. 而在另一方面,
數學的完備性并不能保證它描述現實世界的完備性. 最明顯的, 從經典力學到狹義相對論, 再到廣義相對論,
在每一個層次上都是存在著非常完美的數學描述的, 其數學空間都是完備的, 但是很顯然, 即使是廣義相對論, 它也不是對于物理世界的完備描述.
目前物理學界仍然在量子引力的黑暗中摸索. 所有這一切都不影響我們在建筑工程中以足夠高的精度應用力學原理.
級列理論所描述的絕不是一種從一般到特殊的思想的應用, 而是同時包含著從一般到特殊和從特殊到一般兩個方向. 在級列理論中,
我們首先研究的一般是最特殊的情況, 即最簡單, 對稱性最高的情況. 此時模型中特征元素個數很少, 而且界限分明, 很少交互或者發生關聯.
我們得到簡單模型的解之后, 就可以將其作為初始解去求解更高階的模型. 這是從特殊到一般的一種進展. 而在另一方面,
我們可能以創造性的方式得到某個更高階模型的解, 此時我們需要研究高階模型與較低階模型之間的關聯, 考察當更高階的模型退化到低階模型的時候,
它們的解是如何自然的實現退化的. 雖然迭代這個名詞在當前軟件工程領域如日中天,
但我想很多開發人員卻從未花上一刻時間去真正的體味這個概念本身的內涵, 而陷入了人云亦云的窘境. 從數學上說, 迭代過程的基本問題是收斂問題,
而且往往收斂過程中的控制策略要遠比迭代初始值的選擇更重要. 那么什么樣的控制策略才是保持探索性但又傾向于收斂的呢? 連續性是最基本的要求.
參見 反問題的級列求解
http://canonical.blogdriver.com/canonical/974280.html.
級列理論最關鍵的部分其實是兩個存在性: 一是復雜性級列的客觀存在, 二是級列之間連續性的客觀存在.
注意到級列理論所描述的只是存在性，在一般情況下，
我們并不能直接得到從低階解推導出高階解的構造方法。而復雜性的級列的存在意味著總存在超越我們當前認知范圍的信息，
從低復雜性層次上升到高復雜性層次可能是需要非凡的創造力的，
決不是顯然的。此時我們唯一的選擇只能是從后驗的角度去檢驗這種存在性。模型的可退化性正是連續性的一種自然推論。這在物理學中是一件不言而喻的事情也是
一種強制性的要求：狹義相對論可以在低速情況下退化為Newton力學，而廣義相對論可以在引力均勻的情況下退化為狹義相對論。在軟件領域，
似乎只是到了近幾年，
可退化性才得到了一些重視，至今很多人對它的思想實質仍然沒有充分的了解。退化是否是指系統中不同職責部分的合并但是這些職責依然存在? NO,
NO, NO. 精簡機構的原因難道是為了裁減人手,增大人均工作量嗎? 精簡的原因首先在于人浮于事, 本身就沒有那么多的職責,
卻要生造出那么多的處理步驟來.
我們或者合并部門，或者干脆撤銷部門，一些專門因為內部協調而生的部分更是要被毫不留情的裁減掉。在常見的軟件開發中,
明明是非常簡單的數據庫訪問操作, 偏偏要在service層, data object層, dao層都把同樣的接口代碼重復一遍,
美其名曰多層體系架構, 可以保持系統的靈活性. 可是誰需要這種靈活性, 它到底是設計的靈活性還是設計的脆弱性? 在簡單的情況下, 選擇meta
driven的方案,從描述文件直接驅動多個層次的運作往往能夠極大的提高系統的穩定性和靈活性.
假設現在有一個網絡應用,
我們首先考慮最簡單的情況, 例如我們假設只存在一種通信協議:打電話. 我們可以通過電話通知另一方的接線員,
讓他把信息記錄下來再錄入系統當中,以此維持系統的運轉. 如果永遠都只有一個固定的接線員X通過唯一的一部電話M來完成通信過程,
則系統中的多個概念就會發生簡并: 通信將等價于打電話,等價于打電話給X, 等價于使用電話機M打電話給接線員X. 隨著系統的復雜性逐漸增大,
系統的對稱性出現破缺, 原本被認為同一的概念出現了微妙的不同, 并可能演變成差異巨大的兩個分支. 假設現在多了另外一種通信協議:硬盤交換.
我們可以把數據拷貝到一塊硬盤上, 然后攜帶到遠處的機房, 在那里把數據導入系統, 以維持系統的運轉.
如果我們的系統演化到了這個階段是否意味著我們原先的軟件模型已經徹底崩潰了? 并不是如此的, 在一個宏觀的粒度上,
我們的系統所需要的可能只是一種端到端的通信手段, 只是現在通信這一更高層的抽象概念不再等同于更加細節化的具體通信手段(打電話)了.
如果原先系統設計中的各個主要模塊之間只存在高層抽象之間的依賴, 則只需要增加一些數據導入導出模塊,
我們的系統就可以平滑(連續)的接納一種新的通信協議. 一種宏觀的高層視圖如果直接映射到某種實現, 則它所對應的就是一種最簡單的系統模型.
系統的不斷發展相當于是給這個最簡單的模型不斷補充細節, 使它不斷的復雜化. 這種變化是有脈絡可尋的, 很多時候是局部的, 輕微的. 當然,
持續累積下去, 也許有一天我們會突然發現系統已經面目全非了, 甚至原先的高層視圖(簡單模型)也無法維持了. 但是即使這樣,
是否意味著我們原先的設計失敗了呢? 答案仍然是否定的. 軟件系統如同其他系統一樣, 處在不斷的演化狀態當中, 但是什么叫做系統的演化?
很多人有一種錯覺, 以為軟件結構完全不變, 完全不需要源代碼級別的修改, 只需要通過外部配置導入擴展對象的設計才是好設計,
才是成功的可擴展設計. 這是以一種靜態的僵化態度來看待程序的演化, 沒有理解演化的實質.
演化(evolution)首先是一種變化(variation). 按照級列設計理論, 當系統沿著復雜性的級列發生演化的時候,
因為不同復雜性層次之間存在著本質性差異, 我們不能奢望現在的簡單設計能夠一直包容越來越復雜的模型,
更加現實的態度是能否在未來的復雜的模型中為現在的簡單設計找到位置. 我們不預言未來, 也無法保證我們現在的行為能夠容納將來的選擇.
在適度重構的意義下實現部分重用已經是我們能夠做到的最好程度了. 我們需要理解世界本身是在變遷的, 即使現在我們能夠預測到未來,
現在就為其作準備也未必是適當的, 因為現在的最優不等價于將來的最優, 同樣將來的最優也不等價于現在的最優.
在上文中的網絡應用的例子中, 也許系統最終發展成為一個非常龐大的系統, 而我們最初設計的功能成為了該系統的一個子模塊,
這不是完美的可擴展性嗎?
http://canonical.blogdriver.com/canonical/1002861.html
級列理論的思想是非常通俗的, 并沒有絲毫神秘的地方.
復雜性的級列可以在空間中呈現出一種復雜性遞增的形態，也可以沿著時間軸展開，構成發展的形態。在傳統設計理論中也在頻繁的處理著這些問題,
因而可以看到很多相近的思想, 但是我們也需要注意到一些細節性的不同.
傳統的設計中也講層次，但是多半說的是stratify而不是hierachical，是同一時刻可以看到的一種層次堆壘關系，而不是在不同復雜性層次上
才揭示出的級列關系. 傳統設計中也講高級抽象與低級抽象之間的關系，但沒有提供級列理論中完整的視圖, 也很少強調每個層次上元素之間的連續性。
關于級列設計理論在軟件設計中的適用性, 我只想提一下witrix平臺中的jsplet開發框架, 參見
從級列理論看MVC架構
http://canonical.blogdriver.com/canonical/579747.html
jsplet:對Model 2模式的批判
http://canonical.blogdriver.com/canonical/591479.html
在2002年左右, 我是先得到級列設計理論, 然后才根據其思想設計的jsplet框架. 在整個witrix平臺的設計中,
級列設計理論也是重要的指導思想. 不過, 以我的經驗來看, 一般人是很難理解他人的思想的, 即使是對別人的想法有些興趣,
實際思考的東西與作者的原意往往也有著很大的差異.
http://canonical.blogdriver.com/canonical/1014773.html
最后我還是強調一下一件最最基本的事情, 一件每個人都應該時刻牢記的事情: 不要孤立的看待問題, 而是尋求一種概念之間的連續性.
http://canonical.blogdriver.com/canonical/1016684.html