最近，《架构师杂志》的资深记者Ron Jacobs在采访Scott Guthrie，这位微软开发事业部的总经理的时候，针对目前广为关注的网络架构开发问题进行了深入的探讨，尤其首次谈到了网络架构开发过程中的若干原则问题。笔者认为，这些原则对于广大热衷于网络开发的专业和非专业人员都有很深刻的启迪作用。本文通过对该次采访的内容进行编辑和总结，以期对广大用户与开发人员有所启迪。
1、 Scott Guthrie的辉煌业绩
谈起Scott Guthrie，我国的IT届人士或许鲜有了解，但是提起鼎鼎大名的ASP.NET，那么不知道的人就微乎其微了，Scott Guthrie就是ASP.NET项目的领导者和主要开发者。实际上，Scott Guthrie所领导开发的项目还不仅仅是ASP.NET，还包括大家所熟知的公共语言运行库（CLR，Common Language Runtime Library），Internet 信息服务7.0（IIS, Internet Information Service），Windows展示平台（Windows Presentation Foundation）及其增强版WPF/E，Windows窗体构件（Windows Forms）等等，都是在他的领导下得以面世的。另外，他参与和领导的微软公司重要项目还包括Commerce Server、Atlas、.NET Compact Framework 和 Visual Studio Web 和客户端开发工具，因此在项目经理和架构师岗位上，年轻的Scott Guthrie已经是汇集经验、成就于一身的八面玲珑的风云人物了。目前，Scott Guthrie全面负责.NET平台组工作的同时，已经成长为新一代的微软开发事业部总经理。换句话说，微软公司近期所推出核心应用程序模型、运行库、工具软件和一些基层的驱动引擎都将在这位悍将的领导下推向市场。
2、网络服务架构开发原则之一：一切为了用户
自1996年至1997年，Scott Guthrie在负责Web服务器技术的研制工作时，偶然介入了IIS团队的开发工作，并参与了IIS4.0的开发与推广工作，由于缺乏于用户的沟通，当时开发团队的成员普遍认为Web编程模型组件的发展已经到了鼎盛时期，近期已经没有可以改进的地方了，但是当时的广大用户却没有对微软的努力付出足够的关注。
网络系统作为一种信息系统，应该遵循软件开发过程中所建立的软件工程原则，这是目前业界已经不争的事实。作为对于软件工程原则一直身体力行的微软公司来说，其开发团队中出现上述情况实属偶然。笔者认为，原因之一是，虽然微软这类航母级的开发团队制定了大量符合自身特点的软件工程规范和原则，但是他们的很多条款都过短关注了一些特别的直接用户，比如一些重量级的公司，Intel、Sun、Oracle等客户的需求；原因之二是，对于网络服务架构的很多标准建立时间较短，而且很多是近些年才逐步得到了完善，在1996年前后关于网络服务架构的很多基本规范并没有建立起来，因此用户即使存在很多需求，也缺乏通用的需求描述和交流平台。基于上述两方面的原因，大多数用户的需求在当时并没有得到足够的重视。在认识到了问题的症结所在之后，Scott Guthrie小组开始和众多的客户沟通，仔细了解他们在构建哪些类型的应用程序，有哪些具体的需求和要求微软向他们提供的基础，很快就意识到需要做的事还有很多。
当时，处于一线的开发人员（即微软所提供平台的基础用户）主要关心两个困难：一是代码/内容分离的问题，即如何减少开发者繁琐的工作量；二是如何编写干净代码的问题，即提高代码重用性的问题。但是编写的大量代码具有"一次编写，终身不读"的特点。从开发工具和运行时间管理的角度，要使当时现有的基础开发架构运行良好，确实存在许多挑战。在没有具体的开发目标的前提下，微软公司同意该小组专门研究IIS未来体系结构，这是一向颇具风险的投资，但是投资量不大，因为Scott Guthrie当时领导的整个团队只有3-4人。正是这个小组发明了Windows Server 2003中著名的HTTP.SYS内核驱动程序，并开发了Web编程模型组件以及ASP.NET的雏形。
3、网络服务架构开发原则之二：重用性并非总是一剂良药
Scott Guthrie当时领导开发团队在开发过程中也曾面临平台选择的问题，当时.NET已经初具规模，但是最初它们却没有基于.NET进行开发，而是在大部分的原型设计中选择了传统的C++、JavaScript 和 ActiveScript 脚本引擎，这是因为在体现编程模型的垃圾回收、精细封装和面向对象技术方面等特性方面，他们没有发现.NET所提供的大量可重用代码可能给自己未来的产品可能带来任何的方便。微软的开发团队不利用自己具有可重用开发的基础平台，这是否是对自己产品的不信任呢？所有的知情者为他们捏了一把汗，因为这需要极大的勇气、并要冒极大的风险，所开发的产品能否与微软的大框架良好兼容，开发之初没有人敢相信他们必定成功。
时至今日，当ASP.NET几乎成为网络开发架构的首选已经成为事实的时候，Scott Guthrie终于能够大胆地说出自己的看法了，软件开发中的重用性原则并非放之四海而皆准的真理，有些时候没有一个具有重用性的基础平台，对于成功产品的推出可能会是一件好事情。换句话说，如果当时的基础开发是基于.NET开始的，恐怕不会有今日ASP.NET的成功。实际上，他们的这次成功也给大量迷信上层平台的人们提了一个醒，重用性并非软件工程原则提供给开发人员的必须服用的良药。
目前，人们已经爱不释手的ASP.NET拥有可以对服务器的后台运行垃圾回收的应用程序，可以优化地实现服务器的瘦身。
4、网络服务架构开发原则之三：尽量使用托管代码
Scott Guthrie所领导的开发团队在所开发的ASP.NET中使用了大量的托管代码，它不会成为某些本机内容的打包程序，而需要将它深深地置入到平台之中。据统计，ASP.NET开发过程中，95% 的代码使用了托管代码。这样做有两重原因：一是要利用其提供的扩展性，真正将面向对象的扩展性深深置入到平台中；二是由于客户应用程序将采用托管代码，而且相对于客户所占的份额而言，在调用堆栈方面的代码的比例相对较小。如果不使用托管代码编写代码，还认为客户应用程序能轻易成功，目前看来是自欺欺人的。虽然放弃了传统代码重用的理念，而选择代码托管作为一次风险很高的赌博，但这种方式确实很奏效，可以说托管代码对于ASP.NET项目的成功有着巨大的促动作用。
ASP.NET的成功从某种意义上说明了小团队开发可以从一个全新的代码库入手，而不必要拘泥传统软件工程中声音越来越响亮的代码重用原则，更有利于将一些核心的改进深入到引擎内部，随着后续系统的不断充实和开发团队的不断壮大，这种对深层引擎的改进会得到丰厚的汇报。在大的开发团队中，如果离开了COM的互操作性而重用大型旧代码库，实施起来的困难也会非常巨大。因为COM的互操作性在那时还根本不存在。
5、网络服务架构开发原则之四：尽早构造原型
管理层敢于下大赌注于一些关键项目的开发，这是微软公司发展历史上非常值得其它公司借鉴之处。然而如果没有周密的计划，以及遵循一些原本已经证明是正确的系统开发原则，在强大的公司也会因为草率行事而导致最终的失败。在这些可以奉行的原则之中，原型法（Prototype）是非常值得推崇的，关于原型法的由来和历史我们不准备做过多的解释，因为它已经成为目前程序设计领域广泛遵循的原则。但是，Scott Guthrie所领导的开发团队在应用原型法时却有独特的心得：将原型法尽早实施于程序设计的早期过程之中，即尽早构造原型。
ASP.NET的开发过程中，确定了一个非常重要的纲领，即将构造原型的过程放在进可能早的环节之中。在项目早期力争让运行代码在原型上运行，以展示给他人。
不仅可以用原型证明系统功能的真实性，而且在这一过程中也可以学会很多构建系统的策略，以便发现哪些环节可行，哪些不可行，并相应做出响应。所建立的原型，包括组件控件驱动模型、Web编程的事件驱动方法等等。通过原型法，结合迭代策略就会发现，这些原本虚拟的应用程序原型，有些确实无法用代码编写出来，也有些功能确实非常必要。将原型法提前到需求分析阶段，对于ASP.NET系统的成功至关重要。它的重要意义有两点：第一，它是用来尽早提升质量的方法，第二，它会为在不必担心回归的情况下重构和调整代码库奠定基础。当涉足一个项目或是一个全新领域，根本不知道该如何从头开始研究出最终产品时，专门花一段时间来构建原型并不断尝试是至关重要的。
6、网络服务架构开发原则之五：架构师不能仅仅从事分析设计工作
一个好的架构师，首先不能只做分析设计工作而不编写代码。Scott Guthrie认为，架构师应该是多面手。这些人应该有时参与开发，有时进行架构设计。编写代码对于架构师而言是非常重要的。在实际工作中，一个架构师不一定要编写生产代码，但要不断尝试新技术、新方法，并体会系统的工作方式，这对于其提高设计工作的质量至关重要。为了做到这一点，不需要架构师每天编写大量的生产代码，可以每天抽出一或两小时编写代码。比如，编写一些示例、原型或有趣的小项目，以确保自己掌握和了解编码前沿技术。从代码架构师的角度来说，动手实验非常重要。
一个好的架构师，还要研究系统设计的核心理论，探索如何构建高度可靠的系统。Scott Guthrie认为，架构师应该在实践中总结出一些行之有效的原则，并应用到实际工作中。并不是说要考虑具体的代码内容，而是需要思考系统的简易性、可靠性或容错性等成功系统的核心原则及其实施策略。无论是客户端应用程序、服务器应用程序、还是游戏程序，都需要认真考虑这些原则。这儿可以举出一些有关原则的具体实例：Windows 或 Unix 应用程序中进程地址空间的工作方式是什么？什么是线程技术？如何深刻理解它在多处理器或多核系统上的工作？
具有良好编码背景的架构师，要在体系结构、开发和软件原理方面拥有非常深厚和坚实的背景。假如架构师能够勤于思考系统设计的核心理论，可以在很大程度上给于开发团队有效的指导。
7、网络服务架构开发原则之六：发扬团队协作精神
Scott Guthrie认为，在网络服务架构开发中，除了上述原则之外，还有一个非常重要的原则，即开发团队应该具有团结协作精神。尤其是架构师能够将一些有用的东西逐步渗透给其他团队成员，并给他们带来潜移默化的影响。另外，一个优秀的架构师应该能够保证将自己的技术技能与公司团队内部和团队之间的协调工作能力相结合，应该能够从技术角度为产品的未来铺平道路，在从事一些更高级的原型构建工作并研究产品的开发方向的同时，还要为探索下一代产品做出努力。一个优秀的架构师必须能够自如地跨多个团队开展工作。
其它团队成员必须各司其职，并在完成本职工作的前提下，最大限度挖掘个人的工作潜力，为确保产品质量尽职尽责。其他团队成员必须相信架构师是忠于团队的，与团队之间保持长期的合作关系，会对问题的解决有所贡献。
综上所述，上面讲述的几个原则，本质上是要求包括架构师在内的团队每个成员应该与时俱进，即适应社会的快速变化，接受新生事物的不断涌现。要做到跟上时代发展的脚步，开发团队的每个成员必须做到一些原本不难做到的小事，比如，找时间去不断充电、腾出时间专门关注业界的动态、订阅优秀的博客并每天阅读帖子等等，就可以很好地了解当今的热门技术和行业的最新发展动态。只有这样，团队所开发出来的网络服务架构才能满足不断变化之中的用户和开发人员需求，才能并拥有最广大范围用户和开发人员的支持与青睐，才能将用户和开发人员的丰富想象力发挥到极致！
