我們的 .NET 策略 Our .NET Strategy

以下是我目前對 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 Server 類別所用的日期類別一樣。你大概不會相信，以前我們浪費了多少時間去針對 SQL 敘述調整日期格式，或是把 COleDateTimes 轉成其他日期時間格式。再來終於出現了！一個到處都可以用的字串類別！我上星期才在寫一段 ATL 程式在 BSTR、OLECHAR、char *、LPSTR 還有其他亂七八糟的型別間轉來轉去。真是大解脫啊。

好吧，我承認，.NET 違反了絕不要從頭重寫的規則。微軟有兩個條件可以這樣做。首先他們有全世界最好的程式語言設計者，過去 20 年間軟體開發的生產力提升，有九成都是這個男人貢獻的。他是 Anders Hejlsberg，賜予我們 Turbo Pascal(謝謝你！)、Delphi(謝謝你！)、WFC(好嘗試！)和現在的 .NET(把球打出場囉！)。其次是他們有本錢投入了無數工程師在這上面做三年，這期間他們的競爭力或多或少都會被延誤到。記住，微軟可以做並不表示你也能做。微軟創造他們自己的重力。正常的規則是對他們無效的。

有些人現在會開始寫些氣憤的信贊揚其他環境，或是質問我為什麼不用可以寫一次到處用(竊笑)的 Java，或者用 Delphi(天才已經離開那裡了。.NET 就是 Delphi 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；希望現在還是一樣，這樣我們就能拿到統計資料。

底線是現在不能把 CityDesk 或是 FogBUGZ 移植到 .NET。當 CLR 普及率到 75% 時我們就會移植 CityDesk 的未來版本。計畫如下：

1. 用微軟的轉換工具移植現有的程式碼和表單
2. 先用暴力法修正問題，直到能動為止
3. 用 C# 建立新表單及類別
4. 以漸進方法，在舊的表單及類別一定得大改時移植到C#
5. 很多舊表單和類別只要還正常動作，就會永遠維持在 VB.NET(使用醜陋的向後相容字串函數等等)

FogBUGZ 也需要等 CLR 在伺服器電腦的普及率變得更高；我們必須對我們的客戶進行調查，看看如果 FogBUGZ 要用 CLR 時狀況會有多糟。

我們有另一個正在開發但還不能公開討論的產品；這個產品和 FogBUGZ 共用了很大量的程式碼(一個我們稱之為 "Dispatcho" 的子集合)，所以在我們移植 FogBUGZ 之前都還是用 VBScript / ASP。

至於 FogBUGZ / Dispatcho / 秘密新產品，計畫如下：

1. 等到需要CLR也不會出問題的時候，
2. 把現有的「商業邏輯」類別移植到C#，
3. 現有的web表單還是維持用ASP，
4. 用ASP.NET建立新的web表單。

討論

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.