四十四、我們的.NET對策 · Joel 說軟件

# 四十四、我們的.NET對策以下是我目前對Fog Creek內漸進移到.NET開發工具的想法。現狀：CityDesk大部份是用Visual Basic 6.0寫的，小部份則是用Visual C++6.0。 FogBUGZ大多是用VBScript for ASP寫，小部份是用C++。幾乎我們所有的內部工具和我們的web呈現(Fog Shop，討論區等等)都是用VBScript for ASP。為什么要要操心移完全到.NET囑？簡單說是因為.NET是目前為止最出色而且生產力最高的開發環境。ASP.NET真的讓web應用程序寫起來容易得不可思議；過去這幾天我已經以出奇的高速寫出幾個內部用的應用程序。各種苦工雜事(如表格驗證及錯誤報告)在用ASP寫web應用程序時會耗去75%的時間，在ASP.NET卻變成輕松的小事。ASP.NET的生產力遠遠超越ASP，其間的差別就像Java和C一樣。了不起。 C#有很多Java的優點，還有一些小的改進如自動的boxing。雖然我們過去用ASP 和VB6時總是盡量寫出相當面向對象的程序，不過移到C#還是不錯的。最后是.NET所附的類別鏈接庫真的很好。事實上由數據存取到web開發再到GUI開發，每祥東西都重新設計過，所以由上到下到難以置信的協調。舉例來說，當你檢視原本的Win32 API，就會驚訝由函數呼叫取得字符串竟然有那么多種方法。每隔兩年他們就會改變主意認為另一種方法比較好。.NET把這些問題全部清掉了。我很高興現在有一個ASP.NET日歷構件(widget)可以用，它會產生由月歷選一個日期的HTML碼，而且可以放心那個東西傳回的日期類別(我相信是 System.DateTime)和SQL Serve「類別所用的日期類別一樣。你大概不會相信，以前我們浪費了多少時間去針對SQL敘述調整日期格式，或是把COleDateTimes轉成其他日期時間格式。再來終于出現了！一個到處都可以用的字符串類別！我上星期才在寫一段ATL程序在BSTR、OLECHAR、char *、LPSTR還有其他亂七八糟的型別間轉來轉去。真是大解脫啊。好吧，我承認，.NET違反了絕不要從頭重寫的規則。微軟有兩個條件可以這樣做。首先他們有全世界最好的程序語言設計者，過去20年間軟件開發的生產力提升，有九成都是這個男人貢獻的。他是Anders Hejlsberg，賜予我們Turbo Pascal (謝謝你！）、Delphi (謝謝你！）、WFC(好嘗試！）和現在的.NET(把球打出場啰！）。其次是他們有本錢投入了無數工程師在這上面做三年，這期間他們的競爭力或多或少都會被延誤到。記住，微軟可以做并不表示你也能做。微軟創造他們自己的重力。正常的規則是對他們無效的。有些人現在會開始寫些氣憤的信贊揚其他環境，或是質問我為什么不用可以寫一次到處用（竊笑）的Java，或者用Del phi (天才已經離開那里了。.NET’就是Del phi 7.0, 8.0, 9.0)或Lisp或其他東西。他們會說我已經被鎖在微軟的卡車上了！可惜我現在沒時間來討論宗教，而且我也覺得討論這東西很無聊。我才不在意就語言來說日文是否比英文更好。這根本就無關緊要。讓我們繼續談完我們的策略。第一個問題：我對.NET還沒有懂到能寫出好的程序代碼。在任何開發環境中，要做某件事時通常都會有很多方法，而我們連第一種方法都還沒學會，更別提第二種方法了。所以我們寫出的.NET程序代碼質量還沒有好的能當產品推出。Bill Vaughn第一本談ADO的書出來之前，我們連基本SQL查詢的最佳作法都不知道呢。所以我們最優先的事是教育，方法是用.NET來制作往后所有內部用的軟件和web程序（基本上就是沒有人會付錢的軟件）。我們可以把部份的Fog Shop移到.NET，各種內部的東西一定會用.NET。（今天我用ASP.NET寫了一個FogShop優待卷產生器。寫得一團亂不過會動！）第二個問題：肥大的20 MB CLR (runtime)。8 MB的CityDesk下載文件里有6 MB 來自執行時期鏈接庫和數據存取鏈接庫，已經是夠慘了；我們絕不可能期望每個 CityDesk Starter Edition使用者另外再下載20 MB的東西。只能希望一年或兩三年后很多人由其他地方拿到CLR了 (Windows XP沒有附真是太慘了）。我們會注意狀況；它以往都會改掉你的user agent;希望現在還是一樣，這樣我們就能拿到統計資料。底線是現在不能把C ityDesk或是FogBUGZ移植到.NET。當CLR普及率到75%時我們就會移植CityDesk的未來版本。計劃如下： 1. 用微軟的轉換工具移植現有的程序代碼和窗體 2. 先用暴力法修正問題，直到能動為止 3. 用C#建立新窗體及類別 4. 以漸進方法，在舊的窗體及類別一定得大改時移植到C# 5. 很多舊窗體和類別只要還正常動作，就會永遠維持在VB.NET(使用丑陋的向后兼容字符串函數等等） FogBUGZ也需要等CLR在服務器計算機的普及率變得更高；我們必須對我們的客戶進行調查，看看如果FogBUGZ要用CLR時狀況會有多糟。我們有另一個正在開發但還不能公開討論的產品；這個產品和FogBUGZ共享了很大量的程序代碼(一個我們稱之為”Dispatcho”的子集合），所以在我們移植 FogBUGZ 之前都還是用 VBScr i pt/ASP。至于FogBUGZ/D ispatcho/秘密新產品，計劃如下： 1. 等到需要CLR也不會出問題的時候， 2. 把現有的「商業邏輯」類別移植到C# 3. 現有的web窗體還是維持用ASP， 4. 用ASP.NET建立新的web窗體。