Joel on Software
Our .NET Strategy
by Joel Spolsky Thursday, April 11, 2002
Here are my current thoughts on the gradual migration to .NET development tools at Fog Creek.
下面就是我关于FogCreek公司慢慢转移到.NET开发工具的想法。
The status quo: Most of CityDesk is written in Visual Basic 6.0, with parts written in Visual C++ 6.0. Most of FogBUGZ is written in VBScript for ASP, with parts written in C++. Almost all of our internal tools and our web presense (Fog Shop, Discussions, etc) are written in VBScript for ASP.
目前状况：大部分CityDesk的功能都是使用VisualBasic6.0写成， 有一些部分使用VisualC++6.0 写成。 大部分FogBugZ的功能用ASP的VBScript写成，一些部分使用C++写成。 我们几乎所有的内部工具和我们的网页展示（FogShop，讨论，等等）都是用ASP的VBScript写成。
Why bother moving to .NET at all? Simply put, it's because .NET appears so far to be one of the most brilliant and productive development environments ever created. ASP.NET really makes it incredibly easy to create useful web applications; over the last couple of days I've been creating some applications we use internally at incredible speed. All the grungy stuff that takes 75% of the time creating web applications with ASP (such as form validation and error reporting) becomes trivial. ASP.NET is as big a jump in productivity over ASP as Java is to C. Wow.
谁会费那个事要迁移道.NET上呢？ 简单说吧， 因为.NET到目前为止已经成了有史以来最聪明最具开发效率的编程环境。ASP.NET 确实让编写有用网页应用程序变的无比简单；过去的几天我以难以想象的快的速度编写了一些我们内部使用的工具。 所有那些采用ASP创建网页应用程序需要花费75%时间做的邋遢东西（例如表单验证和错误报告）在ASP.NET里都变的超级简单。 就生产率而言，ASP.NET相对ASP的提升程度就好比Java相对于C的那种提升程度一样。哇哦。
C# has most of the good stuff from Java, with a few small improvements like automatic boxing. Although we have always done what we can to create reasonably object oriented code in ASP and VB6 in the past, switching to C# will be nice.
C#从Java继承了所有好的特性， 并且有一些小的改进，比如自动装箱。 虽然在过去用ASP和VB6的时候我也尽可恩的编写了合理的面向对象代码， 但是切换到C#还是会更好。
Finally, the class libraries that ship with .NET are great. The fact thateverything, from data access to web development to GUI development, was redesigned means that there is incredible consistency from top to bottom. When you look at the old Win32 API's, it is simply amazing how many different ways there are to get a string back from a function call, for example. Every two years they changed their mind about what a good way is to do this. .NET has cleaned that all up. I love the fact that you can use an ASP.NET calendar widget, which generates HTML that selects a date on a monthly calendar, and be confident that the "date" class you get back from that thing (System.DateTime, I believe) will be the exact same date class that the SQL Server classes expect. In the past you would not believe how much time we wasted doing things like reformatting dates for SQL statements, or converting COleDateTimes to someOtherKindOfDateTime. And finally -- a string data type that works everywhere! Just last week I was writing ATL code and messing around with BSTRs and OLECHARs and char*s and LPSTRs and what a mess that was. Good riddance.
最后，.NET提供的类库实在太棒了。 基本上，从数据访问，网页开发到用户界面开发都重新设计过了。这也意味着从上都下都有着无比优越的一致性。 当你去查看旧的WIN32 API的时候，最令人称奇的就是很容易就能发现有多少种不同的方式来从一个函数调用里获取一个字符串返回值，在比如说，每隔两年他们就会改变他们觉得做这件事情的正确方式。 .NET已经把这种情况清理干净了。 我钟爱ASP.NET的日历原件，他会帮你产生HTML代码然后显示一个月历， 然后要相信那个元件产生出来的日期（我觉得应该是SYSTEM.DATETIME）绝对就是SQLSERVER预期的那种日期类型格式。 而在过去，你根本就想不到我们在SQL语句里重新格式化日期格式花了多少时间，或者是把COLEDATETIEMS转换成其他格式的DATETIME。 然后，最重要的是，终于有了普遍使用的字符串数据类型！就在上周我编写ATL代码的时候还在把BSTR和OLECHAR类型 还有什么CHAR* LPSTR之类的搞来搞去 ， 这些现在全都滚蛋了。
OK, I admit it -- .NET violated the Never Rewrite From Scratch rule. Microsoft got away with it because they had two things. First, they had the world's best language designer, the man who was responsible for 90% of the productivity gains in software development in the last 20 years: Anders Hejlsberg, who gave us Turbo Pascal (thank you!), Delphi (thank you!), WFC (nice try!) and now .NET (smacked the ball outta the park). Second, they put about a zillion engineers on it for about three years, during a period where much of their competition was more-or-less stalled. Remember, just because Microsoft can do something, doesn't mean you can. Microsoft makes their own gravity.Normal rules don't apply to them.
好吧，我承认 -- .NET确实触犯了“不要从头开始”的规则。 微软却能够灵活的绕开这个原因主要有两个原因。 首先，他们有着世界上最优秀的语言设计师， 这就是那个最近20年负责生产了世界上90%的有效率的软件开发方式： Anders Hejlsberg， 他给我们创造了TurboPascal（谢谢你！）， Delphi（谢谢你！）， WFC（不错的尝试！） 然后现在是.NET（把球远远的砸出了界外）。 其次， 他们让几万个工程师在这件事情上工作了3年，在这个阶段他们的竞争多多少少停滞了。 记住，这只是因为微软有能力做这件事情，不是说你也有这个能力。 微软能够创建自己的引力。 正常的法则不适用于他们。
A few dozen people will now proceed to compose angry emails praising some other development environment, or asking why we don't just use Java and get Write Once Run Anywhere (giggle), or Delphi (the talent has left the building. .NET is Delphi 7.0, and 8.0, and 9.0), or Lisp, or whatever. I am getting locked in the Microsoft Trunk! they will say. Regrettably, I don't have time to get into religious discussions right now and I usually find them quite boring. I don't care if Japanese is a better language than English. It just doesn't matter. Let me finish describing our strategy.
会有几十个人接下来会写一封怒气值爆表的邮件来向我赞扬其他的开发环境，或者是问我为什么我们不适用Java来一次编写随处运行（偷笑）， 或者是Delphi（ 那个天才已经离开那里了。 .NET就是Delphi7.0 和8.0和9.0 ） 或者LISP或者其他的什么东西。 我已经锁定在了微软阵营了！ 他们会说。 不幸的是， 我现在没有时间和你们进行这种宗教信仰式的争论，而且我觉得这些人通常都很无聊。 我才不会在乎日语是不是比英语好的一种语言。 这根本每什么关系。 让我接着描述我们的策略。
First problem: we don't know enough about .NET to write good code. As usual in any development environment there are many ways to do any given thing, and we haven't quite learned the first way, let alone the second way. So the quality of .NET code that we can write is not good enough to ship. Until Bill Vaughn's first ADO book came out, we didn't even know the optimal ways to do basic SQL queries. So our first priority is education, which we will accomplish by doing all future in-house and web-based development in .NET -- basically, all the software that nobody is paying money for. We can migrate parts of the Fog Shop to .NET and certainly use .NET for all kinds of internal stuff. (Today I wrote a FogShop Coupon Generator in ASP.NET. It's kind of messy but it works!)
第一个问题： 要写出好的代码的首要障碍就是我们不够了解.NET。 跟往常一样在一个开发环境里面有很多种不同的方法达成同一个任务， 我们还没有学到第一种方式， 更不要说第二种方式了。 所以我们编写的.NET代码的质量不够好因此不能发布。 在BillVaughn的第一本ADO书籍问世之前， 我们甚至都不知道进行简单SQL查询的最佳方式。 所以我们的首要任务就是教育， 通过教育，未来所有的内部和网页开发都会用.NET完成 – 基本上所有那些还没有用户付钱购买的软件都会用.NET开发。 我们会把Fogshop部分迁移到.NET，然后肯定会用.NET 来开发各种内部工具。 （ 今天我用ASP.NET开发了一个Fogshop优惠券生成器， 虽然写得很乱但是能运行！）
Second problem: the obese 20 MB CLR (runtime). It's bad enough that about 6 MB of the 8 MB CityDesk download comes from runtimes and data access libraries; we just can't expect every home CityDesk Starter Edition user to download another 20 MB. The hope is that in a year or two or three lots of people will have the CLR from somewhere else (too bad it didn't make it into Windows XP). We'll keep an eye on that; it used to change your user agent; I hope it still does, so we can get statistics.
第二个问题： 肥大的20MB CLR运行时环境。 要知道CityDesk的8MB安装文件有6MB是运行时环境和数据访问库已经足够糟了；我们不能够期望每一个CityDesk初学者版本的用户会再下载20MB。 我们期望是在未来的一年两年内或三年内用户会从其他地方下载CLR运行时环境（没有把这个继承进WINDOWXP实在太糟了）。 我们会主意留心这件事情； 下载这个东西需要你更改你的用户代理，我希望仍然是这样，这样我们就能够获得一些统计数据了。
The bottom line is that neither CityDesk nor FogBUGZ can be ported to .NET today. We will port some future version of CityDesk when the CLR has about 75% penetration. The plan is to:
1 . port existing code and forms using Microsoft's conversion tools
2 . fix problems by brute force until it's working again
3 . create new forms and classes using C#
4 . gradually port old forms and classes to C# whenever they need major work, anyway
5 . many old forms and classes will remain in VB.NET forever (using the ugly backwards compatibility string functions, etc.) as long as they work properly.
底线就是现在CityDesk和FogBugz都不能移植到.NET。 在未来CLR的安装率突破75%的时候，我们会考虑用.NET为CityDesk的未来版本开发一些新特性。 计划就是：
1 . 采用微软的转换工具移植现有的代码和表单
2 . 通过暴力枚举解决所有会出现的问题，知道解决这些问题
3 . 使用C#创建新的表单和类
4 . 当旧的类和表单有一些大的改动的时候，不管怎样，都使用C#重写这些
5 . 很多旧的表单和类会永远停留在VB.NET （仍然会使用那些丑陋的前向兼容的字符串函数，等等） 只要它们还能运行。
FogBUGZ also needs to wait for greater CLR penetration on server computers; we need to survey our customers and find out how bad it would be if FogBUGZ required the CLR.
FOGBUZ需要CLR在服务器计算机上获得更大的突破； 我们会向用户调查如果FOGBUGZ需要用CLR的话，会有多糟糕。
We have another product in the works which we haven't talked about publically; this one will share a large portion of its code base with FogBUGZ (a subset we are going to name "Dispatcho") so it will remain VBScript/ASP at heart until we port FogBUGZ.
我们有一个同步进行但没有公开提到过的产品； 这个产品会和FOGBUGZ共享大部分的代码库 （这个子集，我们打算命名为“DISPATCHO”） 所以在我们移植FOGBUGZ之前，它本质上也会停留在VBSCIRPT/ASP架构上。
For FogBUGZ/Dispatcho/SecretNewProduct, the plan is:
1 . wait until it's OK to require CLR,
2 . port existing "business logic" classes to C#,
3 . keep current web forms in ASP,
4 . and create new web forms in ASP.NET.
对于FOGBUGZ/DISPATCHO/神秘新产品，计划就是：
1 . 等待可以切换到CLR了
2 . 将现有的“业务逻辑”类移植到C#
3 . 保留现有的ASP网页表单
4 . 用ASP.NET开发新的表单。