1. 程式人生 > >應用程式框架設計之前言 (轉)

應用程式框架設計之前言 (轉)

要做一個應用程式框架的念頭Bigtall在幾年前就有了,因為在工作中發覺很多方面非常的不順手,幾乎每一個環節都存在這樣或者那樣的問題:

  • 公司不同專案組做的設計是完全不同的風格,而且設計做不細,導致專案計劃越來越流於形式
  • 各層程式碼凌亂,從後臺的java或者c#到前臺的html,天馬行空,隨心所欲
  • 資料庫結構和文件不匹配,要不是莫名其妙的多、少欄位,要不就是些莫名其妙的名字

如果深入到設計方面,就會發現雖然做過很多的專案,但是幾乎沒有可以參考的成功案例,所有的設計哪怕是同類型專案,也幾乎要重頭開始;編碼方面就更加麻煩了,我最深刻的印象就是從業以來我編制了無數的字串處理函式,有c/c++版本的,有C#版本,有java版本的,還有delphi和早已忘記的vb,當然,更少不了時下流行的js了(這還是好的呢)。一旦到了專案規模較大的時候,我們甚至會在程式碼流程中迷路,不知道呼叫從哪裡來,不知道邏輯要往哪裡跳。

這麼多的問題,是廣大的處於CMM 1級的軟體企業共同存在的問題,當然也會出現在那些CMM2345實際還是CMM1的軟體企業中。加入管理手段(比如真正去實施CMM規範)可以解決大部分的問題,準確地說是可以解決幾乎所有的管理問題並緩解大部分的技術問題,但是解決不了所有的問題。

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

最明顯的就是專案系統設計的重用問題,無論你是CMM多少級,如果沒有一個統一的軟體架構,重用就會打折扣甚至根本就無法重用。就像南方人北方人溝通要用普通話,今人和古人溝通就必須用相同的文字(順便鄙視並可憐一下朝鮮、韓國和越南)一樣,前後的專案要能夠溝通交流,他們就需要一個相同的結構。所以“程式框架”就是公司專案之間的“普通話”,也是專案內部的“潤滑劑”。

這裡要明確一下“程式框架(Framework)”和“軟體架構(Architecture)”之間的區別,簡單地說,程式框架是一個可以實際應用的程式碼集合,而軟體架構可以看作是一種抽象的設計。另外,兩者的關注面也不一樣,程式框架熱衷於解決實際執行過程中的問題,甚至會提供工具包或者輔助模組(比如許可權系統、日誌系統等),而軟體架構則集中精力在各個部分(模組、元件等)之間的關係。兩者其實是關於同一個事情的不同層次的東西。

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

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

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

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

現在如果要開發一個應用程式框架,至少需要滿足如下的幾個條件:

  • 分層(廢話)
  • 易於測試
  • 易於擴充套件,並跟現有的其他系統進行無縫整合。一般要具有AOP、IOC、DI能力。
  • 易於部署
  • 具有許可權,使用者管理能力
  • 有組織架構、工作流、規則引擎支援
  • 有頁面流轉,狀態管理能力
  • MOF或者MDA能力
  • SOA能力
  • 介面技術的抽象能力(如WebForm,HTML,Ajax,Xml,Rich Web等)

bigtall的應用程式框架設計系列文章準備從簡單開始,一步一步記錄並呈現給大家bigtall開發框架的整個過程。文章列表如下:

  1. 多層應用之間的資料傳遞: 分層和層間資料傳遞(上)、分層和層間資料傳遞(下)
    多層架構已經成為了標準,但是資料在穿越各個層次的時候,它的形態有什麼變化和規律呢?
  2. 介面層的分析和抽象
    介面層承載了應用程式所有的可視部分,究竟裡邊還有多少我們需要關注但是卻忽略了的事實?
  3. MOF/MDA的支援和程式的設計規範
    如果人在根本上是不可靠的,那麼就儘可能不用人去做。但是到達這一步,我們還需要告訴機器一些什麼東西?
  4. 工具!我的工具!
    bigtall設計的小工具
  5. 待續
Tag標籤: 架構