atitit.提升軟體開發的效率and 品質的那些強大概念and方法總結

標籤：

atitit.提升軟體開發的效率and 品質的那些強大概念and方法總結

 

1. 主流編程中三個最糟糕的問題 1

1.1. 從理解問題後到實現的時間很長 1

1.2. 理解和維護代碼 2

1.3. 學習曲線高 2

1.4. 擴充性爛 2

1. Coc 2

2. Dsl 2

3. DSM 3

4. 4gl 3

5. 產生式編程(Generative Programming,GP) 3

5.1. 為重用而開發以及使用重用的開發 3

6. 在模型驅動開發（MDD）介紹MDA 4

7. ·  元編程 4

8. 意圖編程 4

9. ·  AOP 5

10. ·  泛型程式設計 5

11. FP 5

12. 面向語言編程LOP（Language Oriented Programming）5

13. 代碼產生 VS 模型解釋6

14. 參考 6

 

 

 

1. 主流編程中三個最糟糕的問題1.1. 從理解問題後到實現的時間很長

在明白問題和解決方案後，將解決方案編碼到電腦中將會花費很長的時間。這是因為可以使用非常豐富的自然語言表達問題，但我們只能通過通用的程式設計語言與電腦交流。而現在的程式設計語言只有幾十種，而自然語言表達可以有千萬上萬種，因此這種轉換的成本是比較大的。

在主流編程中，大部分時間都是在“編程”上，這實 際上是在用編程層次的抽象術語來表達自然語言的概念，而這是很困難的，沒多少創造性，或多或少也是一種時間的浪費。舉個例子，今天大量的開發時間花費在面 向對象的設計（OOD）上，在程式員表達類、繼承、關聯等方面這確實是一種還算有創造性的過程，但是使用Language Oriented Programming，OOD根本就不需要。

（個人觀點：這個我還不是很瞭解，我想底層還是需要的吧，有待進一步瞭解）

 

作者:: 老哇的爪子 Attilax 艾龍，  EMAIL:[email protected]

轉載請註明來源： http://blog.csdn.net/attilax

 

1.2. 理解和維護代碼 

在通用語言的程式中，很多高度概括的視角、藍圖都 丟失了，這不利於我們對產品理解。解決這個問題的傳統方法是寫注釋或用其它形式的文檔來記錄設計資訊和模型資訊，但這證明了這是一種脆弱的解決方案，因為 它需要編寫這些輔助文檔的成本、以及文檔和代碼帶來的不同步麻煩等問題；理想情況下，代碼應該是自我描述的，我應該只閱讀代碼本身來理解代碼，而不是什麼 注釋和外部的文檔。

1.3. 學習曲線高 

OOP很少能夠直接表述領域概念，它們必須引入額 外的枝節（如一個類的運行時行為）來完成到領域概念的映射。理解這些領域、學習這些類庫不是一項簡單的任務，我們需要用大量的指南和文檔來解決這個問題， 但是學習這些將花費大量時間；當一個類庫變得複雜的時候，它也變得更難以學習，程式員將因此失去學習它的動機。即使掌握了領域問題和技術的這種複雜映射之 後，依然還會很容易的誤用類庫，因為開發環境（像編譯器和編輯器）不能協助你正確的使用類庫。

1.4. 擴充性爛

當需要進行一些語言擴充時，我們只能等待語言的設計者去更新它；如果需要我的IDE有一些額外的強大功能，只能等待供應商來添加新特性；就是這些依賴限制了我們完全的自由；當然，程式員也可以寫自己的編譯器和IDE，但這樣將會花費大量的時間和努力，並且並不一定能成功。

1. Coc2. Dsl3. DSM4. 4gl5. 產生式編程(Generative Programming,GP)

因為我們平時寫程式一個非常大的苦惱就是領域知識已經深深的隱藏在代碼中，而任何一個領域知識的變動對程式來說就是無休止的改動和調試。而產生式編程卻可以做到以代碼的形式清晰的表現領域模型。

是一種軟體工程泛型(paradigm)，基礎是對系統族建模。就是說，給一個特定的需求說明書(specification)，就可以根據要求製作出一個高度定製、最佳化的中間產品或者最終產品。這需要使用基本的、可重用實現組件通過配製知識的方式實現。

在軟體中，向自動化製作軟體的方向轉變需要經曆兩個步驟：

1. 把焦點從開發一個系統轉移到開發一個系統族上來：開發出正確的共性組件

2. 使實現組件的裝配自動化：使用產生器達到自動化

　　我感覺它可以作為產品線工程的一種軟體工程方法，產生式編程就是設計實現組件，使之適應於通用產品線結構，同時對配置知識建模，強調如何把抽象的需求轉變成特定的組件群，並且使用產生器實現配置知識，通過這些工作來解決前面說的高複雜性、高效率和高品質等問題。

GP的目的地組中於系統族，而不是一種一個的系統（one-of-a-kind system），它不是從頭構造一個單獨的系統族成員，而是基於一個通用的產生式領域模型。模型由三部分組成：

1. 指定系統族成員（問題空間 problem space）

2. 組裝出每一個成員的實現組件（解空間 solution space）

3. 在問題空間和解空間之間的配置知識映射關係（配置知識）

5.1. 為重用而開發以及使用重用的開發

產生式編程是產生的，如：AOP（AspectJ），DSL（Drools）

產生式編程是組合的，

1.產生式是自底向上，而聲明式是自定向下。即產生式編程用的思路是組合概念（用小粒度的概念組合產生大粒度的概念），
而聲明式編程是解析概念，用統一的概念來理解，把不同差異性交由具體程式解析。
2.聲明式編程的編輯器產生的是xml檔案，將由架構程式解析；而產生式產生程式碼，不做解析運行。
3.由於1，導致中繼資料模型不一樣，產生式是相對細粒度的，而聲明式是粗粒度的（不能直接比較大小，定義的是無差異性的概念）。如Ant，jbpm都是很大的概念。

6. 在模型驅動開發（MDD）介紹MDA7. ·  元編程

編寫元程式的語言稱之為元語言。被操縱的程式的語言稱之為目標語言。一門程式設計語言同時也是自身的元語言的能力稱之為反射或者自反。

反射是促進元編程的一種很有價值的語言特性。把程式設計語言自身作為一級資料類型（如LISP，Forth或Rebol）也很有用。支援泛型程式設計的語言也使用元編程能力。

元編程通常通過兩種方式實現。一種是通過API（APIs）將運行時引擎的內部資訊暴露於編程代碼。另一種是動態執行包含編程命令的字串運算式。因此，“程式能夠編寫程式”。雖然兩種方式都能用於同一種語言，但大多數語言趨向於偏向其中一種。

最常見的元編程工具是編譯器，它可以將程式員使用進階語言編寫的相對短小的程式轉換為等價的組合語言或者機器語言程式。這是最基礎的編程工具，在大多數情況下，直接編寫機器語言程式是不太現實的。

在程式中嵌入直接處理常式資料的解譯器即可實現這一目的。現在已經有一些用於常用進階語言的實現，例如RemObject為Object Pascal編寫的Pascal Script。

另一個很常用的元編程例子是lex和yacc，這兩個工具用來產生詞法分析器和文法分析器。Yacc通常用作編譯器的編譯器，產生能夠將進階語言轉換為機器語言的工具。

8. 意圖編程

財務人員看見電子錶格軟體的時候眼睛發亮，我想當程式員看見可用的意圖編程工具的時候也會發亮的。

意圖編程的提出者也是“所見即所得 (WYSIWYG)”文檔編輯的發明人。

他說“目前，編程正好和開採鑽石過程相反，在開採鑽石時你挖出大量的泥土,而找出一點點昂貴的鑽石。可程式化時，你從一個有價值的真正意圖開始, 隨後卻把這種意圖埋在泥土中”。

 

噴氣發動機的例子。他說，拿渦輪葉片來說，它們必須做得 非常精確。即使由很細心的熟練工人加工葉片，仍然不可能達到你要求的精度，而必須另造一台機器來加工葉片。其中會有人幹預這個過程嗎？當然，製造、維修和 調整機器必須由人來完成。機器也會出錯，機器一旦出錯會很顯著，你能馬上發現，並改正它。程式編碼也是如此。不需要人去接觸編碼。否則程式易於出錯。人能 製造這種機器。..

 

9. ·  AOP

Aspect Oriented

10. ·  泛型程式設計

泛型程式設計最初誕生於C++中，由Alexander Stepanov[2]和David Musser[3]創立。目的是為了實現C++的STL（標準模板庫）。其語言支援機制就是模板（Templates）。模板的精神其實很簡單：參數化型別。換句話說，把一個原本特定於某個類型的演算法或類當中的類型資訊抽掉，抽出來做成模板參數T。比如qsort泛化之後就變成了：

11. FP12. 面向語言編程LOP（Language Oriented Programming）

 

LOP放棄了傳統的基於文本的語言，用創造新的語言來代替類庫，可以和編輯器所整合，並且每個程式員都可以創造自己的語言

按照Dmitriev先生的觀點，通用語言的問題在於：它們描述領域模型的能力太差。在完成概念性的領域建模之後，開發人員們還必須經過一個漫長的編碼過程，才能把模型描述為機器可理解的程式，反過來要理解這些代碼所描述的領域模型也是同樣困難。而DSL雖然能夠很好地描述領域模型、解決領域問題，但這種語言又太少了，而且大多數開發人員必須苦苦等待少數大廠商為他們提供適用的DSL。很大程度上，這種“語言的失位”造成了軟體開發的低效。

　　Dmitriev先生提出的解決方案就是LOP：藉助工具的協助，允許開發人員建立自己的DSL。這樣的DSL當然能夠最貼切地描述領域問題，從而大大提高開發效率。而且，這樣的“自訂DSL”也不必是文本形式的，它可以直接儲存為樹狀結構（或別的結構），並直接以圖象的形式展現。

LOP的切入點就是允許我們可以建立、重用、修改語言和環境。要理解LOP 是什麼，可以從的主流編程和LOP方法過程進行一下比較，它使得編程階段已經不是瓶頸了，而轉移到了“建立”這一步，作者開發可一個通用的平台 （the Meta Programming System）來設計DSL，它允許程式員像現在編寫程式一樣非常容易的就可以定義自己的語言；這個平台將完全支援LOP，給程式員為程式的每一部分選擇 使用最合適的語言的自由，而不是將他們綁在某個固定的通用程式設計語言之上。

LOP將不只是編寫程式，還包括建立用來編寫程式的語言

13. 代碼產生 VS 模型解釋

我們可以解釋模型直接運行在領域架構之上，也可以把模型通過代碼產生技術轉換成代碼之後編譯運行在架構之上。這兩種方式都有利弊，可以搭配使用，在OpenExpessApp中將採用這兩種方法，類庫通過代碼產生，UI等元模型通過架構解釋執行。由於代碼產生是MDD中很重要的一項技術，所以本篇我將介紹一下代碼產生相關的知識。

 

14. 參考

MDSF：產生式編程（Generative Programming）方法介紹 - 周 金根 - 部落格園

MDSF：面向語言編程LOP（Language Oriented Programming）方法介紹 - 周 金根 - 部落格園

MDSF：LOP-使用MPS來做個計算機的樣本 - 周 金根 - 部落格園

MDSF：代碼產生 VS 模型解釋 - 周 金根 - 部落格園

atitit.提升軟體開發的效率and 品質的那些強大概念and方法總結