天天看點

軟體開發技術名詞的解密篇(轉載)

序:去年為了總結自己所學習/接觸過的技術,也順便為初學者少走彎路指明一些方向,可惜後來諸事纏身未能繼續,十分遺憾,現放到自己的BLOG上來鼓勵自己将此繼續下去。

"Win32程式設計”

  很不幸,我從開始學習程式設計到了解這個名詞中間隔了很長的時間(上個世紀的學習環境可見一斑)。很長時間裡我都不明白32是指什麼,我用過Dos,Win31,win95,win97...但好像沒用過名為Win32的作業系統啊?很久以後我才知道,32在這裡并不是指作業系統的版本号,而是指32位。微軟作業系統在win31及其以前都是DOS系統,windows隻是在dos下運作的一個大程式而已。在其後win95則稍有改變,windows除了DOS核心以外也真正成為了作業系統的一部分,提供着各類作業系統提供的服務。應該說,在win95之後的windows(新近的64位win系統以前)都可以稱之為win32系統平台(95/98實際上是16與32位混合)。是以在這樣的平台上,直接或間接使用系統提供的API程式設計,就稱之為Win32程式設計。對Visual Studio而言,Win32程式設計一般指SDK、MFC、ATL這幾類開發方法,其中ATL在國内應用不是很廣泛,一般應用于以COM元件為架構的中大型軟體産品。

"SDK" :Software Development Kit,常譯為軟體開發(工具)包

  在Win32程式設計領域一般指與MFC這類架構程式設計相差別的,直接調用Windows提供的API的開發方式,與字面原意有一些差別。另外一個經常見到的說法就是某軟體(硬體)帶有自己的一套SDK,這裡其實一般是指一套API庫函數或者類庫,供上一層的開發者調用。又譬如常說的DX的SDK,其實是微軟開發的一套COM元件,供上層開發者使用。總之,供程式員使用的比較完備的代碼庫,就可以稱之為SDK;

“MFC”: Microsoft Fundation classes 微軟基礎類庫

  大家都知道,使用SDK程式設計方式往往有很多每次都重複的固定不變的一些代碼,為了提高程式設計的效率,減少上千個API帶給開發人員巨大的精神壓力,微軟開發出了這麼一個類庫,注意,這個類庫與作業系統本身無任何關系,它隻是對API進行了一個面向對象的封裝,當然,還給出了一系列程式設計的架構。使用SDK的方法,使用Visual Studio,通過調用Windows API,MFC你也可以做得出來。MFC把一些固定不變的代碼已經寫好了,隻在編譯時候鍊上,是以我們的代碼裡看不到WinMain(),而事實上整個程式的運作,和SDK的方式無任何差別,初學者請記住這一點。另,補充一點個人感想,MFC的初衷,帶給開發人員更多的便利,我覺得并不太成功。學習MFC所費的力氣和最終的所得,并不太成正比。

"API":Application Programming Interface,應用程式接口

  這個詞的出現頻率很高,從某種意義上來說,也可以看作是SDK的一個子集。這也是做給程式員的程式,不過一般指用導出函數的方式提供服務的函數庫,不包括類庫群組件。

“GDI”:Graphic Device Interface,圖形裝置接口

  這個是Win32程式下最常用的顯示方式,與DirectX、OpenGL處于同一級。在DOS要顯示一些東東可不是容易的事,最簡單的是調用一些C的圖形庫函數來實作顯示,不過一般也就是些畫線,填色,輸出幾個文字,效果很弱(是以DOS程式界面一般都不怎麼樣,且實作起來不是一般的複雜),要複雜一點的動畫/圖檔顯示什麼的,經常要用到的就是硬體中斷,調用一些顯示卡自身的子程式(固化在顯示卡内的)來做。因為每一個顯示卡都不同,是以DOS的遊戲相容常常由于顯示卡的差異而很糟糕。到Windows下大家就幸福多了,Windows将硬體這一層屏蔽起來,用一個表格(Device Context)來代表一個顯示,我們要做的就是在這個表格上填好相關參數,然後畫上我們想畫的東東,然後作業系統會依照這個表格(DC),把相應的顯示内容(一般是一塊顯示記憶體)傳送到指定顯示卡的指定的顯存,再由顯示卡傳給顯示屏。我們不再需要與不同的顯示卡打交通,這是一個十分偉大的勝利!GDI中最常用的是雙緩存技術,就是說你可以在記憶體中建立(也就是複制)一個DC,隻不過在這個DC中顯示的不再被傳送到顯示器上。有什麼用呢?因為它的各參數是與目前螢幕DC一緻的(COPY嘛 ,當然是這個結果),是以它的顯示内容可以完整無失真地傳送到螢幕DC上。我們通常在記憶體DC上畫圖,譬如畫一圓,再畫一條直線,畫完後一次性地傳送到螢幕DC上,這樣對使用者來說螢幕隻重新整理了一次,可以解決你畫一點内容螢幕即重新整理一次導緻的閃爍問題。當然,雙緩沖甚至多緩沖還有很多别的用處,那就要靠自己揣摩了。

"DirectX"

  通常簡稱為DX(讀音:低叉)這是個很吸引人眼球的名詞,讀起來就很上口:)。Windows為我們作了許多屏蔽底層硬體的工作,其中DX是最知名的技術之一。作業系統要與各類硬體打交道,特别是多媒體相關的,譬如顯示卡、聲霸卡、搖桿輸入、多媒體流的網絡傳輸等等,這些事情如果都自己來弄的話,那就太要命了(這些一般都涉及系統底層,自己也很難做出來)。而DX則正是這麼一套作業系統提供的隔離多媒體硬體與程式員的間質,DX自身一般并不實作處理的能力,它是一個标準,要求硬體來滿足,好比DX提供一個函數名,硬體來實作函數内容一樣。通過它我們可以非常簡單而快速地調用硬體提供的各類服務。它主要包括DirectDraw(通過直接通路顯示硬體來提供快速的圖象處理能力),DirectSound(提供了軟硬體的低延遲聲音混頻和回放,以及直接通路音頻裝置的能力),DirectPlay (它明确的提供了通用環境連接配接能力來簡化你應用程式之間的通訊服務),Direct3D(DirectDraw的3D版),DirectInput(簡化你的應用程式通路滑鼠、鍵盤和操縱杆裝置的能力),DX5.0之後又增加了一些(如DirectShow),不再詳述。DX一個重要的特點就是你可以通過它直接通路硬體而無需知道硬體的具體細節。譬如DirectDraw,就能夠越過記憶體而直接通路顯存,這樣的速度将比GDI快很多,不在一個數量級上。補充一點:DX是以元件的方式提供的,而不是通常的導出API的形式。DX SDK的最新版本是9.0

"COM”:component object model,元件對象模型,一般簡稱元件

  這是微軟為了解決代碼重用的一個重要機制。重用代碼的最簡單辦法是源代碼重用,把寫好的函數和類加到自己目前的代碼中,編譯即可。簡單是簡單,敝病卻顯然的多。另一個常用的方法是單獨做成子產品,以DLL的形式分發,DLL導出函數或者類,客戶程式用動态/靜态連結的方法将其加載,這顯然比前一種源代碼的方法好一些,難度也不大,最為常用。但DLL也有一些不足,最根本的,它不是二進制相容,DLL版本更新一次就需要與客戶程式代碼重連結一次,有些時候這幾乎是不可能的任務。為了更好地讓程式設計像“搭積木”一樣簡單,讓子產品可以完美地配合,完美地替換,COM産生了。COM不是類庫,不是代碼,不是作業系統的服務,而是一套程式設計模型,理論上來說,它與語言無關,與作業系統無關,unix下同樣可以做COM。COM是一種程式結構模型标準,你做的DLL或EXE在結構上滿足這麼一個标準,那這個DLL或EXE就是一個元件,它将在該平台上成為二進制相容。COM主要利用了系統資料庫來登記本子產品的資訊。客戶程式調用時首先查系統資料庫,找到所需元件的位置(這實作了位置透明),然後就用Loadlibrary把它加載進來,這和普通調用沒有本質差別,差別在于由于元件特殊的實作方法使得整個過程中使用者程式都不知道元件的位置,元件的類的執行個體化過程,如何銷毀,不能直接通路元件的任何實作細節,使用者隻與元件的幾個public接口打交道。這将實作真正的子產品之間的獨立。對使用者程式而言,對于目标元件的認識,除了接口,一無所知。在接口不變的情況下,元件可任 意替換而客戶程式不作任何改動,無需編譯,僅這一點,在中大型程式的子產品內建的過程中就将節約相當多的時間。

 "STL":Standard Template Library,标準模闆庫

  這是最早由Alexander Stepanov和Meng Lee(蠻像中國人的名字)完成,于1994年送出給ANSI/ISO 标準C++委員會并通過而成為标準C++的一部分。望文生義即可知這是一個代碼庫标準,不是文法标準。簡單地說,STL是以C++中的模闆文法為基礎建立起來的一套包含基礎資料結構和算法的代碼庫。STL的特點是實作了“類型參數化”,即STL的代碼中可處理任意自定義類型的對象,如果不使用模闆技術的話,這是一件相當困難的事。也因為這個原因,在最新的java及C#文法中均加入了對模闆文法的支援,可見其重要性。另外一個有關STL重要的話題是GP(Generic Programming),泛型。這是與面向對象相并列的另外的一個程式設計模型,它以模闆為基礎,弱化了實體類型的差異,簡化了程式設計時問題抽象的模型,提供了更好的封裝性和彈性,對于繁雜的面向對象程式設計毫無疑問是一種解脫,至少是精神上的。GP并不是用來取代面向對象的,而是作為一個有益的補充體,是面向對象很好的合作夥伴。GP是最近幾年軟體架構的一個研究熱點,但國内真正的應用似乎并不多見,這項技術本身還基本處于研究前沿。<<Modern C++ Design>>一書對C++中的GP應用有很好的诠釋,而這本書對腦細胞的殺傷力之大,也是其它C++書藉望塵莫及的。想知道C++的代碼技巧可以做到怎樣的出神入化嗎?不妨看看這本書。

"ATL":Active Template Library,活動模闆庫

  這在VC程式設計下應該算是比較進階的話題了,它集COM和模闆技術于一身,帶來了極友善的元件編寫方法和極高的學習門檻。可以說,進入ATL領域就算是進入了中級以上的程式設計領域。ATL是為元件而生,它的目的是為了讓程式員更友善地編寫元件(純用C++寫一個最簡單的元件實作一個“Hello World”對初學者來說都是要命的),同時它使用模闆技術來類似于MFC一樣建立了一個開發COM的架構代碼庫(模闆庫),使用該架構及模闆庫可以相對友善地進行元件開發。ATL中的一個特點就是你自己的類将成為ATL代碼庫中某些類的父類,這是一件很有趣的事(這也是模闆技術的一個特點)。

"HANDLE": 句柄

  這是一個中文翻譯很古怪的字,對初學者來說是百思不得其解的東東。這其實等價于void*(順便提一下,初學者往往對VC代碼中各種古怪的符号、類型标記/宏等百思不得其解,其實它們大多來自基本類型的#define或者typedef,請将光标移到這些符号上(譬如HANDLE),然後按下F12,編譯器自會把你帶到它的聲明處,反複使用幾次,你終會見到它的原貌,然後長籲一口氣:原來不過如此而已。沒用過的初學者請牢記:F12)。很多初學者總想知道一個HANDLE代表一個什麼對象,我的建議是不要去了解為某對象,而就是了解為通路某一個對象的入口,事實上HANDLE大多數時候是一個整數索引(标志該對象在作業系統的某表中的位置,就好像一個數組的下标一樣),Windows系統核心中主要是幾張大表,這樣一個整數索引就是标記目标在這個表中的位置,供作業系統通路時查詢用。偶而它的确是指向某對象的指針,有時它還攜帶一些額外輔助資訊。總之,我們不要去直接通路它,把通路HANDLE的任務交給作業系統好了,除非你還嫌寫程式不累:)。

"DLL": Dynamic Link Library 動态連結庫

  DLL的一個特點就是可以動态加載(顧名思義),即在主程式(我更喜歡稱為客戶程式)需要該子產品時才由作業系統加載到記憶體。畢竟一個大型應用程式我們經常使用到的功能并不多,這樣一些不常用的功能子產品(DLL)在程式運作時一般将不被載入,可極大節省記憶體開銷。DLL同時也是目前最常用的分發子產品的方法,便于彼此協作。程式中對DLL的調用主要有兩種方法:1 針對使用DEF檔案導出函數的DLL,使用API函數LoadLibrary(“DLLModuleName" )加載,然後使用GetProcAddress()得到函數指針,進而調用 2 直接将類、函數等導出,客戶程式使用同一份頭檔案聲明,加入對應的lib連結庫,即可在客戶程式中直接使用DLL中的類或函數,無需LoadLibrary。

"Process": 程序

  程序是一個動态的概念,包括從程序的建立申請,PCB(Process Control Block程序控制塊,一般作業系統實作為一個表格(struct))的建立,位址空間的記憶體配置設定,子產品代碼載入并執行,執行完以後進行撤銷,整個過程被稱為"程序"。在Win32下,一個程序有4G的邏輯空間。但我們也常把它作為靜态概念來使用,在Win32下,一個EXE的執行就是一個程序(如果它内部又開了新程序,另當别論)。

"Thread": 線程

  為了更有效的提高CPU的使用率,更好地實作多任務并發,微軟将程序進行進一步分割,實作了CPU任務排程的新對像:線程。一個程序擁有至少一個線程。我們在實作多任務并發的時候通常是建立一個新線程(建立線程的系統開銷要小于程序),線程以我們自己的一個函數作為入口,函數執行完畢自動撤銷(當然你也可以在執行過程中強制結束該線程)。順便提一下,在UNIX下并沒有線程這個概念,想來是因為UNIX主要是以多程序的并發服務為主(是以它更适合于做伺服器),系統運作時通常已經有了太多的程序,是以沒有必要再對程序進行細化,因為這樣做甚至會降低系統效率(CPU排程不過來),當然,這是我個人的猜想:)

"C語言"

  到目前為止,C語言應該是傳播最為廣泛的語言,特别在UNIX的世界裡依然扮演着主角的位置,在其餘如硬體開發,嵌入式系統(如手機)皆有十分突出的表現,即便在win32平台下SDK的開發中也有一席之地。更主要的是它是大多數國内(國外我不敢說)程式員的啟蒙語言,通過它許多人才領會了程式的思維。C最大的特點就是快,除了彙編以外效率可以達到最高,而它的靈活性,對硬體的直訪性也完全符合程式員自由的天性。如果說學習别的技術尚有猶豫和徘徊,那麼學C隻有一句話:相信我,沒錯的!也有許多人主張可以直接學習面向對象語言,我不太同意。面向對象語言對機器模型的抽象十分容易讓程式員迷糊,心中難以建立準确的程式運作時的模型。畢竟我們是程式員,不是使用者,我們不能把所有的問題都想當然地交給編譯器和作業系統去解決,它們也解決不了。至少學習一門面向過程的語言,才能知其是以然。

C++

  這是貝爾實驗室的又一傑作,同時,也傷透了全球太多程式員的心,腦細胞殺傷力十分之大。C++比大多數初學者想像的都要複雜得多,它基本包括:一個類化了的C語言,模闆,标準模闆庫.很多初學者掌握的C++僅僅隻是一個類化了的C語言的一個子集(不相信的話,你不妨看一看<<Modern C++ Design>>中的C++代碼,看看能了解多少)。更麻煩的是使用C++不得不談到面向對象的程式設計風格,這同樣比初學者想像的難很多,要有打持久戰的準備。而最讓我這類C++愛好者憂心的還是它目前在Win平台中的前景,在.net平台上很難找出不用C#而使用C++寫新代碼的理由:( 。而它的複雜性和目前許多諸如java/C#及一些動态語言(python/ruby)比起來,開發效率顯然的低,大有退出上層應用程式開發的趨勢。這麼一個包含了最多範式的近乎完美的語言,我實在不想放棄。我唯有祈禱在未來C++的路可以走得更遠更好一些。

源代碼版本控制

  這是軟體開發中一個十分重要的工程手段,幾乎是必須的一個Process(過程)。很多作坊式的開發團隊在采用軟體工程的一些方法的時候,第一個要進行改進或增加的,往往就是這個過程。對初學者學習而言,建議在開始進行實踐小項目的階段即進行源代碼版本控制,因為這在以後的工作中,是一定會用到的。  

    源代碼版本控制的基本原理如下:

  在伺服器端建立該項目的資料庫,并儲存你標明的項目源檔案的第一個版本。用戶端任一使用者要獲得某源檔案的修改權利,需進行check out操作。之後用戶端一般每完成一個無編譯錯誤的版本想儲存的時候,進行check in操作,将目前版本儲存在伺服器端上并成為最新版本(注意,不是覆寫以前的喲)。任一用戶端可以友善地得到伺服器上的檔案的任意版本(如果有權限的話)。一般還實作了一個重要的功能是版本比較,任一用戶端可以利用版本控制工具對某檔案的不同版本進行版本比較,它會标記出不同版本的同名檔案的不同點,可以輕易地看出版本内容的演化,這一招很常用。 下面介紹一下我接觸過的三種版本控制工具(也是國内用得比較多的):

  VSS: Visual Sourcesafe

  這是微軟Visual Studio自帶的源代碼版本控制工具,它最大的特點就是易安裝(與Visual Studio內建在一起,裝VC/VB的時候就順便搞定,不用别外費工夫),使用簡單(伺服器端設定相對容易,一般個人稍加摸索就可以輕松搞定,用戶端更是隻管check in/out),基本功能完善,版本比較很直覺(我喜歡)。它的特點是某人check out了某版本以後,别人将無法對此版本check out,也就是說同一時間隻有一個可以修改某一個檔案,這樣就避免了不同的人對同一檔案的修改造成彼此沖突(注:可通過設定伺服器端實作多人check out,但幾乎不會這樣做,因為那樣就失去了VSS的一個最重要的功能)。另,VSS可內建于VS環境,但根據我的經驗,直接在VC裡對版本的check操作,常常不生效,是以最好還是到VSS程式裡去進行check操作。補充:單機上也可以使用VSS,這樣的好處是在對目前某些檔案進行了誤操作或大規模地誤修改之後,可以恢複到最近的無錯誤的版本,最大程度地挽回損失。VSS實際應用較普遍,如果你是走Visual Studio路線的話,一定要用一下。

CVS: Concurrent Versions System

  這個也是一個大名鼎鼎的開源的版本控制工具,主要活躍在UNIX世界。CVS我使用不多,一般而言好像功能比較偏向于指令行方式(UNIX下開發很多人也都使用着指令行方式)。當然,Windows下面也實作了幾個版本的CVS,也可以內建于VS,好像還有一個可以挂接在IE上的,我沒試過。著名的開源項目管理網站sf.net也是用的CVS,如果你要和全世界的程式員一起協作開發,CVS是必須要安裝的。在JAVA的世界裡,也是以CVS為主。

Rational Clearcase

  這個工具就比較上檔次了,Rational公司(現在是IBM)的出品,價格昂貴。我最初參加工作的時候用過一小段時間,簡單談一下。這個工具的特點是複雜,安裝及設定就十分複雜,我的印像中用戶端甚至不得不加入到NT域裡面去,導緻我在本機的權限都不夠,安裝新程式都很麻煩,很郁悶(不知道是不是我們公司的相關人員安裝設定錯了,想來應該是這樣,但其複雜性可見一斑)。對使用而言,它有一個功能挺有用的,就是它能夠根據你每次check的版本号,自動生成版本樹(一個樹狀圖表),你可以清晰地看到版本的演化過程。是以嚴格地說,像CVS/Clearcase這樣的才真正稱得上“版本”控制,VSS還太勉強。Clearcase的功能十分強大,我不詳述了(我還不想出書),較适于大型軟體公司實施軟體配置管理時采用。雖然它的名氣十分之響亮,但我不知道國内有多少公司在真正使用正版的Clearcase這樣的工具,想來應該是十分之少。

OpenGL

  OpenGL至今頗有一點英雄落寞的味道,這一套标準是實作得如此之好,以至于曾經一度成為遊戲界面華麗的标準。它的低落也是一個必然,畢竟在微軟的強力打壓下鮮有不挫敗的。但它曾經能夠給微軟帶來如此的壓力,至今也依然在工業界被廣泛使用,大多數遊戲/顯示卡依然保留着對它的支援(CS裡我喜歡的還是OpenGL)。而它的性能在某些方面與D3D比較,依然占着上風。不幸的是DirectX在不停地向前發展,而它,幾乎止步不前了,前景并不光明。OpenGL目前在工業領域應用較為廣泛,它的優秀的矢量圖的操作性能,華麗的色彩,在專業的圖形圖像處理領域表現突出。遊戲中使用相對以前而言則是越來越少。新近聽說微軟的最新作業系統Vista對OpenGL進行了極大的打壓,不但性能上折扣,支援的版本也隻到1.4(最新版本好像是2.0),不知道最後如何收場,拭目以待。

DirectDraw & D3D

  大凡像樣的2維Windows遊戲,幾乎都是采用此技術來實作顯示的。DirectDraw有兩種模式:全屏和視窗。其中全屏應用更多一些。在全屏下,DirectDraw有一個十分著名的“換頁”技術,即在兩個顯示頁面之間用“交換”來實作顯示重新整理,這個速度十分地快,隻是一個顯存内一個指針的交換,比你用BitBlt複制一屏的像素快太多太多,遊戲的高效的動畫效果大多源于此技術。

DirectDraw主要用于娛樂領域和一些實時顯示要求較高的場合,如醫療圖像。D3D是目前大多三維遊戲的标準采用,我沒鑽研過,不敢多言。它的效果嘛,玩玩遊戲就知道了:)

UML:Unified Modeling Language,多譯為統一模組化語言

  這個語言是一種圖形語言,主要是作為設計時模組化的一種标準的圖形模型,便于程式員與程式員、程式員與客戶、設計員與代碼員之間的溝通,同時它也幫助設計人員将頭腦中的基于程式代碼的對程式功能的了解形成文檔,便于理清頭緒,進行下一步編碼的工作。換言之,設計過程的産品,可以表現為一些文本文檔,或者一些架構代碼,或者一些僞代碼,但比較标準通用的,是表現為一堆UML圖。UML包括動态圖和靜态圖兩大類,其中靜态圖中的類圖最為常用。很多人初學時不知道該怎麼做設計,寫小軟體時常常沒有設計過程,其實很簡單,把軟體的類圖畫出來就好了。學做設計時未必要找一個像Together或者Rational Rose一樣的巨無霸。用一些簡單的可以做UML圖的工具就好,專門用來畫UML圖的小工具很多,網上容易找。補充一點:畫UML圖不要面面俱到,不要什麼都畫,突出重點友善了解就好,甚至使用不規範的記号也不要緊(當UML的功能是草稿的時候)。

RTTI: Runtime Type Information 運作時類型資訊

  在程式中,當我們得到某一個對象的執行個體或者指針時,大多數時候并不能直接肯定它的類型(都是繼承以及類型轉換惹的禍),這個時候,依靠VC4.0或更高版本的編譯器提供的RTTI支援,調用庫函數typeid()即可在運作時擷取這個對象的“類型資訊”,在一些動态進行中“類型資訊”很重要,擷取了類型資訊以後,你就可以有十分把握地調用該類型的相關操作,或者類型轉換,或動态生成。因其重要性,在JAVA和.net庫中借助單根繼承和“虛拟機”對此有了更優雅的做法,每一個自object繼承的類天然就有了表述自己類型資訊的能力(繼承的好處),并且容易擴充,現在你需要類型資訊的時候,大可直接ask那個對象:tell me, what type are you?它就會告訴你答案。

debug & release 調試 & 發行

  大家都知道,debug是調試版,release是發行版,差別在于debug版生成的程式中包含大量供調試用的場景代碼(不是真正運作需要的),而release一般去掉了這些資訊,并進行了某些代碼優化,是以release版的程式會比debug版的程式小很多,運作速度也快一些。同時,debug版為了便于調試,往往會對調試使用的診斷代碼加上DEBUG一類的宏,使得在release下不對這些代碼進行編譯。正由于兩種版本編譯使用的源代碼的差異(以及release糟糕的優化),常常使得兩種版本運作時産生截然不同的效果,一個正常一個崩潰是大多數人都遇到過的。導緻問題的可能性很多,注意事項詳見各論壇的諸多精華貼。另,同一個程式如果DLL之間的連結使用了不同版本(譬如EXE是release版,dll是debug版),有時會無法正常運作,是以我一般的做法是每一個DLL針對不同版本使用兩個DEF檔案,編譯生成不同名的兩個檔案(debug版檔案名後加d),調用時各個版本針對自己的版本調用,這在一定程度上可避免混亂。另,release也是可調試的,在工程設定裡把調試資訊打開即可。

XP:eXtreme Programming 極限程式設計

  這是近幾年才時興起來的開發模型,國内大緻是01/02年開始有所宣傳。

  它主要是針對中小型開發團隊在開發時間要求緊、需求不穩定的中小項目(大多數軟體項目都是這個情況)時使用。它打破了傳統軟體工程的架構,非常新巧。譬如整個開發過程中文檔很少,大量使用“卡片 (如CRC卡片)”來描述開發計劃和内容;沒有真正意義上的軟體功能規格說明書,取而代之的是一系列可測試的用例;沒有獨立的設計和測試階段,它們總是在疊代中增量反複進行;設計:盡可能小和簡單;一般沒有代碼複審(code review),大家共同擁有代碼。而它的最顯著的一個外在特征是它常使用“成對開發”,即一台機器前坐兩個開發人員,共同開發(一個看,一個寫),這乍聽起來真是蠻有趣的:),它的基本出發點是認為成對開發的效率在一定條件下要高于兩個人獨立開發的和。不要覺得天方夜譚,在很多項目中,這種做法的有效性已經被證明。

  XP的特點可以用“快、小、靈”來概括,它和傳統瀑布模型(自頂向下)的差別在于它使用疊代增量(設計->代碼->測試->設計->代碼...)的方式。想法很簡單:沒有什麼目标是可以一開始就容易确定的。用爬山來做一下比喻的話,傳統的是在山下研究地圖,選好一條路線,然後沿着此路前進,XP則是走一走,停一停,看一看,對下一步的方向作出新的選擇,在很多時候,這樣做會讓你選擇到更好的捷徑。

ICONIX:

  這個字相信很多人都沒見過,我也不知道是什麼字拼起來的,作為開拓眼界,我還是提一下吧。這是一種界于XP和RUP(Rational Unified Process)之間的開發模型,換言之,它比XP“大”,比“RUP”要小。它采用了UML的一個子集,特點是用例驅動,保持良好的進度跟蹤能力。它的目标是用最短的時間來把用例變成代碼。具體來說,這種開發模型相對精簡的XP而言,更加強調用例的建立、分析和代碼化,用例是其中心地位。

RUP:Rational Unified Process

  前面已經提到了,相信你已經感覺出它是一個豐富的軟體開發模型。這是由IBM提出來的軟體工程模型,它使用完整的UML圖,對開發的各階段(需求、設計、代碼、測試、維護)均有十分完善而複雜的标準,就不詳述了。RUP本質上是疊代式開發,在每一次疊代中均完成以下四個階段:初始階段(inception)、詳述階段(elaboration)、建構階段(construction)、轉換階段(transition)。

CMM:Capability Maturity Model 軟體成熟度模型

  這是卡内基*梅隆大學軟體工程研究所(我的專業正是軟體工程,是以這也成為我心目中的聖地)的一大力作,一度曾形成了席卷全球軟體開發的CMM浪潮。CMM分為五級,大多數軟體企業都處于第一級,而得到第五級認證的全球也沒有多少,國内去除掉挂羊頭賣狗肉的,也是寥若星辰(嗯,比星辰是寥多了)。是以CMM實施一般是從第二級開始,能做到第三級的都是頗有實力的軟體公司了。CMM是以Process(過程)為中心的模型,從二級始每一級都有幾個Key Process(關鍵過程),每一個KP又分為若幹Key Active(關鍵活動)。CMM的實施一般不能越級實施,并且每一級的實施通常都要一年以上,是以要達到較高等級是一級很困難的事。另,CMM不僅可用于較大規模公司,同樣也可實施于小公司,小項目組(這是很多人所不知道的)。實施視具體情況等級之間可交叉,譬如實施時采用二級的某些KP再加上三級甚至四級的KP,但你隻有實施了所有二級的KP,你才能也隻能通過二級認證,即便你采用了某些四級的KP。CMM最新發展成果是CMMI(Integration),這主要是新考慮了軟體與非純軟體因素的關系(譬如系統),以及團隊之間的協作問題。CMM在國内的發展似乎有點走向ISO同樣的道路,這實在不是一個好消息。

Callback Function: 回調函數

  在侯sir的<<深入淺出>>中一開始就提出了這個概念,大概的提法是說回調函數是作業系統調用而你永遠不要去調用的函數。這個提法讓初學者有點望而生畏,以為是一種多麼高深而難以領會的系統底層的核心技術。其實不然,這個技術本質很簡單,而且很常用。它實質就是函數指針的基本運用(如果不知道什麼是函數指針的話,翻翻書)。在一個子產品中,有時想讓一部分功能由其它子產品實作,譬如說一個做顯示的子產品,它隻想實作顯示的資源配備,畫面的重新整理,縮放等控制功能,而把畫具體實體(譬如圓、多邊形,都可以有很多種不同效率的實作方法)的代碼由别的子產品來實作,怎麼辦呢?用函數指針。在自己的類中放一個畫圓的函數指針,使用時由外部為這個函數指針指派(其實就是指向了一個外部的函數),在自己的代碼中直接調用這個函數指針來畫就可以了(本子產品完全不知道外部子產品是怎麼畫圓的)。那個外部的函數在這裡就是回調函數!

  在很多系統API中就使用了這種函數回調的方法,讓我們開發的代碼實作可以嵌入到API的代碼實作當中,其實我們就是傳了一個函數位址給它而已。換句話說,這些API搭好了某些運作的代碼架構,我們來為它具體實作。

XML: Extensible Markup Language 可擴充标記語言

  也許你還在為選擇.net和j2ee而徘徊不前,如果是這樣的話,不妨先着手學一下它們所共通的一個基礎:XML。有了HTML為什麼我們還要XML?很簡單,HTML重在表現文本/圖檔以及一些多媒體内容,它很難表達資料,因為它的标記是固定的,而資料類型千千萬,根本無法描述。.net和j2ee都要解決一個資訊傳輸格式标準化的難題,這個格式要能承載文本/資料,最好還能描述程式接口,同時又應該像HTML一樣簡單,具有通用性,能夠在HTTP下很好的運作。在這種要求下,XML産生了。它的特點正如其名,和HTTP一樣,它也是一種标記語言,但是它的标記不是固定的,是可自定義(也就可無限擴充)的,這些自定義标記能夠很好的描述資料類型以及對應的資料内容(乍看起來很像資料庫表的定義)。除此以外,XML還可以描述程式接口,是以XML可以友善地與網絡程式構件(COM、EJB等)直接互動。由于它也是一種ASCII文本流,是以與目前的HTTP相容,在目前的internet上暢通無阻(這很重要)。有了以上功能,XML就名副其實地成為了新一代網際網路技術的标準資訊載體,在.net和j2ee的網絡架構中,各種“構件”的資訊互動都交給了XML,可謂任重而道遠。

  XML我自己沒怎麼寫過,單就學習上的經驗而言,感覺文法上比HTML更瑣碎一些,小細節更多,沒那麼容易速成:) 好在根本同源,有HTML基礎甚至WEB開發基礎的,學起來也很輕松。

Java2:

  這是近幾年最吸引大衆焦點的語言,在Web開發,網絡平台,移動開發的世界裡發光發熱。你可以不用java,但你不可以不了解java,畢竟這是一個極大且豐富的軟體開發領域。有些沒使用過java的VS陣營裡的人可能還不明白java2裡的那個2是什麼意思,容我先解釋一下。Java最初正式推出1.0時,并沒有受到如此多的好評,受到頗多責難,于是它不斷地推出新版本來完善自己,其中變化顯著的一個版本是1.2(我沒記錯吧),Java的每一個新版本除了文法上的更新,還有一明顯的标志,那就是JDK(Java Development Kit,就是Java自帶的一套SDK)的更新,版本1.2以後的java為了在宣傳上與以前的java相差別,便被稱為java2。目前用得比較多的jdk是1.3/1.4 ,最新的JDK是1.5(代号tiger)。java開發的IDE國内主要以JBuilder為主,另外就是在開源領域如雷貫耳的Eclipse,而sun也力推自己的開源java IDE:Netbeans(從sun的網站上可下載下傳,免費)。Java運作是虛拟機機制,相當于在作業系統上增加了一個軟作業系統,源碼被編譯成一種位元組中間碼,由虛拟機解釋執行,隻要有對應的虛拟機,java程式就可以在該作業系統上運作,這就是java号稱的一次編譯,到處運作的由來。而附帶而來的不可避免的性能問題也讓Java難以成為桌面程式開發的主流。補充一下:對初學者學習而言最好的Java IDE我推薦使用JCreator,這是一個C++寫成的IDE,幾MB的大小,比Eclipse快十倍以上的啟動速度,對初學者帶來極大的便利。

J2EE:

  Java實際上又被分為3類:J2EE/J2SE/J2ME,不同類分别對應不同的JDK,J2EE針對企業平台開發,J2SE是标準版,J2ME針對移動平台開發。J2EE現在實在是熱得燙手,我前不久翻了一下程式員早期的雜志,發現在第一期創刊号裡(2001.1)已經有了j2EE方面的讨論,現在已經是2004.6了,你對它的認知又多了多少?J2EE不是一種單純的技術,而是一種體系架構以及組成該架構的諸多标準。企業平台開發和桌面/簡單Web資料庫開發有很大的不同,它的程式規模往往很大(不是一個或者幾個EXE可以搞定的),用到的往往是海量的資料庫和海量的通信,并且常常是不可中斷的,這些特殊性都使得企業平台開發更多地去關注架構的問題。而我們寫一個熟悉的java用戶端程式,或者消息進行中間件,又或者資料庫處理程式,都隻是這樣一個架構裡的一小部分。J2EE是很寵大的,是以請不要寫了幾個EJB(這是java世界裡的構件,概念上大概是類似于COM)的例子程式就感覺自己精通j2EE。

  J2EE中傳遞消息時往往引入了一個被稱作消息管理器的中間件,在伺服器端使用EJB的容器來管理和調用EJB。在J2EE中一個重要的概念是Transaction(事務)處理,事務的概念最早廣泛應用于資料庫技術。這實際上是一個封裝了很多操作的單元,它的作用是中間任何一個操作失敗,可以自動依次整體撤銷,是以一個transaction就是操作成功/失敗的最小單元,不存在一個transaction隻成功了部分操作的情況。

在企業服務平台開發中比較知名的有一個叫BEA公司(這是一家不錯的公司,應該知道它的名字),它的産品是Weblogic。

.net

  .net是微軟為下一個十年準備的技術,你呢?.net也是一種平台技術,而不是單一技術。它主要分為.net運作時平台(對應java的虛拟機)和.net類庫(對應java的jdk)。目前隻有Windows2003是天然內建了.net運作時平台的作業系統,是以如是你寫的.net程式想要在别的作業系統上運作,該作業系統必須先安裝.net平台,這是一件蠻煩人的事,也是為什麼到目前為止,還沒有太多的人改用.net來寫程式(盡管可極大提高開發效率)。希望Longhorn的出現可以扭轉這一現狀。那我們就終于可以和MFC這樣過時的架構類庫說再見了,一大快事。

.net采用了很多最新的技術和思想,對走VS路線的人來說(特别是有COM概念的),學起來相對輕松且很過瘾,前人推薦的“.net架構程式設計“和”.net本質論“都是很好的書。當然,看它們之前你最好基本掌握一門.net語言,譬如C#,掌握語言對我們來說是最easy的。