The Joel on Software Translation Project:我們的.NET策略

From The Joel on Software Translation Project

Jump to: navigation, search

我們的.NET策略

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Thursday, April 11, 2002
屬於Joel on Software, http://www.joelonsoftware.com

以下是我目前對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.


Personal tools