尋找時光機器，開發人員的時光機器!

我非常喜歡Guy Pearce和Jeremy Irons主演的『時光機器(The Time Machine)』這部電影，雖然我已經看過這部片子很多次了，但每當HBO重播這部片子時我都會禁不住的停下來好好的看看這部連劇情都可以倒背如流的電影。對於這部電影我並不特別喜歡其中的動作場景，而會讓我每次都願意再看一次的原因卻是Jeremy對Guy解釋為什麼Guy無法藉由時光機器改變過去的原因以及這部片子結尾時2個不同時空並現的畫面，那給我一種無法敘述的震撼，80萬年是那麼遙遠的時空距離，但它們又同時那麼真實的存在，每次我看到這裡都會問自己如果我也擁有Guy發明的時光機器我會用它做什麼?

人們通常藉由老歌，照片，景像和許久不見卻突然乍現的朋友而回想到過去的種種。其實我想每個人都擁有時光機器，它早已存在於每個人的記憶之中，只是年輕時你不曾注意到它的存在，當時光逐漸飛逝之後你終於發現它早在那兒等待著你，你不會記得你第1次是何時坐上它進行了你生平第一次回到從前的時光之旅，但是你絕對會注意到當你的年齡愈來愈大之後你坐上它進行時光之旅的次數卻愈來愈多，每次在你不自覺的坐上它之際，你使用它的時間也愈來愈長，最後你甚至會捨不得把它停下來。只是這個記憶時光機器有一個缺點，那就是它的時光之旅似乎種是模模糊糊的，只有少種的旅程會讓你擁有非常清晰的回憶，而大部份的旅程總是只有大略的景像，例如即使下次當你坐上它進行時光之旅時，你可能也記不得10年前的這一刻你在做什麼。

開發人員也許不太富有(一笑)，但是開發人員卻擁有一項特權，那就是開發人員擁有另外一個更為明確的時光機器，它就存在於我們寫過的程式碼中(啊，除非您從沒寫過Code，呵呵)。結合我們每個人都擁有的記憶時光機器和開發人員特有的時光機器，那麼它們可以精確的帶領你回到特定的時間點。例如當我翻出我古早仍在使用C/C++程式語言保留的程式碼時:

{*******************************************************}

{程式師 : 李維 }

{日期 : 1993, 12, 22

{程式名稱 : XXXX… }

{系統名稱 : XXXX…}

{程式說明 : XXXX…}

{程式歷史 : 1993, 12, 22 09:30 開始撰寫….}

{程式歷史 : 1993, 12, 22 30:30 分析改變資料庫綱要，因此….}

….

{*******************************************************}

#include “stdio.h”

…

void main(…)

…

我便突然登上了我的時光機器，回到了那時仍然是菜鳥程式師的我，我立刻的記起了那天我在寫的程式，我的同事，我甚至可以回想起那天中午我吃了什麼以及午睡時留了酣睡的口水(因為那時太累了，白天上班晚上得帶小孩)。呵呵，當然如果你想讓你的開發人員時光機器能夠精確的運作，那麼你必須在以前就養成良好的習慣，在你的程式中留下時光的足跡。

當我如觸電般藉由我的時光機器回到以前進行時光之旅回之後，我也在咀嚼和回味當時讓我困惑的如何設計類別的問題現在是不是已經惑然開朗了，如果是的話那麼代表我比以前進步了，如果沒有的話就代表這些年來我仍然在愕愕然然的混日子，不求長進。還好我得到的答案是那些曾經讓我困惑的問題現在幾乎都已經瞭然於胸了。

為什麼我會寫上面的感想? 這是因為我上一篇文章『程式語言，風格和技術之旅』中寫的內容以及一位網友的評論而觸發的，而且湊巧的是也和我想寫的DBX4技術有關。

在『程式語言，風格和技術之旅』中我寫了資料存取技術改變的原因，以及為什麼會有這些多不同的資料存取技術。dbExpress從1.0演進到DBX4的期間也正好面臨了兩個非常重要的關鍵期，第一個關鍵期是當時Borland在BDE之後急需一個能夠跨平台的資料存取技術，因為Delphi要在Linux平台上推出版本，這造就了dbExpress的出現。第二個關鍵期是.NET平台的出現，Borland不但需要一個一個能夠跨平台的資料存取技術，也需要一個能夠在.NET平台上根據ADO.NET規範實作的資料存取技術，造就了dbExpress的衍生.NET版本BDP的出現。2006年第三個關鍵期出現了，那就是原生Win64平台的考量。2006年的dbExpress 3.x當時的情形是Delphi的資料庫開發小組維護了太多不同的資料庫的dbExpress驅動程式，在Win32下dbExpress有6,7個不同資料庫的驅動程式，在.NET下也有相同數目的BDP驅動程式。而MS又改變了ADO.NET的架構，ADO.NET 1.x和ADO.NET 2.0使用的架構是不同的，難不成Delphi的資料庫開發小組得再重新開發一套符合ADO.NET 2.0規範的BDP驅動程式? 再接著開發一套Win64的dbExpress驅動程式? 那Delphi的資料庫開發小組的工作將是多麼困難?

因此當Steve回到CodeGear並且成為Delphi的資料庫開發小組的主要架構師之後，他必須苦思如何解決這個複雜的問題，而且他的解決方法還必須和現在的dbExpress相容，必須能讓開發人員在使用相同的dbExpress元件條件下，於Win32，.NET ADO.NET 2.0和未來的Win64都能夠使用單一的dbExpress原始程式，如果您是Steve的話，那麼您要如何解決?

這個問題相當的龐大，要在一篇文章中說明所有的技術事項有點辛苦(啊，我也沒那麼多時間一次寫完)，為了讓各位瞭解其中的一項困難，讓我們以ADO.NET 1.x和ADO.NET 2.0的架構來簡單的說明一下。

BDP在當時是根據ADO.NET
1.x規範開發的並且加入了一些當ADO.NET 1.x沒有的功能(現在這些功能ADO.NET已經加上去了)。ADO.NET 1.x當時有兩種不同的實作和使用機制，因此像BDP只需要實作ADO.NET 1.x規範的父類別並且把功能藉由介面提供出來即可。例如下表就是ADO.NET
1.x的父類別以及介面:

Provider-specific classes and generic
interfaces in ADO.NET 1.0/1.1

SqlClient class	Oracle class	Generic interface
SqlConnection	OracleConnection	IDbConnection
SqlCommand	OracleCommand	IDbCommand
SqlDataReader	OracleDataReader	IDataReader/IDataRecord
SqlTransaction	OracleTransaction	IDbTransaction
SqlParameter	OracleParameter	IDbDataParameter
SqlParameterCollection	OracleParameterCollection	IDataParameterCollection
SqlDataAdapter	OracleDataAdapter	IDbDataAdapter

因此BDP就以介面輸出它提供的服務和功能，開發人員也應該藉由介面來使用BDP這個根據ADO.NET 1.x規範實作的Provider。如此一來就可以保護開發人員的程式碼，不管開發人員稍後是不是使用了不同的資料庫，只要使用介面實作父類別的驅動程式是可以自由改變的。

不幸的是ADO.NET 2.0改變了這個規則，在ADO.NET 2.0中走回抽象父類別的架構，所有的資料存取類別都必須從ADO.NET 2.0的抽象父類別繼承下來並且實作，而且不再使用介面的方式，這意謂程式碼必須直接使用類別物件的方式來使用ADO.NET 2.0的服務，那麼程式碼如何得到特定Provider的資料類別物件而不是抽象父類別的樣例呢?因此在ADO.NET 2.0中就提供了DbProviderFactory來讓用戶端程式碼取得正確的衍生類別樣例。而在ADO.NET 2.0中只保留ADO.NET 1.x的介面做為相容目的而已，ADO.NET 2.0確定走向抽象父類別/DbProviderFactory的模式，例如下面的表格是ADO.NET 2.0的抽象父類別和相容於ADO.NET 1.x的介面:

Generic base classes and Generic interfaces
in ADO.NET 2.0

SqlClient class	Base class	Generic interface
SqlConnection	DbConnection	IDbConnection
SqlCommand	DbCommand	IDbCommand
SqlDataReader	DbDataReader	IDataReader/IDataRecord
SqlTransaction	DbTransaction	IDbTransaction
SqlParameter	DbParameter	IDbDataParameter
SqlParameterCollection	DbParameterCollection	IDataParameterCollection
SqlDataAdapter	DbDataAdapter*	IDbDataAdapter
SqlCommandBuilder	DbCommandBuilder
SqlConnectionStringBuilder	DbConnectionStringBuilder
SqlPermission	DBDataPermission*

 

OK，ADO.NET 1.x和ADO.NET 2.0的架構是如此的不同(雖然都叫ADO.NET)，那麼對於dbExpress和BDP怎麼辦? 如果你是Steve又怎麼辦?

先再想想Steve的工作目標?一套資料存取技術架構可以適合在Win32，Win64和.NET平台。如果根據ADO.NET 2.0的規範來改變dbExpress架構，那麼會有許多問題。首先ADO.NET不是原生Window資料存取技術，二是考慮ADO.NET 2.0回頭使用抽象父類別架構到底好不好?

使用抽象父類別架構對於MS是好的，因為MS可以任意在抽象父類別中加入任何新的方法，因為ADO.NET的規範是由MS定義的。但是對於其他實作ADO.NET Provider的廠商來說是不好的，因為這代表如果從抽象父類別衍生子類別並且加入新的方法的話，那麼如果稍後ADO.NET又在抽象父類別中加入了相同名稱的方法那麼就完了，如此一來其他實作ADO.NET
Provider的廠商必須立刻改變衍生類別的宣告和實作，重新部署等。對於開發人員來說使用介面也比使用抽象父類別樣例變數來得安全，因為介面代表契約，契約不能改變但是抽象父類別的定義卻可能改變。

因此對於DBX4來說由於dbExpress已經推出好多年了，有大量的使用者，如果採用ADO.NET 2.0的方式是很危險的，不然就得為ADO.NET 2.0獨立的寫一套Provider，這又和一套資料存取技術架構可以適合在Win32，Win64和.NET平台的目標不合。那麼應該怎麼辦呢?

其實答案很簡單，那就是忘了ADO.NET 2.0，讓DBX4擁有自己革新又相容於dbExpress的架構，並且可以執行在Win32和Win64平台。那麼ADO.NET 2.0呢?很簡單，使用Adapter設計樣例。那就是遵照ADO.NET 2.0的規範使用抽象父類別/DbProviderFactory的模式，但是只在.NET平台撰寫一個輕量級的ADO.NET 2.0 Bridge Provider，這就是DBX4中的ADODBXBridge Provider。這個Bridge
Provider接受.NET 2.0應用程式對於ADO.NET 2.0的呼叫，然後藉由PInvoke呼叫到DBX4的原生驅動程式。如此一來不但可以讓DBX4在不受ADO.NET 2.0或是未來ADO..NET 3.x/4.x的影響下於三個平台提供更先進的功能，更重要的是如果未來ADO.NET的抽象父類別中定義了和DBX4相同名稱的方法，那麼Steve只要修改ADODBXBridge Provider中的程式碼即可，不需要改變DBX4，這不是很好嗎?

現在您應該瞭解了ADODBXBridge設計的背後原因和它的目的了。我建議對DBX4有興趣的朋友再回頭去看看BDS目錄下的DBX4架構圖。

剛才說的如何整合DBX4和ADO.NET 2.0只是DBX4聰明架構的一部份，當我們以後說明更多DBX4的設計架構，觀念和想法之後，你會發覺到更多有趣的事情，技術和取捨，從其中如果你細細思量也更會體會一個技術架構師的背景，價值和思考邏輯，這其實是我最有興趣的一環。

我們下次再繼續討論吧，不過我不敢保證還是DBX4，也許是ECO IV，看我的心情和靈感啦，我們下次見。

CodeGear RAD Studio 2007 產品發表會，9月11日起，北中南三地隆重豋場

Highlander 9月就會在台灣進行發表會, 歡迎各位一起來看看Delphi.NET泛型功能, ASP.NET 2.0, ECO IV, BlackfishSQL, DBX4等新功能.詳情請參考下面的URL:

http://www.borlandpresents.com/edm/delphi_techday07/taiwan/

程式語言，風格和技術之旅

使用過dbExpress了嗎? 我想有很多人正在使用dbExpress，但一定也有很多人仍然在使用BDE，ADO，或是正苦於不知選擇什麼資料存取技術。我可以瞭解改變資料存取技術的痛苦，因為我也寫過專案和產品，不過每隔數年存取技術便會有重大的改變似乎是不可避免的事情，從BDE，Jet Engine，ODBC到比較新的ADO，dbExpress和ADO.NET等。但是為什麼一定需要每隔數年便需要改變一次資料存取技術呢? 通常這有數個原因，讓我們撇開因為銷售/行銷的因素之外，最主要的原因應該是客戶存取資料的模式改變了，因而造成了原有的資料存取技術已經不適用了。例如BDE/ODBC都是為了當時桌面型(Desktop)或是C/S架構設計的資料存取技術，一旦人們需要在分散式環境以及Web上使用時這些資料存取技術的架構便不足以使用了。

另外一個原因則是使用架構，客戶端程式語言和設計上的考量和需求之故。例如以前的資料存取技術驅動程式大都是使用C程式語言撰寫的，BDE/ODBC等都是。這主要的原因除了效率之外，彼時使用這些驅動程式的程式語言也大都是程序程式語言，例如C，Pascal和VB等。由於驅動程式本身以及用戶端程式語言都是程序性程式語言，因此這並沒有什麼問題。而為了讓高階程式語言能夠使用用C撰寫的驅動程式，因此這些C驅動程式大都是使用直列式的Export程序讓用戶端程式語言呼叫，而這種設計方式也讓這些Export出來的程序在API接受的參數型態上大都使用通用Pointer，Smart Pointer等，到了C驅動程式之後再由C驅動程式進行正確的指標轉換為，資料型態轉換等工作。

這一切都運作的不錯，但是當用戶端的程式語言逐漸由物件導向程式語言主導之後事情就有所不同了。新的資料存取技術必須能夠和用戶端的物件導向程式語言合作的更好，最好是改變以往使用直列式的Export程序並且直接使用指標的方式，因為有一些物件導向程式語言根本沒有指標的機制或是觀念。此外以往使用直列式的Export程序的方法也存在許多的問題，例如如果驅動程式的功能增加了而增加直列式的Export程序的數量，那麼由於輸出程序的進入點位址改變而造成用戶端應用程式的錯誤，因此必須重新連結和部署新的驅動程式。

以上說的兩個因素就是客戶端程式語言和設計上的考量。因此新一代的驅動程式開始直接使用物件導向程式語言來撰寫，例如Java，C#和Delphi，為什麼? 因為這樣一來驅動程式便能夠和用戶端程式語言有更好的契合。

另外如果驅動程式的設計架構能夠使用最新的設計樣例來設計而不是只使用直列式的Export程序的方式，那麼也可以解決不同的資料庫，不同的驅動程式架構或是新功能的加入而必須讓驅動程式和所有應用程式需要重新連結，部署的問題了。

為什麼我要說這些呢?這主要是因為我在上篇文章中最後說到的有趣經驗『從程式碼和架構閱讀背後開發人員的特性』。在Highlander的Beta測試期間我對DBX4和ECO IV最有興趣。因為從DBX4的發展我看到了CodeGear這次在資料存取技術的決心，DBX4勢必將成Delphi，BCB和RRAD
Studio唯一且最好的資料存取技術。這也可以從DBX4自BDS 2006以來快速的進步看出來。在Highlander中DBX4更進一步的推出了桌面型存取，分散式存取的架構，這個意思是說Highlander中的DBX4不但允許開發人員使用DBX4開發桌面型應用程式，C/S應用程式，更可以發展分散式和Web應用程式。

例如為了讓開發人員能夠使用Highlander中的BlackfishSQL，Highlander中的DBX4提供了DBXClient程式單元，讓Win32的Delphi，BCB能夠藉由DBXClient連結BlackfishSQL。由於Highlander提供了DBXClient程式單元完整的原始程式，這代表Win32的Delphi，BCB開發人員可以直接連結DBXClient程式單元到EXE中，最後只需要部署一個EXE就可以提供桌面型應用程式，C/S應用程式或是分散式資料庫應用程式，這實在太酷了。DBX4我準備下一次再詳細的討論，現在讓我們回到本篇文章的主題『程式語言，風格和技術之旅』。

我為了瞭解DBXClient是如何能夠讓Delphi/BCB的開發人員能夠在相同的dbExpress架構，藉由使用原本的dbExpress元件組之下就能夠神奇的存取純.NET資料庫BlackfishSQL，因此我一直追蹤著DBXClient相關的原始程式以及它如何與原本VCL框架中的dbExpress類別整合，這實在很有趣，特別是當Steve成為CodeGear資料存取技術的Architect之後，我可以明顯的感覺到dbExpress的改變以及DBX4的誕生。更重要的是我在閱讀這些原始程式時得到的樂趣。我知道Highlander還沒有出來，我也不知道有多少人有我這種痞好喜歡不時的閱讀原始程式碼，為了讓各位感覺一下以前的dbExpress架構和所謂直列式的Export程序寫法，在下面我列出了Delphi 7時TSQLConnection元件在連結資料庫時呼叫的DoConnect方法:

001   
procedure TSQLConnection.DoConnect;

002    var

003     
Status: SQLResult;

004     
LoginParams: TStrings;

005     
PropSize: SmallInt;

006     
TrimmedUserName: string;

007    begin

008     
CheckLoginParams;

009     
ConnectionState := csStateConnecting;

010     
LoadSQLDll;

011     
LoginParams := TStringList.Create;

012      try

013       
SetCursor(HourGlassCursor);

014        Status :=
getDriver(PChar(FVendorLib), PChar(Trim(FParams.Values[ERROR_RESOURCE_KEY])),
FSQLDriver);

015        if
Status <> SQL_SUCCESS then

016         
DataBaseErrorFmt(sDLLLoadError, [FVendorLib]);

017      …

從上面的程式碼中各位查覺到什麼沒有? 沒有的話沒關係，讓我們討論一下。請注意上面程式碼的第14行，TSQLConnection.DoConnect開始呼叫getDriver取得連結特定資料庫的驅動程式並且進行連結。現在查覺到什麼沒有?還沒嗎?

其實014行已經透露出它即將呼叫一個由C撰寫的函式，為什麼? 一看PChar出現進行指標型態轉換就可略知一二了。繼續查查GetDriver，它有下面的宣告:

  GetDriver:
function(SVendorLib, SResourceFile: PChar; out Obj): SQLResult; stdcall;

  DllHandle:
THandle;

 一看這種宣告便知道GetDriver是一個由C撰寫的DLL輸出的函式，這C1的DLL驅動程式便是由TSQLConnection.DoConnect在010行LoadSQLDll動態載入的。因此從上面簡單的討論和觀察中我們可以得知下面的結果:

1.        
以往的dbExpress驅動程式是使用C/C++撰寫的驅動程式

2.        
C/C++撰寫的驅動程式使用指標，型態轉換等技術來實作

3.        
C/C++撰寫的驅動程式使用直列式的Export程序以便讓物件導向的Delphi/Object Pascal來呼叫

另外一個非常重要的觀察結果就是我們從這麼少的片斷程式碼就可以知道dbExpress許多和組態，架構相關的實作都是由C/C++撰寫的驅動程式一手包辦，這意謂如果我們需要為dbExpress增加新的功能，例如Pooling，或是新的應用架構，例如分散式架構，那麼一定得去改C/C++撰寫的驅動程式原始程式，但是C/C++撰寫的驅動程式通常不會把原始程式放出來，因此它是一個黑盒子。

 

那麼讓我們猜猜設計和實作這樣的工程師的背景是什麼? 對啦前任dbExpress架構師Ramesh是C/C++的背景，大部份的時間都使用C/C++，因此自然的在設計和實作dbExpress時就是使用C/C++的技術，想法和觀念。這是工程師養成的背景因素。此外如果各位有機會仔細看看以往dbExpress在VCL框架中的實作程式碼，如果你有C的經驗，那麼您可能會發現許多地方程式碼的寫法和C的味道很接近，簡單的說Ramesh是使用Delphi的語法但是卻使用他最熟悉的C的味道在寫程式碼。

那麼在Highlander中呢? 嗯，現在dbExpress架構師是Steve，他是我最近最注意的R&D工程師，因為他非常的有創意，而且能夠實作出來。DBX4是他的構思和實作，BlackfishSQL也是，未來他有更酷的技術要實作出來。在那之前，我讓各位看看Highlander中相同的TSQLConnection.DoConnect片斷程式碼，仔細看看各位又查覺到了什麼? 從這些程式碼中您可以推斷出Steve的技術背景嗎?

001   
procedure TSQLConnection.DoConnect;

002    var

003      …

004    begin

005      …

006     
ConnectionFactory := TDBXConnectionFactory.GetConnectionFactory;

007     
ConnectionProps   :=
ConnectionFactory.GetConnectionProperties(ConnectionName);

008     
ConnectionProps   :=
ConnectionProps.Clone;

009           

010     
FDBXConnection := ConnectionFactory.GetConnection(ConnectionProps);

011     

當我看到這些新的實作程式碼時，我早已會心一笑，我不需要認識Steve就知道他大概的養成背景。為什麼? 當我看到上面的實作程式碼使用了Factory設計樣例，從Property檔案載入組態資訊，藉由Factory物件取得資料庫連結物件而不是像以前一樣直接載入C撰寫的驅動程式輸出的直列式的Export程序，我就知道Steve一定是從Java背景來的工程師，因為這種寫程式碼的風格在Java中被大量的使用。

再當我看到Steve以類別來代表驅動程式如下所示:

  TDBXDriver
= class

  Private

…

 

 
TDBXDriverEx = class(TDBXDriver)

  Private

    …

 

 
TDBXClientDriver = class(TDBXDriverEx)

    private

而不像Ramesh是使用C的風格(我們在前面已經看過了):

  GetDriver:
function(SVendorLib, SResourceFile: PChar; out Obj): SQLResult; stdcall;

  DllHandle:
THandle;

 

就更可以確定Steve的背景了。讓我更有趣的是看看C背景的工程師和Java背景的工程師寫程式碼的風格。由於為了保持程式碼的風格，因此我使用了圖形來擷取了Highlander中部份的實作程式碼如下:

各位可以看到Steve的風格，不但是非常的物件導向，連每一個字元都排得整整齊齊，而且使用Delphi語法寫程式碼的習慣和Java的風格非常的接近，這和Ramesh自由的C風格是截然不同的，因此當我在追蹤Steve的程式碼時就讓我比較愉快，所以我是比較喜歡物件導向和嚴謹的風格的，不過我知道也有很多人是自由派的，well，這就是程式風格嘛。這些推理，構想和學習的事情是我現在閱讀，追蹤原始程式時的另外的樂趣，其實我也不知道我這個嗜好是從什麼時候開始的。

這些樂趣和觀察就是我在Beta測試Highlander中經歷的第3個奇妙的經驗，程式碼也許不僅是代表開發人員的思維邏輯，也會透露出他的成長背景，更會影響他的設計架構，多看看別人的程式碼，多想想別人的設計是自己進步的竅門之一，不過也許我們也應該花些時間回頭看看自己以前的程式碼，這麼多年來它透露了出什麼呢?

那麼您看過昨天的您了嗎? 去年的您是什麼樣子? 那更早以前呢?

說完了Highlander 3個讓我回味的經驗之後，下次該讓我們好好從技術角度討論了，先從我喜歡的開始吧，讓我們看看DBX4，BlackfishSQL和ECO IV

期待在CodeGear的第一個9月

最近沒什麼寫文章，這有許多的原因。首先是我不知要寫些什麼。噢，如果各位認為我說不知道寫些什麼代表沒東西可寫那就誤會我的意思，我的『不知要寫些什麼』是因為一來CodeGear現在管的很緊，連許多老外都會來看我的部落格，再加入Google即時翻譯的功能，著實讓我被盯的很緊，不太敢多寫些和未來技術有關的內容。另外的因素則是因為實在太忙了。9月份CodeGear就要發表2個非常重要的產品，而這2個產品也到了最後測試的階段，我每天花在這上面的時間就很多，再加上CodeGear其他事務性的工作，因此在CodeGear工作實在比以前在Borland還忙碌。

不過就是因為最近忙碌的日子讓今天早上我在開車時一便聽著Mika的Life In Cartoon Motion專題時突然感覺一陣放鬆，可以想想從7月以來體驗的奇妙經驗。這些奇妙經驗主要便是因為CodeGear目前正在Beta測試的三個產品帶來的感受。也許在我說明我奇妙經驗以及經歷這些奇妙經驗之後自己的感想之前，我應該先說明是那些產品讓我有這些不一樣的感覺，這三個產品就是目前仍然在Beta測試的Highlander，RoR IDE以及ECO IV。

為什麼我以前不會有這次這麼不一樣的感覺? 以前我不也歷經了無數次產品測試的階段嗎? 也許各位會問我這個問題。是的，我的確是測試過無數的產品，但以前我在測試產品時大都只把測試中的產品當成『開發工具』產品在測試，
都是在測試功能，測試穩定度，找臭蟲中度過，但卻沒有想太多其他的事情，但是這次卻不一樣。

為什麼? 給各位一個提示，現在回頭看看我說的三個產品，您看到了什麼? 三個產品? 三個技術? 三種語言(Delphi.NET，Ruby，C#)?，還是三個煩人的工作(一笑)? 其實這三個產品之所以給我很強烈的感覺是因為他們代表的技術是如此的不同，我簡單的用下面的表格呈現我看到的東西讓各位也感覺一下:

產品	Web技術	軟體工程
Highlander	ASP.NET	Agile/Page Mode
RoR IDE	Rail	Agile/MVC
ECO IV	+ASP.NET, +MonoRail	Agile/MDA/DDA

 

想像一下我一天的工作，如果我早上測試Highlander，下午又測試RoR IDE，那麼我將如同洗三溫暖一樣，早上使用ASP.NET，以Page Mode和ASP.NET的元件以元件導向方式來開發Web系統，下午又馬上換成使用MVC模型，以框架方式來開發Web系統，也許我到了晚上又決定摸摸ECO IV，那麼我的腦袋又立刻要切換成以MDA/DDA方式思考。同時測試三種設計觀念如此不同的產品是我以前從未擁有過的經驗。而當我被這些不同的軟體工程和開發模式弄得腦筋錯亂，而導致搖頭晃腦，口吐白沬之時也就是那種神奇感覺出現之際，看來這年頭搞軟件也可以擁有吃免費搖頭丸的效果。

在同時身受三種不同技術洗禮之際是有許多的好處，除了表面上的感受之外，例如我可以決定，嘿，我喜歡ASP.NET這個功能，我覺得RoR那裡做的棒多了，ECI IV在這兒最Cool。更重要的是如果您願意的話，您可以發掘出更為深入的領悟。例如在這三個產品的測試過程中，我看到了CodeGear R&D在開發產品方面顯著的改變，什麼意思? 讓我為各位敘述一下以前Borland開發工具的測試流程。

在早期Borland仍然重視開發工具的時代，每當Borland有新版本的開發工具開始進行測試時，我就搶破頭的想要參加，因為那時的Borland非常的保受，不太讓人參加Beta測試，甚至是Borland內部的員工也一樣。即使加入了Beta測試之後你也永遠不知道下一個測試版本什麼時候會出來，會有什麼功能等，因此您每天只能期望今天好運降臨，突然有一個新的Beta測試版本，於是您馬上就迫不及待的安裝最新的Beta測試版本並且開始好好玩一玩了，而Beta的日子就在這種模式下度過了。

但現在CodeGear不同了，CodeGear R&D開始使用SCRUM的開發開發模式，而且周期大都是一個星期，因此現在我知道每個星期的進度，也知道每個星期5的晚上去下載最新的Beta版來測試。如果您覺得這有什麼不同? 不就是Beta時間進度固定了嗎? 呵呵，可在我眼中卻有大不同的意義，為什麼? 如果各位看過SCRUM的書籍的話，您可能就會髒會到我的感覺。我看了這麼多有關SCRUM的書籍和實際使用SCRUM的案例之後，我覺得SCRUM最重要的精神在於把『軟體開發的不確定性逐漸的轉換成可預測(Predictable)的進度』。

每個SCRUM周期(SCRUM叫Sprint)不但讓開發人員有明確的目標，也讓客戶能夠軟體真的會長成什麼樣子，進而增加客戶對於軟體的可預測性。在我工作的生涯中老板告訴我『唯一的不變就是改變』，學習敏捷開發時它說『要擁抱改變』，既然變化/改變不可避免，那麼SCRUM便是來幫助我們『把變化控制在可預測，可控制的單位時間之內』。

這是第一個這三個產品給我的神奇體驗。

第二個神奇的體驗則來自這個三個產品/技術在IDE中給我的想法。打從我使用Turbo Pascal 1.0一直到VS.Net 2003，BDS 2005為止，每當我在IDE中開始開發之前，我必須先選擇建立一個特定型態的專案，例如ASP.NET專案，VCL Form專案等，接著IDE就在專案管理員中幫我建立了相關的檔案，於是我就接著在編輯器中開啟不同的專案檔案來進行開發的工作，自此之後我們工作的對象就是一個一個不同的檔案，對嗎?Eclipse IDE對於IDE的貢獻是加入了不同Perspective的功能，開發人員可以根據目前工作的模式來使用不同的Perspective，而IDE就把目前的工作環境客製化成當前工作的模式或是當前工作的檔案適合的工具組來讓開發人員使用，免除開發人員需要自己不停的花費時間來進行相同的客製化工作。這很好，節省了許多開發人員寶貴的時間。但這仍然是以專案這個觀念為中心。

可是想想，除了專案，專案檔案或是不同檔案需要的工具組之外，其實我們還需要什麼? 這個構想是我在使用RoR IDE和ECO進行開發時出現的。是的，我需要不只是檔案或是工具組的角度，我需要的是我當前使用的軟體技術需要的環境。RoR使用MVC模式來讓開發人員據以開發，那麼當我建立RoR專案時為什麼不能有一個MVC的環境? 我需要一個View，它是以RoR的Model，View和Controller組成的環境，在這個環境中我可以很方便，很自然的完全使用MVC的精神來使用IDE，此時這個IDE已經成為了MVC IDE，所有的IDE功能都是以MVC的角度讓我對於整個軟體有一個全盤的掌握，讓我從MVC的角度來檢視我的軟體架構。，同樣的，當我使用ECO時，我需要的是MDA/DDA的環境，在MVC/MDA/DDA中專案的角度已經不重要了，我要的是一個適合目前我使用的軟體工程的IDE，是一個客製化成特定軟體開發技術的環境，如此一來我才能擁有最大的生產力。

這是我這次測試這三個產品時出現的第二個體驗。

第三個神奇體驗則是有關，從程式碼和架構閱讀背後開發人員的特性。前一陣子有本書，書名可能是『Code Reading』(呵呵，對不起，老人家記性愈來愈差)。那本書主要討論的是從現有的程式碼中找尋寶貴的程式碼技巧。而我這次第三個神奇體驗就有點類似Code Reading這本書。當我在測試Highlander時看到了背後R&D開發人員養成經驗對於產品的影響，這在以前是我沒注意，也沒有想過的，但這次卻活生生的在我Beta測試的過程中實際的發現，實在太奇妙了。不過這和我想討論的DBX4有密切的關係，我就留待下次一併敘述吧，現在已經是12:43了，我也該吃飯了。

CodeGear 8/9月份線上研討會

CodeGear為了服務我們無法到達城市的開發人員，因此將定期舉辦線上研討會讓向隅的朋友能夠至少在Internet上能夠和我們交流。在8/9月我將各負責一場的線上研討會，歡迎各位朋友參加。在下面的URL可以註冊這兩場線上研討會:

http://borland.interwise.com/borland/iClass/WD3562/default.asp

http://borland.interwise.com/borland/iClass/DS3285/default.asp

 

其中WD3562是討論如何使用Delphi 2007的VCL For Web開發AJAX的應用程式。Delphi&AJAX研討會我已經在上一季於台灣進行了3場次的討論，由於我上一季沒有時間到大陸為大陸的朋友進行這場上研討會，因此歡迎台灣不沒有參加以及大陸的朋友參加。

 

DS3285則是討論CodeGear即將發表的Highlander中的泛型程式設計。在這場研討會中我將介紹Delphi.NET的泛型功能以及如何使用泛型來進行程式設計，相信泛型程式設計是許多Delphi開發人員期待以久的功能。Highlander為Delphi.NET提供了泛型程式設計能力，在未來的Delphi中CodeGear將繼續為Delphi Win32以及Delphi Win64也加入泛型程式設計。因此Delphi的泛型程式設計將可同時使用於原生視窗和.NET中。

要參加這兩場線上研討會您需要在上面的URL中先行註冊，而註冊需要您擁有BDN/CDN的帳號。如果您還沒有申請BDN/CDN的帳號，那麼請您先在下面的URL申請帳號之後，再使用申請的帳號到上面的URL中註冊。

https://members.codegear.com/newuser.aspx?returnurl=http://cc.codegear.com/Default.aspx

 

See You!