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