四十四、我们的.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窗体。