canonical

    軟件開發(fā)作為一種工程技術，它所研究的一個重點就是如何才能有效降低軟件產品的研發(fā)成本。在這一方向上，組件技術取得了空前的成功。它所提供的基本圖景是 像搭積木一樣從無到有的組裝出最終的產品。在某種意義上，這是對現(xiàn)代建筑工業(yè)的模仿和致敬。新材料，預制件，框架結構，這些建筑學的進展在軟件領域被一一 復制，建筑工地上的民工自然也成為了程序員們學習的楷模。畢竟，在組件的世界中碼代碼，基本上也是一種“搬磚”的行為。

    值得慶幸的是，軟件開發(fā)作為一種智力活動，它天生具有一種“去民工化”的傾向。信息產品有著與物質世界產品完全不同的抽象本質。在物理空間中，建造100 棟房屋，必須付出100倍的努力，老老實實的干上100遍。而在概念空間中建造100棟房屋，我們卻可以說其他房屋與第一棟一模一樣，加點平移旋轉變換即 可。一塊磚填了地基就不能用來蓋屋頂，而一段寫好的代碼卻可以在任何可用的場合無損耗的被使用。一棟建好的房屋發(fā)現(xiàn)水管漏水要大動干戈，而在完成的軟件中 補個局部bug卻是小菜一碟。在抽象的世界中有效的進行生產，所依賴的不應該是大干,苦干的堆砌，而應該是發(fā)現(xiàn)某種可用于推導的原理，基于這些原理，輸入 信息可以立刻轉換為最終的結果，而不需要一個逐步構造的過程。即我們有可能超越組裝性生產，實現(xiàn)某種類似于數(shù)學的原理性生產。http://canonical.javaeye.com/blog/325051

    代碼復用是目前軟件業(yè)中鼓吹降低生產成本的主要口號之一。但是在組件技術的指向下，一般所復用的只是用于構建的磚塊，而并不是某種構造原理。即使在所有信 息已經確定的情況下，我們仍然不可能從需求立刻得到可執(zhí)行的產品。很多代碼即使我們在想象中已經歷歷在目，卻仍然需要一行行把它們謄寫下來。當我們發(fā)現(xiàn)系 統(tǒng)中已經沒有任何組件值得抽象的時候，仍然留下來眾多的工作需要機械化的執(zhí)行。代碼復用的理想國距離我們仍然非常的遙遠。

    子例程(subroutine)是最早的代碼重用機制。這就像是將昨天已經完成的工作錄制下來，在需要的時候重新播放。函數(shù)(function)相對于子 例程更加強大。很多代碼看起來并不一樣，但是如果把其中的差異部分看作是變量，那么它們的結構就可以統(tǒng)一了。再加上一些判斷和循環(huán)，很多面目迥異的東西其 實是存在著大量共享信息的。面向對象技術是一次飛躍性的發(fā)展。眾多相關信息被打包到一個名稱（類型）中，復用的粒度和復雜度都大大提升。派生類從基類繼 承，可以通過重載實現(xiàn)對原有代碼的細致調整。不過，這種方式仍然無法滿足日益增長的復用需求。很多時候，一個名稱并不足以標定我們最終需要的代碼結構，在 實際使用的時候還需要補充更多的信息。類型參數(shù)化，即泛型技術，從事后的角度看其實是一種明顯的解決方案。根據參數(shù)動態(tài)的生成基類自然可以吸納更多的變 化。經歷了所謂Modern C++的發(fā)展之后，我們現(xiàn)在已經非常明確，泛型并非僅僅能夠實現(xiàn)類型共變，而是可以從類型參數(shù)中引入更豐富的結構信息，它的本質是一種代碼生成的過程。http://canonical.javaeye.com/blog/57244 認清了這一點，它的擴展就非常明顯了

DSL（或者某種模型對象）相對于普通的類型(Class)，信息密度要大很多，它可以提供更豐富也更完整的輸入信息。而CodeGenerator也不必拘泥于基礎語言本身提供的各種編譯機制，而是可以靈活應用各種文本生成技術。http://canonical.javaeye.com/blog/309395 CodeGenerator在這里所提供的正是根據輸入模型推導出完整實現(xiàn)代碼的構造原理。

    現(xiàn)在很多人熱衷于開發(fā)自己的簡易代碼生成工具，這些工具也許可以在簡單的情形下減輕一些體力工作，但是生成的代碼一般不能直接滿足需求，仍然需要手工執(zhí)行 大量的刪改工作。當代碼生成之后，它成為一種固化的物質產品，不再能夠隨著代碼生成工具的改進而同步改進，在長期的系統(tǒng)演化過程中，這些工具并不一定能夠 減少累積的工作量。

為了改進以上代碼生產過程，一些人試圖在CodeGenerator中引入越來越多的可配置性，將各種變化的可能內置在構造原理中。顯然這會造成CodeGenerator的不正常的腫脹。當更多的偶然性被包含在原理中的時候，必然會破壞原理的簡單性和普適性。

必須存在[修正補充]這一項才能維持以上方程的持久平衡。

    為了擺脫人工修正過程，將模型調整納入到概念世界中，我們需要超越繼承機制的，更加強大的，新的技術手段。其實在當前的技術背景下，這一技術已經是呼之欲出了。這就是AOP, Aspect Oriented Programming。http://canonical.javaeye.com/blog/34941

繼承僅僅能夠實現(xiàn)同名方法之間的簡單覆蓋，而AOP所代表的技術原理卻是在代碼結構空間中進行任意復雜的刪改操作,它潛在的能力等價于人工調整。

    為了實現(xiàn)上述生產模式，需要對編程語言，組件模型，框架設計等方面進行一系列改造。目前通用的AOP實現(xiàn)和元編程技術其實并不足以支持以上模式。http://canonical.javaeye.com/blog/275015
    這一生產模式將會如何演化，也是一個有趣的問題。按照級列理論，我們立刻可以得到如下發(fā)展方向：

    Context0 + DSL1 + EXT0 = DSL0  
    Context1 + DSL2 + EXT1 = DSL1 
   

 http://canonical.javaeye.com/blog/33824

Witrix平臺中BizFlow可以看作是對DaoWebAction的修正模型，但是它本身具有完整的意義，可以直觀的被理解。在BizFlow的基礎上可以逐步建立SeqFlow，StateFlow等模型。http://canonical.javaeye.com/blog/126467

      現(xiàn)在有些人試圖深挖函數(shù)式語言，利用模式匹配之類的概念，做符號空間的全局優(yōu)化。但是我們需要認識到通用的機制是很少的，能夠在通用語言背景下被明確提出 的問題更是很少的。只有在特定領域中，在掌握更多局部信息的情況下，我們才能提出豐富的問題，并作出一定背景下的解答。DSL的世界中待做的和可做的工作 很多。http://canonical.javaeye.com/blog/147065

      對于程序員而言，未來將變得越來越豐富而復雜，它將持續(xù)拷問我們的洞察力。我們不是一行行的編寫代碼，把需求一條條的翻譯到某種實現(xiàn)上，而是不斷發(fā)明局部的生產原理，依靠自己制定的規(guī)則在抽象的空間中不斷的創(chuàng)造新的表象。