Delphi中VCL库的原架构师Chuck Jazdzewski回忆Delphi 1的开发原则

1995年2月14日情人节。

我坐在Moscone中心正厅的前排。灯光刚刚变暗，人群中一片寂静。数千人突然全神贯注地注视着舞台。照相机熄灭，发出预料中的杂音。然后，安德斯（Anders）（注：Delphi和C#设计师）上台并开始演示。

我之前或之后从未经历过类似的经历。我既紧张又兴奋。我们建立了每个人的期望，我希望我们不会令他们失望。

显然我们没有。似乎在每一个功能上，安德斯（Anders）都表现出人们的欢呼，而当安德斯（Anders）表明Delphi本身就是一个Delphi开发的应用程序时，我们受到了热烈的欢迎。我知道我们做了出色的事。我将永远为之骄傲。

是的！我们度过了一个令人惊叹的夜晚，用了大约2年开发时间。那是我花所有时间最多的一个版本，比我们原先计划的要花一年多的时间，但是我们完成了，感觉非常非常好。

好了，快完成了。Delphi的第一个版本要等到14日的两周后的3月1日才发布，而我们仍处于最终批准该产品的阶段，但我们尚未完成。有几个“构建中止”错误需要修复，而我记得，马克·库西纳（Marc Cousineau）是最后一个站着的人。他错过了那天晚上。我们在那里想念他，但他拿了最后几发子弹，所以我们其他人都可以玩得开心。谢谢马克！

我们怎么知道我们选择的功能是正确的？我们怎么知道我们完成了？

构建产品的最大挑战通常不是做什么，而是弄清楚您不必做什么。在可以构建的所有功能中，应该构建哪个？哪些可以等待，哪些不能等待？即使在'95，也就是Windows '95发生翻天覆地变化的6个月之前，Windows API仍然庞大而复杂。我们应该包装API的哪些部分，我们应该忽略哪些部分？

我们所做的就是应用80/20规则，或者据我后来了解到，这被称为帕累托原理。将其应用到Windows API之类的东西意味着在80％的时间中大约只有20％的API被使用。这意味着我们不必包装所有东西，只需要找出那20％。或者，正如安德斯（Anders）喜欢说的那样，我们需要争取最大的收益。

但是，20％的时间使用的其他80％的API呢？我们知道两件事。首先，我们永远没有时间将其全部包装。我们没有人，也无法跟上像微软这样多产的公司生产产品的包装纸。其次，无法编写价值不超过80％的应用程序。这导致了原理，

• 使简单的事情变得简单。
• 使困难的事情成为可能。

该原则在实践中最直接的示例是具有该  Graphics 单位的单位  TCanvas 及其相关类。Graphics 包裹基础Windows API句柄的所有  类均通过适当命名的Handle 属性公开该句柄  。对于高级封装，这在当时是独一无二的。允许用户使用该手柄进行几乎任何操作，并且基础对象将相应地进行调整。我和Anders花费了大量时间来实现这一目标；使容易的事情变得容易，而使困难的事情变得可能。 TCanvas 使用 DC很简单，公开我们使用的基础句柄使我们无法包装调用API。您可以看到在整个VCL中都应用了此原理，暴露了底层的句柄以使困难的事情变为可能，颈椎枕即使这样做并非易事。

如前所述，我们有意使VCL可扩展。我们没有人来包装所有东西，而是希望我们的用户能够构建或购买创建应用程序所需的组件。允许使用与编写其余应用程序时相同的语言来编写组件，这意味着我们为特定于应用程序的封装大大降低了门槛。

我们从1993年初开始使用Delphi，后来在那个冬天的某个时候被锁定并加载了版本。实际上，我们花了很长时间才获得了看起来像Delphi的东西并开始运行。我记得我们在1993年7月向一群工程师进行的演示，向他们展示了当时的情况。它包括组件面板，表单设计器和基本编辑器，甚至还包括我们后来称为双向编辑的东西。

编辑器实际上只是一个  TEdit 非常初级的人员！到了七月，不仅是我和安德斯了。我们决定取消有关Borland Pascal 8.0的工作，而完全专注于Delphi。Allen Bauer和Alex Shtaygrud开始从事调试器和编辑器的工作（解释为什么使用TEdit），而Dave Scofield开始使我的IDE挑毛病  看起来更美观。具有讽刺意味的是，开发人员在其大部分职业生涯中都在构建UI库和框架，却无法创建外观精美的UI来挽救生命。

会议结束后，我记得一位软件开发工程师说我们应该立即发货并立即发货！我们受到鼓舞，但知道我们为使Delphi 1进入可发布状态付出了很多努力。欢迎加入Delphi知识局QQ群:32422310