CSDN博客

img gigix
博客专家

“软件蓝领”批判

发表于2002/5/9 13:17:00  2598人阅读

“软件蓝领”批判

撰文/透明

说在前面

最近一段时间,“软件蓝领”的概念被炒得沸沸扬扬,连我老爸都忧心忡忡地打个电话问我:“听说以后只要找些高中生来培训两个月就可以编程序,那你岂不是要没饭吃?”由此可见,尽管“软件蓝领”的阶层尚未真正形成,“软件蓝领”这个概念倒是早已深入人心。不过就历史经验来看,中国人最擅长逻辑思维,因此也最容易受语言的鼓惑而陷入逻辑先验的泥潭。那么,抛开所谓的“概念”,我们来科学地看看“软件蓝领”。

在开始一切的讨论之前,首先要说明一点背景。本文将大量使用建筑科学与软件科学作类比,这是基于这样的考量:软件工程学很大程度上受到建筑科学的影响,并且软件比建筑物更具灵活性;因此软件与建筑是有可比性的,但是软件对感性质量的要求会更高、而对物理质量的要求则不如建筑那么高(我想这是很自然的:尽管Windows不断打补丁,它仍不失为一个优秀的软件;而盖房子则不允许有任何“补丁”出现)。如果你不能承认这一考量,那么下面的文字对于你都是废话,可以不必看下去了。

一点背景

OK,现在我们已经有了起码的共识,继续。传统软件工程方法强调软件的“模块化”,认为用少数的、规格统一的模块(module)加上简单的模块拼装就可以构建出大量的、彼此不同的软件产品。这正是软件蓝领能够产生、存在的理论基础。其实这种概念并不新鲜,自从第二次工业革命以来,建筑师们就开始追求一种快速的、模块化的建筑方法,并且卓有成效——他们用完全相同的“小格子间”模块建起了无数的摩天大楼。这是伟大的成就,难怪软件工程专家们一开始就选定了“模块化”作为自己模仿的对象。而且,当软件的用户只是极少数人的时候,这种模块化的开发方法的确起到了很好的效果。

但是你知道在70年代,以Christopher Alexander为首的建筑学家把这种模块化建筑方法叫做什么吗?“语言的沦丧”。C.Alexander认为,建筑物之所以“有生气(alive)”,是因为它由一些特定的、有生气的模式(pattern)组成。模式之间彼此相似,但又彼此不同。道理很简单:模式具有可定制性,而模块则不具有。完全相同的模块必定是与具体目的无关的。换句话说,用模块化方法方法建造的产品能够满足最基本的要求,却不能满足任何一个人的特定要求。为了满足单个人或者一小组人的要求,就必须采用模式化的方式为他们定制。模式是既有的,设计、建筑是定制的。有人会说:任何的物质,最终都是由同样的模块——原子——构成的。但是,即使是两个碳原子,它们也是彼此不同的,因为其中的电子具有量子性。所以,模块化(所有模块完全相同)不是自然的,而模式化(概念上一样,细节上有差异)才是自然的。

上面这一段也许有点太抽象,现在从工程学的角度来看看。C.Alexander认为,任何一个系统都必须处理一个问题:系统的内应力。学过工程力学的人都知道,在设计结构时必须注意内应力。如果内应力疏解得当,它会使系统更加稳固;如果疏解不当,它会加速系统的崩溃。在《建筑的永恒之道》里,C.Alexander把“内应力”从物理范畴扩展到了心理范畴,人的喜好、习性……都属于内应力。如果使用恰当的模式、进行恰当的组合,内应力将得到恰如其分的疏解,从而增强系统的稳固性。很明显,要使内应力得到“恰如其分”的疏解,建筑者必须了解模式本身,并在实现的过程中不断根据当前的情况进行微调,否则很容易造成应力集中而加快系统崩溃。

(在这里插上一段。C.Alexander认为:好的模式应该在其内部处理相关的内应力;好的模式组合应该在其之间恰当地疏解内应力。这个观点是不是和开放-封闭原则很相似?是不是也有点象高内聚/低耦合的原则?所以说,各种科学之间都是相通的;所以说,建筑学对软件开发者绝对有指导意义。)

然后,C.Alexander也提到了设计和实现之间的关系。他认为:一个具有了模式思想、掌握了模式语言的人可以作出优美的设计,这个设计是能够满足他的要求的;但是,如果设计的实现者没有模式思想、没有模式语言,他便不能完整地实现该设计。而且,从最简单的方法,他会采用模块化的实现方法,从而使产品的质量迅速降低。

回到正题

总结一下,我刚才讲了三件事:

1.       模块化方法不能满足任何人的特定要求,只能满足所有人的最基本要求;模式化方法是根据特定要求而定制的,所以能满足客户的要求。

2.       模块化方法不利于疏解系统内应力,从而使系统趋于崩溃;模式化方法利于疏解系统内应力,从而使系统具有自适应能力,趋于稳固。

3.       模块化实现方法使设计质量降低;模式化实现方法保证产品质量与设计质量一致甚至更高。

我相信大家都能看懂我的意思了。由于软件对于感性质量的要求更高,对于物理质量的要求较低,所以模块化方法更加不适宜于软件开发;而模式化方法则更加适宜于软件开发。另一方面,从我上面的叙述大家也能看出:模式化开发要求开发者有对整个系统的全面了解,有足够的知识广度和深度;而所谓的“代码工人”、“软件蓝领”只能进行模块化的开发,他们的知识无法保证他们现实的需求作出正确的微调,因此他们开发出的模块极易造成应力集中。在建筑学中,模块化方法建造出的产品只能满足最基本的要求,那就是物理性质的要求;而软件产品对于物理性质要求更低,而对感性质量要求更高,所以模块化方法建造出的软件产品连最基本的要求都可能无法满足。

上面讲了许多建筑学知识,最后再从软件科学的角度来说说。我们都有知道:软件中的可复用模块是被很多其他功能部分共享的,也就是说,很多功能部分依赖可复用模块。如果可复用模块再依赖这些使用它的功能部分,那么它必定是不稳固的,因为任何一个部分的修改都可能导致连锁反应。所以,可复用模块必定是不依赖于功能部分的,否则它便不具有可复用性。很明显,这样不依赖任何特定功能的通用模块数量会很少,而且设计要求极高——设计STL绝对不是“软件蓝领”能做的。从上面的结论可以得知:可复用的模块设计要求极高,用可复用模块拼装成的功能部分又不具有可复用性(因为它依赖于特定的应用)。那么,没有深厚知识底蕴的“软件蓝领”们该何去何从?

总结

软件工程和建筑工程有很多共通之处,上面我用一些建筑学的知识,证明了“软件蓝领”的不合理性。当然,“代码工人”这个词本身便带有建筑学的影子。但是请注意两个事实:第一,软件工程中的科技含量远远高于土木工程;第二,软件开发中重复性的劳动很容易用机器代替。由此,我更加可以肯定:所谓的“代码工人”、“软件蓝领”——也即不具有深厚专业知识底蕴,只有编码能力的程序员——在软件行业中是无容身之所的。

参考资料

《建筑的永恒之道》,原书名The Timeless Way of BuildingChristopher Alexander著,中文译本由赵冰翻译,知识产权出版社20022月出版。

《设计模式》,原书名Design PatternsEric Gamma等人著,中文译本由李英军等人翻译,机械工业出版社20009月出版。

Robert C. Martin, Designing Object-Oriented C++ Applications Using Booch Method, Addison-Wesley, 1992.

0 0

我的热门文章

相关博文

img
取 消
img即使是一小步
也想与你分享
打开
img