我们的.NET策略

作者：周思博（Joel Spolsky）
译：Paul May梅普华
2002年4月11日星期四
属于Joel on Software，http://www.joelonsoftware.com

以下是我目前对Fog Creek内渐进移到.NET开发工具的想法。

现状：CityDesk大部份是用Visual Basic 6.0写的，小部份则是用Visual C ++ 6.0.FogBUGZ大多是用VBScript 对于ASP写，小部份是用C ++。几乎我们所有的内部工具和我们的web呈现（Fog Shop，讨论区等等）都是用VBScript for ASP。

为什么要要操心移完全到.NET嘱简单说是因为.NET是目前为止最出色而且生产力最高的开发环境.ASP.NET真的让网页应用程式写起来容易得不可思议;过去这几天我已经以出奇的高速写出几个内部用的应用程式。各种苦工杂事（如表格验证及错误报告）在用ASP写网页应用程式时会耗去75％的时间，在ASP.NET却变成轻松的小事.ASP.NET的生产力远远超越ASP，其间的差别就像Java的和ç一样。了不起。

C＃有很多的Java的优点，还有一些小的改进如自动的拳击。虽然我们过去用ASP和VB6时总是尽量写出相当物件导向的程式，不过移到C＃还是不错的。

最后是.NET所附的类别程序库真的很好。事实上由资料存取到web开发再到GUI开发，每样东西 都重新设计过，所以由上到下到难以置信的协调。举例来说，当你检视原本的Win32的 API，就会惊讶由函数呼叫取得字串竟然有那么多种方法。每隔两年他们就会改变主意认为另一种方法比较好..NET把这些问题全部清掉了。我很高兴现在有一个ASP .NET日历构件（插件）可以用，它会产生由月历选一个日期的HTML码，而且可以放心那个东西传回的日期类别（我相信是的System.DateTime）和SQL 服务器类别所用的日期类别一样，你大概不会相信，以前我们浪费了多少时间去针对SQL叙述调整日期格式，或是把COleDateTimes转成其他日期时间格式。再来终于出现了！一个到处都可以用的字串类别！我上星期才在写一段ATL程式在BSTR，OLECHAR，焦炭 *，LPSTR还有其他乱七八糟的型别间转来转去。真是大解脱啊。

好吧，我承认，.NET违反了[绝不要从头重写]（/维基/ The_Joel_on_Software_Translation_Project：％E4％BD％A0％E7％B5％95％E5％B0％8D％E4％B8％8D％E6％ 87％89％E8％A9％B2％E5％81％9A％E7％9A％84％E4％BA％8B “关于软件翻译的乔尔项目：。你绝对不应该做的事“）的规则微软有两个条件可以这样做首先他们有全世界最好的程式语言设计者，过去20年间软体开发的生产力提升，有九成都是这个男人贡献的。他是[安德斯 Hejlsberg]（http://windows.oreilly.com/news/hejlsberg_0800.html），赐予我们的Turbo 帕斯卡（谢谢你！），德尔福（谢谢你！），WFC（好尝试！）和现在的.NET（把球打出场啰！）。其次是他们有本钱投入了无数工程师在这上面做三年，这期间他们的竞争力或多或少都会被延误到。记住，微软可以做并不表示你也能做。 **微软创造他们自己的重力。**正常的规则是对他们无效的。

有些人现在会开始写些气愤的信赞扬其他环境，或是质问我为什么不用可以写一次到处用（窃笑）的Java，或者用Delphi（天才已经离开那里了.. NET 就是德尔福 7.0,8.0,9.0）或Lisp或其他东西。他们会说我已经被锁在微软的卡车上了！可惜我现在没时间来讨论宗教，而且我也觉得讨论这东西很无聊。我才不_在意_ 就语言来说日文是否比英文更好。这根本就无关紧要。让我们继续谈完我们的策略。

第一个问题：我对.NET还没有懂到能写出好的程式码在任何开发环境中，要做某件事时通常都会有很多方法，而我们连第一种方法都还没学会，更别提第二种方法了。所以我们写出的.NET程式码品质还没有好的能当产品推出.Bill Vaughn 第一本 谈ADO的书出来之前，我们连基本的SQL查询的最佳作法都不知道呢。所以我们最优先的事是教育，方法是用.NET来制作往后所有内部用的软体和网页程式（基本上就是没有人会付钱的软体）。我们可以把部份的雾店移到.NET，各种内部的东西一定会用.NET。（今天我用ASP.NET写了一个FogShop优待卷产生器。写得一团乱不过会动！）

第二个问题：肥大的20 MB CLR（运行时）.8 MB的CityDesk下载档案里有6 MB来自执行时期程式库和资料存取程式库，已经是够惨了;我们绝不可能期望每个CityDesk入门版使用者另外再下载20 MB的东西。只能希望一年或两三年后很多人由其他地方拿到CLR了（Windows XP没有附真是太惨了）。我们会注意状况;它以往都会[改掉你的用户剂]（http://www.oreillynet.com/cs/weblog/view/wlg/458）;希望现在还是一样，这样我们就能拿到统计资料。

底线是现在不能把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表单。

[讨论]（http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=6118&ixReplies=0）