老翅寒暑

要做一個應用程序框架的念頭Bigtall在幾年前就有了，因為在工作中發(fā)覺很多方面非常的不順手，幾乎每一個環(huán)節(jié)都存在這樣或者那樣的問題：

• 公司不同項目組做的設計是完全不同的風格，而且設計做不細，導致項目計劃越來越流于形式
• 各層代碼凌亂，從后臺的java或者c#到前臺的html，天馬行空，隨心所欲
• 數(shù)據(jù)庫結(jié)構(gòu)和文檔不匹配，要不是莫名其妙的多、少字段，要不就是些莫名其妙的名字

如果深入到設計方面，就會發(fā)現(xiàn)雖然做過很多的項目，但是幾乎沒有可以參考的成功案例，所有的設計哪怕是同類型項目，也幾乎要重頭開始；編碼方面就更加麻煩了，我最深刻的印象就是從業(yè)以來我編制了無數(shù)的字符串處理函數(shù)，有c/c++版本的，有C#版本，有java版本的，還有delphi和早已忘記的vb，當然，更少不了時下流行的js了（這還是好的呢）。一旦到了項目規(guī)模較大的時候，我們甚至會在代碼流程中迷路，不知道調(diào)用從哪里來，不知道邏輯要往哪里跳。

這么多的問題，是廣大的處于CMM 1級的軟件企業(yè)共同存在的問題，當然也會出現(xiàn)在那些CMM2345實際還是CMM1的軟件企業(yè)中。加入管理手段（比如真正去實施CMM規(guī)范）可以解決大部分的問題，準確地說是可以解決幾乎所有的管理問題并緩解大部分的技術問題，但是解決不了所有的問題。

以前bigtall在的公司曾經(jīng)出現(xiàn)過這種論調(diào)“技術是不重要的，市場和管理才是最重要的”，最后公司走入了低谷，好不容易聚集的人才也散了。別人的教訓就是自己的經(jīng)驗，bigtall后來進行深刻的反思，認為這里有一個“度”的問題，我們先看兩個極端“只有市場和管理但是沒有技術”“只有技術沒有市場和管理”的后果，一個是“守不住”，一個是“推不了”。其實兩者是相輔相成的，技術可以把市場的門檻推高，市場和管理可以讓技術更順利地發(fā)展。所以一個公司沒有“最好”的技術，只有“最適合”的技術。一個公司的技術目標應該也只應該是“不斷降低公司的成本”。

最明顯的就是項目系統(tǒng)設計的重用問題，無論你是CMM多少級，如果沒有一個統(tǒng)一的軟件架構(gòu)，重用就會打折扣甚至根本就無法重用。就像南方人北方人溝通要用普通話，今人和古人溝通就必須用相同的文字（順便鄙視并可憐一下朝鮮、韓國和越南）一樣，前后的項目要能夠溝通交流，他們就需要一個相同的結(jié)構(gòu)。所以“程序框架”就是公司項目之間的“普通話”，也是項目內(nèi)部的“潤滑劑”。

這里要明確一下“程序框架（Framework）”和“軟件架構(gòu)（Architecture）”之間的區(qū)別，簡單地說，程序框架是一個可以實際應用的代碼集合，而軟件架構(gòu)可以看作是一種抽象的設計。另外，兩者的關注面也不一樣，程序框架熱衷于解決實際運行過程中的問題，甚至會提供工具包或者輔助模塊（比如權(quán)限系統(tǒng)、日志系統(tǒng)等），而軟件架構(gòu)則集中精力在各個部分（模塊、組件等）之間的關系。兩者其實是關于同一個事情的不同層次的東西。

我們可以來看一下如果存在程序框架會讓文章開頭的幾個問題解決多少：

1. 如果有程序框架，因為項目的WBS幾乎是一致的，所以上一個項目的項目計劃可以直接拿過來使用，而且經(jīng)過幾個項目之后，這個項目計劃的模板會越來越細，越來越實用。
2. 設計過程中，除了需求之外，概要設計、詳細設計的重用性會很高。
3. 因為結(jié)構(gòu)一致，代碼混亂性會降低到可以接受的程度，而且可以重用上一個項目的大部分代碼。而且邏輯清晰，使得代碼相對較小，不容易在代碼中迷失。因為代碼邏輯簡單有序，所以測試起來會很容易。
4. 降低管理成本，除了項目計劃之外，測試計劃，QA計劃等等都可以重用，如果用CMM規(guī)范，項目評審的速度和質(zhì)量都會有提高。

要做一個應用程序框架并不是一件容易的事情，一是這方面發(fā)展很快，而且水平相對較高，如果沒有獨到的解決方案，可能自己的框架一出來就過時了。二是應用程序框架涉及的方面較多，考慮清楚并不是一件容易的事情。三則是開發(fā)一個應用程序框架需要耗費大量的時間，也就是意味著公司需要花費（你的工資×開發(fā)時間+其他）這么多的金錢。

對于小公司來說，除非有著清醒的認識，否則開發(fā)自己的應用程序框架可能是自尋死路。bigtall建議小公司如果.net開發(fā)，則直接用Petshop4的框架，如果java開發(fā)，則直接使用appfuse進行開發(fā)，如果想要一個新的語言，則直接用Ruby On Rails開發(fā)吧。對于php沒有建議，不太熟。

現(xiàn)在如果要開發(fā)一個應用程序框架，至少需要滿足如下的幾個條件：

• 分層（廢話）
• 易于測試
• 易于擴展，并跟現(xiàn)有的其他系統(tǒng)進行無縫整合。一般要具有AOP、IOC、DI能力。
• 易于部署
• 具有權(quán)限，用戶管理能力
• 有組織架構(gòu)、工作流、規(guī)則引擎支持
• 有頁面流轉(zhuǎn)，狀態(tài)管理能力
• MOF或者MDA能力
• SOA能力
• 界面技術的抽象能力（如WebForm，HTML，Ajax，Xml，Rich Web等）

bigtall的應用程序框架設計系列文章準備從簡單開始，一步一步記錄并呈現(xiàn)給大家bigtall開發(fā)框架的整個過程。文章列表如下：

1. 多層應用之間的數(shù)據(jù)傳遞： 分層和層間數(shù)據(jù)傳遞（上）、分層和層間數(shù)據(jù)傳遞（下）
   多層架構(gòu)已經(jīng)成為了標準，但是數(shù)據(jù)在穿越各個層次的時候，它的形態(tài)有什么變化和規(guī)律呢？
2. 界面層的分析和抽象
   界面層承載了應用程序所有的可視部分，究竟里邊還有多少我們需要關注但是卻忽略了的事實？
3. MOF/MDA的支持和程序的設計規(guī)范
   如果人在根本上是不可靠的，那么就盡可能不用人去做。但是到達這一步，我們還需要告訴機器一些什么東西？
4. 工具！我的工具！
   bigtall設計的小工具
5. 待續(xù)