《架构师杂志》评述：Scott Guthrie

发布日期： 2007-03-29 | 更新日期： 2007-03-29

 

Scott Guthrie 是 Microsoft 开发事业部的总经理。他领导着负责构建 CLR（公共语言运行库）、ASP.NET、WPF (Windows Presentation Foundation)、"WPF/E"、Windows Forms、IIS（Internet 信息服务）7.0、Commerce Server、.NET Compact Framework 和 Visual Studio Web 和客户端开发工具的开发团队。在编写新的《架构师杂志》评述系列文章期间，Ron Jacobs 就职业生涯及对体系结构的看法这两个主题与 Scott 进行了一次访谈。

RJ：有人认为您所从事的“是一份很棒的工作”，今天就让我们来聊聊您和您的职业。您目前在 Microsoft 负责哪方面工作？

SG：我现在负责 .NET 开发人员平台组。其中包括 CLR（公共语言运行库）、.NET Compact Framework、IIS（Internet 信息服务）、ASP.NET、Atlas、Commerce Server、Windows Presentation Foundation、Windows Forms 和用于在 Visual Studio 中开发 Web 应用程序的工具。

RJ：哇，涉猎广泛！

SG：也乐趣无穷。这其中包括我们的核心应用程序模型、运行库、工具及其基层的所有引擎。涵盖了许多绝妙的技术，有许多值得研究的东西。

RJ：大多数人会因为 ASP.NET. 而记住您。让我们回到您初到 Microsoft 的日子。您最初都做些什么？

SG：我最早是在 IIS 团队工作，那是在 96 到 97 年，主要从事核心 Web 服务器技术的研究工作，并参与了一个 IIS 版本的研发。IIS 4 发布后，我们开始研究下一代的 Web 编程模型组件。我们当时认为，“我们可能已经做到极至了。就功能集来说还能有什么要做呢？”

于是，我们开始和众多的客户沟通，仔细了解他们在构建哪些类型的应用程序。我们很快就意识到需要做的事还有很多。人们当时都在为代码/内容分离以及如何编写干净代码这两个问题所困扰。我们常开玩笑说我们编写的代码“一次编写，终身不读”。从工具和运行时管理的角度来讲，要使当时现有的基础结构真正良好地运行存在许多挑战。为了实现这个目标，我们成立了一个小组来专门研究针对 IIS 的未来体系结构。正是这个小组发明了我们随 Windows Server 2003 引入的 HTTP.SYS 内核驱动程序。我和另一个同事一起，开始研究 Web 编程模型组件并编写了 ASP.NET 最初的原型。

RJ：你们当时似乎正在考虑将这再提高一个层次，利用在那时还相当神秘的某种东西。我还记得 .NET 的那些日子；你们那时称它为 ASP+。

SG：我们最初叫它 XSP；总有人会问 X 代表什么。那时它真的什么都不代表。XML 以它开头；XSLT 以它开头。一切美好的事物似乎都从 X 开始，因此我们最初会这样命名。在最初的六个月中，我们没有使用 .NET。那时候还没有 CLR（它大约是和我们一起起步的），因此我们大部分的原型设计使用的都是 C++、JavaScript 和 ActiveScript 脚本引擎。我们知道我们需要一个面向对象的环境，我们非常喜欢受管编程模型在垃圾回收、精细封装和面向对象技术方面的特性。尽管如此，我们开始编写生产代码时实际上使用的却是 C++，因为当时的确没有一个理想的运行时平台来构建代码。我们就这样编写了两星期，直到和 CLR 团队不期而遇；当时这个团队在公司内部还没有上层产品的合作伙伴。他们唯一拥有的编译器是叫做“simple managed C”的东西，我们亲切地称它为“smack”。我们最终决定，“我们或许应该以它为基础”。这要冒极大的风险，我们的团队在那时总共才三四个人。我们之所以能够赌一把，主要因为没有人真正在乎我们的成败。谢天谢地，我们做到了，而且取得了巨大的成功。后来的事可以说是众人皆知了。

RJ：我还记得那时候的事。CLR 刚刚问世的时候，几乎没有人愿意下这个赌注。许多团队都在说“我不这么认为”，但是你们做到了，而且取得了惊人的成绩。

SG：是的，尽管在服务器上实现垃圾回收在今天已经司空见惯，但整个想法在当时却着实令人们吓了一跳。他们说：“不可能构建出能在后台运行垃圾回收的应用程序。服务器永远都不会伸缩”。当时出现过很多非常糟糕的情况。从项目的角度讲，我们所做的一件事取得了巨大的成功。我们说：“我们要拿托管代码赌一把，它不会成为某些本机内容的打包程序。我们要将它深深地置入到平台之中。我们 95% 的代码将用托管代码编写”。

我们这样做有两重原因。一是要利用其提供的扩展性，真正将面向对象的扩展性深深置入到平台中。二是，我们知道客户应用程序将采用托管代码，而且相对于客户所占的份额而言，我们在调用堆栈方面的代码的比例相对较小。如果我们连用托管代码编写代码都没想到，还认为客户应用程序能轻易成功，那简直就是自欺欺人。它有着巨大的促动作用。从第一天开始直到创建出较为复杂的示例，我们一直在根据需要不断调整核心的 CLR 引擎，当我们开始着手在上面构建更为复杂的客户应用程序时，我们的工作转化为客户巨大的成本节约优势。这是一次不错的赌博。

RJ：您将这看成是推动引擎改进的方式，这很有意思。您曾说：“我们不但要做这件事，还要通过这件事进一步改善引擎”。

SG：我想这是一次风险很高的赌博，但这种方式确实很奏效。这在很大程度上得益于我们是一个小团队，而且是从一个全新的代码库入手。如果我们的团队再大一些，或者拥有一个现有的大型旧代码库，实施起来可能会更加困难，因为 COM 互操作性在那时还根本不存在。但我们是从头开始，而且开始时人员较少，这些确实有助于我们将这些核心的改进深入到引擎内部。随着我们的不断壮大和功能集的不断翻新，我们得到了源源不断的回报。

RJ：我想管理层肯让你们去尝试真的很不错。

SG：这的确是一场赌博，但却是经过周密计划的。如果我们能够成功将会带来巨大的优势，但不利的方面是我们只有三四个人，在接下来的一年我们总可以尝试一些新的东西。Microsoft 经常下这样的大赌注，而且往往都会取得巨大的成功。当然偶尔也会失败，而且败得一塌糊涂，但作为公司来讲，我们会尽可能确保将赌注押在一些关键的环节上。

RJ：您必须说服所有人允许你冒这个风险吗？或者要比这简单得多？

SG：我们的确不得不说服很多人朝着这个目标努力。在项目早期，我们所做的就是力争让运行代码在原型上运行，以展示给他人。通常你在处理一个全新的项目或者做之前没有人做过的事儿时，将许许多多听起来还不错的 PowerPoint 幻灯片整理起来非常容易，但真实地展示代码并让人们亲身经历这些代码的运行是尤为重要的。不仅可以用原型证明其真实性，而且在这一过程中你也可以学会很多。

我和我的团队努力去做的一件事就是及早构建原型，构建示例应用程序，尤其是可以让客户亲身体验的演示应用程序，我们要向客户说，“看，你可以这样来构建应用程序”。我们设法尽早地做这件事，以便发现哪些环节可行，哪些不可行，并相应做出响应。ASP 项目开始的一个半月后，我写出了一个原型，让人们亲身地感受了一下。这里有组件控件驱动模型（那时我们还没有叫它控件，它们是声明性的标记或组件），这里有 Web 编程的事件驱动方法。我们得以构建出应用程序，并很快发现我们计划中的一些事情的确无法用代码编写出来。与此同时，我们也了解到“这项功能或那项功能确实很棒”，我们就这样不断周而复始，反复迭代。在我们试图让人们知道我们并不是疯子的时候，这一过程发挥了很大的作用。我们展示了我们的代码，而人们也得以亲身体验。这仍然是一次赌博。

RJ：这听起来像是测试驱动开发的思路。我们完成一些短迭代周期；发现一些行之有效的东西。我们会使用自己的作品，针对自己的 API 编写代码，以便了解它们的使用效果。

SG：原理的确是相同的。我将测试驱动开发的意义划分为两层：第一，它是用来尽早提升质量的方法，第二，它会为在不必担心回归的情况下重构和调整代码库奠定基础。在开发生产代码时，我们内部当然会遵循这个基本原理。我想甚至在开始编写生产代码前的原型阶段也是有意义的。对于 ASP.NET.，那是我们成功的之处。那时我们就决定要抛掉后几个月中所要编写的每行代码。我们就此达成一致。我们不会说：“哦，留着这个做修改吧；我们可以把它整理出来”。不。我们要把它彻底抛弃。我们会在某个时候将这个子目录彻底“删除”，那样一来，我们就可以更加大胆地去尝试新事物。我们不必战战兢兢地去保证每样东西的稳定性，就因为它将进入最终版本。

事实上我们这样做了几个月，然后说：“我们做完了，把它删除；从头开始吧；现在我们来编写全部的生产代码并且要确保质量”。我想很多团队都可以从这一点上受益。保证删除原型代码是最最艰难的事。项目通常都是伴随着“嗯，有点相近”的思维而开发出来的。从原型入手并且确保可靠性是很难的。我坚定地认为应该从原型阶段入手并随后将它删除。

RJ：这说明从原型阶段，我们应该着眼于学习，而不应看重这些文件和代码。

SG：每次做项目的时候，只要是重新编写，无论是否从零开始，代码都会变得更好。这在一定程度上是因为你了解了前一种方法的问题和缺陷，并且能够进行反思并做出改进。难就难在你不能一次又一次轻松地做到这一点。但是，当你最先涉足一个项目或是一个全新领域，根本不知道该如何从头开始研究出最终产品时，专门花一段时间来构建原型并不断尝试是至关重要的。

RJ：有人称之为“体系结构刺探”(architectural spike)。这是一个全新的领域，有待于我们进一步探索。我们来换个话题，那在来 Microsoft 前您做过什么？

SG：实际上我大学一毕业就来 Microsoft 工作了。在大学期间我就在 Microsoft 实习。我在大学和高中期间参与了几次创业，搞过一些开发，并以此为乐，但是大学毕业后我还是直接加入了 Microsoft。

RJ：我们和许多对结构体系感兴趣的人都交谈过。好像几乎没有人是只做些设计而根本不编写代码的纯粹的架构师。多数人都是多面手：他们有时参与开发，有时进行架构设计。对于一直在做开发但打算更多进行架构方面构思的人，您有什么建议？

SG：编写代码对于架构师而言是非常重要的。你不一定要签入生产代码，但要不断尝试新技术、新方法，并体会系统的工作方式。最近我并没有编写大量的生产代码，但我每天要花一或两小时编写代码。可以是示例、原型或一些有趣的私人项目；无论什么，我都要进行尝试，思考事物的构建方式。从代码架构师的角度来说，动手实验非常重要。

我的另一条建议是要研究核心系统理论，探索如何架构高度可靠的系统。想一下你要考虑的一些原则，并应用到实际工作中。这并不是说要考虑具体的代码内容，而是思考简易性、可靠性或容错性。这些因素在成功的系统中起着核心作用；无论是客户端应用程序、服务器应用程序还是游戏程序，都是如此。一个认真考虑这些原则并配以良好编码背景的架构师可以在很大程度上给团队以指导。

这些原则并不是要探索出一个向导或是开发不错的新东西，而是要研究 Windows 或 Unix 应用程序中进程地址空间的工作方式。什么是线程技术？如何深刻理解它在多处理器或多核系统上的工作？要消化吸收这种类型的知识、考虑由此衍生的结果，花些时间专门研究未来的趋势（即从硬件和软件角度研究技术未来的走向），并考虑如何进行修改并为我所用。这就是我的建议。

RJ：Microsoft 有开发人员、项目经理和架构师。人们通常对架构师这一角色充满好奇。您希望架构师在团队中发挥怎样的作用？

SG：我们希望或期待架构师能够在团队中担负起几个责任。一是我刚刚谈到的，要在体系结构、开发和软件原理方面拥有非常深厚和坚实的背景。我们希望这样的背景会将一些有用的东西逐步渗透，给其他团队成员带来潜移默化的影响。尤其是在指导年轻和资深的开发人员时，走廊里的对话或者办公室中的闲谈都可以给团队以很大程度的指导。

我们希望架构师能够从技术角度为产品的未来铺平道路。架构师通常要做一些更高级的原型构建工作并研究产品的开发方向。我们希望他们就研发方向提出建议，就实现而言，要求他们既要探索下一代产品，又要着眼于当前产品，以发现我们应进一步改进的地方。例如，我们应该将哪些地方的分解略加调整？我们需要在代码库中做些什么来进行改进？

RJ：除了深厚、坚实的技术技能外，您认为一个成功的架构师还应具备哪些品质？

SG：至少在 Microsoft，对于那些想要在架构领域有所建树的具有深厚背景的技术人员来说，最难的是要保证将自己的技术技能与公司团队内部和团队之间的协调工作能力相结合。

一些软技能更难培养，这就意味着架构师需要动手实践，但还要注意不要危及开发人员或其他团队。他们也应当避免“这是我的，那是你的”这样的对话。架构师必须能够自如地跨多个团队开展工作。他们在工作时注意不要给人留下这样的印象：那就是架构师只是暂时投身于最有趣的问题，然后在遇到难题时便会抽身而去。其他团队成员必须相信架构师是忠于团队的，与团队之间保持长期的合作关系，会对问题的解决有所贡献。这些是架构师需要培养的技能。具有最强影响力的资深架构师能够将深厚的技术和设计技能与人际交往技能和协作能力结合在一起。

RJ：许多人都在说，如今社会变化的速度越来越快，新生事物无时无刻不在涌现。您也提到过跟上发展的脚步是何等重要，但是每天的时间是有限的。您是如何跟上发展的脚步的呢？

SG：这很困难，在开发领域更是如此。就日新月异的创新步伐和信息流动的速度而言，我实在想不出有哪个时代会像现在这样快。回想 90 年代的 Internet 大战，Internet Explorer 与 Netscape 的竞争硝烟四起。那个时候，我们好像不断地在发布新的产品，又总会有新的东西涌现。

从开发的角度讲，我想我们现在所处阶段的发展速度比那个时候更快。要跟上时代的脚步当然十分困难。你必须找时间去不断充电。你必须腾出时间专门关注业界的动态。我想就这点而言博客是一个很好的机制。我订阅了 Bloglines，这是一项不错的免费服务。我大概订阅了 300 或 400 个博客，我尽量每天早晚花 20 到 30 分钟阅读所有人的帖子。这样可以很好地了解当今的热门话题和有趣的想法。

在某种程度上，为了跟上发展的脚步，还要每天花一小时专门构建原型，用自己的产品或其他技术来进行各种尝试；充分掌握现有的组件并知道如何使用它们。在研究任何新技术、API、方法或编程手段时，还有一项重要的工作，那就是不仅要仔细研究有趣的事物本身，而且还要尽量推演出其有用的原则，以便你能够在别处加以应用。因此，如果你研究的是一本有关 Java 重构的书，很好。书中会讲到许多具体的 Java 重构技术，但有哪些更为广义的重构概念是你能够消化理解并应用于 VB 或 C# 的？如果是针对某项专门任务的非常理想的 AJAX JavaScript 框架，也很好。现在，回想一下，尽量找出它的哪个方面可以应用于其他 JavaScript 框架。架构师应当善于研究某些事物并推演事物本身及其中蕴涵的有趣方面，而不是仅仅关注于某个个别的技术元素。

RJ：回顾这些年在 MS 的经历，您有什么遗憾的事情吗？

SG：回首往事，总会有些想要换种做法的事情。有时，可能是曾做过的技术工作，是某种功能的实现方式，你会想“每个人都滥用了那项功能”。或者他们做事的方式背离了我们的预期。当然，在我们构建了像 .NET 那样广泛的开发平台后，我会后知后觉地想出许许多多本可以换种做法的事情。还有一些事情的处理方式，或者与不同团队的合作方式，你会想，“唉，要是我稍微换个方法处理那次谈话就好了”。所以，我肯定能举出许多个别的例子。

总的来说，我对 .NET 的结果非常满意，就结果而言我们已经相当成功。但是，也确实有很多事情我们本可以换种做法，比如“唉，要是不封装那个类就好了”，或者“唉，要是将那个类封装起来就好了”。

如果说有一件重要的事情令我感到遗憾，那就是对于 .NET 客户端应用程序的构建，我们应当早一点花更多时间去仔细考虑客户端的安装过程。我认为我们所采用的方法，即下载的单一可再发行组件包并不比其他任何的 Windows 可再发行组件包差，但我们本应当一开始就抓住这个机会去减少安装带来的影响，并简化客户端应用程序的部署。这就是我们现在正在花大量时间研究的东西，将来一定会有极大的改进，但是我们本应该在六年前就完成这项工作，本应该早一点花更多时间来研究其中的一些情况。

RJ：在您的办公室中，摆放着全部颇有渊源的演讲者徽章，您曾有机会拜访过许多地方，结识了许多人。遇到过什么特别的事吗？有什么人尤其让您记忆深刻？

SG：关于开发人员平台的应用有一件很有趣的事，我发现人们基于我们的平台所构建的应用程序真是五花八门，千差万别。无论是世界最大的社会网络平台 MySpace、还是伦敦股票交易所或英国国民健康服务中心、甚至是华尔街的众多公司（Costco、Dell.com 或 Match.com），都离不开 Microsoft 的技术。前者每天要使用 .NET 浏览 15 亿的网页，而后面的机构有许许多多非常好的客户应用程序是基于 Microsoft 技术构建的。其中许多采用了 Web 方面的技术；其他的则采用其他方面的技术。再看看“迪斯尼乐园”的设施，运行“快速通行证”的仪表都是在精简框架和 CLR 上运行的。如果美国人口局或美国邮政总局的人来敲门，这个人手里拿的设备也是在 .NET Framework 上运行的。

于我而言，印象最为深刻的事就是看到 .NET 在全世界如此广泛而多样化的应用。有时候采用奇异而怪诞的方式，有时候则用于关键任务应用程序，但每一次都那么独一无二，坦率地说真的是超乎你的想像。我认为好的框架并不体现在人们按你的预想在上面构建应用程序，而在于客户和开发人员能够将它的作用发挥到超乎你想象的程度。对我来说，这就是 .NET 最突出的地方。

Scott Guthrie 在 Microsoft 的职业生涯

Scott Guthrie 于 1997 年加入 Microsoft，最初从事 IIS4 和 Windows NT Option Pack 的研究工作。在其发布后不久，他设计了最初代号为“XSP”的新服务器编程模型并构建出原型。随后的 1998 年，与 Mark Anders 一起组建了一个新的团队，构建了最终被称为 ASP.NET 的框架。

Scott 于 2002 年初成为 ASP.NET 的生产单元总经理 (PUM)，并随 Windows Server 2003 发布了 ASP.NET V1.1。在这一期间，他还领导开发了备受欢迎的 Web Matrix 开发工具，这是一个免费的 ASP.NET 开发工具，有助于激发 Web 开发工具的新思维，是为编程爱好者和热衷者提供的一个新方法。2002 年底，他又成为 Visual Studio 内部 Web 工具功能的 PUM，负责开发新的 Visual Web Developer 独立产品（将作为 Visual Studio 2005 系列的一部分发布）和 Visual Studio 中的全部 Web 开发功能。Visual Web Developer 和 ASP.NET 2.0 于 2004 年夏季进入第一次大范围公测，将于 2007 年上半年发布。

在 2003 年底，Scott 的团队与 IIS 团队合并，他担任结合了 IIS、ASP.NET 和 Visual Studio 资产的联合 Web 平台和工具团队的 PUM。随着 ASP.NET 2.0 和 Visual Web Developer 的完成，这个团队目前正积极开发 Microsoft Web 应用程序服务器的下一个主版本，它将作为 Longhorn 的一部分发布。

Scott 现任 Microsoft 开发事业部的总经理，领导负责构建 CLR、ASP.NET、WPF、"WPF/E"、Windows Forms、IIS 7.0、Commerce Server、.NET Compact Framework 以及 Visual Studio Web 和客户端开发工具的开发团队。

Scott 于 1997 年毕业于杜克大学的计算机科学专业，并取得学位。