软件工程简史

软件工程

周爱民在《大道至简》中写道：

语言其实是开发的细微未节，软件工程才是软件开发中的髓质与灵魂。

“实现”的欲望是从程序员出身的管理者的通病。因此如果你仍然在思考选择什么语言、如何重构，以及在开发部里争论一段代码有没有或应不应该采用某种模式，那么请你暂时沉寂下来，听我说：那是细节。

真正的问题是：你的老板要求你下周二就给客户演示这个系统；而客户并不关注你的实现细节，他关注的是你本月月底是否能Close Project。

软件工程首先关注的是以客户为对象的、整个工程的成败和质量。根本上说，技术性、重用性等等，只是保障工程成败与质量的手段而已。

 

所以编程语言的进化史其实就是软件工程思想的演化史。在过去的短短的数十年间，软件工程思想就经历了多次的演化变迁，而且还在不断发展。这里对这些演化阶段做一小结，希望能从纷繁芜杂的各种概念中理出一个脉络。

1.      混沌阶段

机械设计的计算机、面向机器的语言、汇编语言、COBOL、FORTRAN

2.      结构化阶段（面向过程）

C、Pascal等结构化编程语言

3.      面向对象

对象提供了一种处理复杂性的方式。这个问题可以追溯到亚里士多德：您把这个世界视为过程还是对象？在OO运动兴起之前，编程以过程为中心——例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统——我认为，这才是面向对象编程运动的真正胜利。（Booch）

4.      面向组件

面向组件提供了可交换的、可互操作的二进制组件。与共享源代码文件不同，客户端与服务器都支持二进制类型系统（例如IDL），以元数据的表示方式放入到封装的二进制组件中。组件在运行时被发现以及装载，例如拖动一个控件到窗体上，则该控件会在客户端机器的运行时自动被装载。客户端程序仅仅是服务的抽象与契约，称为接口。只要接口不变，服务就能够任意扩展。代理能够实现相同的接口，通过为远程调用封装底层机制实现无缝的远程调用。公共二进制类型系统的可用性使得跨语言的互操作性成为可能，这样，Visual Basic的客户端就能够调用C++的COM组件。重用的基本单元是接口，而不是组件，多态的实现是可互换的。通过为每个接口、COM对象以及类型库分配唯一的标识符可以解决版本冲突的问题。

然而，作为现代软件工程学的一个根本性突破，COM在大多数开发者的眼中却如鸡肋一般，食之无味，弃之可惜。.NET与COM存在的问题，不是概念上的错误，而是基于开发者必须编写大量的公共基础功能这一事实。

5.      面向服务

在2000年末，面向服务方法学作为应对面向对象以及面向组件缺陷的解决方案呈现在人们眼前。在面向服务的应用程序中，开发者只需要关注于业务逻辑的编写，以及通过可交换的、可互操作的服务终结点暴露业务逻辑。客户端调用这些终结点，而不是服务代码或者它的实现包。客户端与服务终结点的交互基于标准的消息交换，服务发布各种标准元数据，描述服务的功能，以及客户端调用服务操作的方式。元数据就是服务，相当于C++的头文件，COM的类型库，或者.NET程序集的元数据。服务的终结点是可重用的，在交互的约束（例如同步、事务以及安全通信）下，服务是与客户端兼容的，而与客户端的实现技术无关。

 

    从多个角度看，服务都是组件的一个本质上的飞跃，就像组件是对象的一个本质上的飞跃一样。在软件行业中，面向服务是我们目前所知的构建可维护的、健壮的以及安全的应用程序的最佳方案，也是最可行的方案。

 

在开发面向服务应用程序时，我们能够实现服务代码与客户端使用的技术与平台的解耦，也与并发管理、事务传播和管理以及通信可靠性、协议和模式无关。总的来讲，实现从客户端到服务的消息传递的安全，就是对调用者的认证，它属于服务范围之外。服务根据需求仍然要实现服务自身的本地授权。在大多数情况下，客户端并不知道服务的版本：只要终结点支持客户端期望访问的契约，客户端就不用考虑服务的版本。为了处理客户端与服务之间传递数据的版本兼容，面向服务同时还构建了版本兼容的标准。

既然面向服务框架为了将服务连接在一起，提供了现有的公共基础功能，那么服务的粒度越小，就越能够有助于应用程序对这些基础设施的使用，开发者所要编写的公共基础功能就越少。在极端的情况下，每一个基本的类都应该是服务，以便于最大程度地利用现有的互联性，避免编码实现公共基础功能。理论上讲，它能够轻松地实现事务型整数，安全字符串以及可靠的类。然而实际上，粒度过于细化会影响到使用的框架（例如WCF）的性能。 我相信随着时间的流逝，以及面向服务技术的发展，服务边界的内聚性会越来越强，服务的粒度会越来越小，甚至于每个基本的构建模块都可以成为服务。（当所有最小粒度的抽象都变成服务的时候，这是否意味着可以把这些最小粒度的抽象看成是资源，然后自然而然地过渡到ROA）显然，这是历史的发展趋势，那就是通过方法学的改进以及抽象，以性能换取效率的提高。

6.      面向资源

2000年Roy Thomas Fielding博士的那篇论文《架构风格与基于网络的软件架构设计》已经成为REST界的圣经。论文中详细讨论了资源的概念：

 

REST对于信息的核心抽象是资源。任何能够被命名的信息都能够作为一个资源：一份文档或一张图片、一个与时间相关的服务（例如，“洛杉矶今日的天气”）、一个其他资源的集合、一个非虚拟的对象（例如，人）等等。换句话说，任何可能作为一个创作者的超文本引用的目标的概念都必须符合资源的定义。一个资源是到一组实体的概念上的映射，而不是在任何特定时刻与该映射相关联的实体本身。

 

更精确地说，资源R是一个随时间变化的成员函数MR(t)，该函数将时间t映射到等价的一个实体或值的集合，集合中的值可能是资源的表述和/或资源的标识符。一个资源可以映射到空集，这允许在一个概念的任何实现存在之前引用这个概念——这一观念对于Web之前的大多数超文本系统来说比较陌生。一些资源在它们被创建后的任何时刻来检查，它们都对应着相同的值的集合，从这个意义上说它们是静态的。其他的资源所对应的值则会随时间而频繁地变化。对于一个资源来说，唯一必须是静态的是映射的语义，因为语义才是区别资源的关键。例如，“一篇学术论文的创作者首选的版本”是一个其值会经常变化的映射；相反，到“X会议学报中发表的论文”的映射则是静态的。它们是两个截然不同的资源，即使某个时刻它们可能会映射到相同的值。这种区别是必要的，这样两个资源就能够被独立地标识和引用。软件工程领域中一个类似的例子是版本控制系统的源代码文件的单独标识，这些标识可以是：“最新版本”、“版本号1.2.7”，或“包含有Orange功能实现的修订版本”。

对资源的这一抽象的定义使得Web架构的核心功能得以实现。首先，它通过包含了很多信息来源而没有人为地通过类型或实现对它们加以区分，从而实现了通用性。其次，它允许引用到表述的延迟绑定（late binding），从而支持基于请求的性质来进行内容协商。最后，它允许一个创作者引用一个概念而不是引用此概念的某个单独的表述，从而使得当表述改变时无须修改所有的现有链接（假设创作者使用了正确的标识符）。

 

在此基础上， 有人提出了ROA（Resource Oriented Architecture）的概念。从本质上讲，ROA是OO和SOA概念杂交的产物，采用了OO中的结构以及SOA中服务接口概念。不管其前景如何，这种概念确实提供了一种架构选项：

 

REST 内含一个架构的精神，或许可称之为 ROA，而它的设计哲学，不见得是面向对象已深化心中的人能在短时间内完全领略。OO 和 RPC 的设计方式往往通过方法或函数调用来达成一件事，而在 SOA 之下，某个业务功能可通过服务操作 (operation) 来建模，落到技术层面，则可很轻易地对应成以一个方法或函数来实现。例订单查询，可以通过一个幕后是 Java 方法的 Web service 来接受用户请求，用户端，也就是服务消费者，将订单序号作为参数，放在请求里面。在这种设计模式之下，主角是及物动词，也就是对订单（受词）的查询动作；但如果要改用面向资源的观念、也就是 REST 理念来设计的话，主角会是那千千万万笔的订单，也就是名词 －每笔订单都有一个独特、专有的 URI/URL 来识别，据以对它们进行各别的查、增、删、改。ATM 也举过一个例子，她说如果用 REST 来设计灯光控制的应用，那你的房子里面的每一个灯泡都必须有一个独特的 URI，然后对每盏灯发送开/关的控制信号；而不是通过一个统一的灯光总控来进行控制。看一个自然语言的例子，要表达类似的意念，我们可以说：“我不（太）同意你的看法”，但也可以说“我和你的看法不同”，前者以动词为重心的表达方式，较为强烈而单刀直入，后者以名词为主题的表达方式，让人的感觉较为婉转，REST 在设计上的体现，也有这种婉转的味道。