“软件蓝领”批判
撰文/透明
说在前面
最近一段时间，“软件蓝领”的概念被炒得沸沸扬扬，连我老爸都忧心忡忡地打个电话问我：“听说以后只要找些高中生来培训两个月就可以编程序，那你岂不是要没饭吃？”由此可见，尽管“软件蓝领”的阶层尚未真正形成，“软件蓝领”这个概念倒是早已深入人心。不过就历史经验来看，中国人最擅长逻辑思维，因此也最容易受语言的鼓惑而陷入逻辑先验的泥潭。那么，抛开所谓的“概念”，我们来科学地看看“软件蓝领”。
在开始一切的讨论之前，首先要说明一点背景。本文将大量使用建筑科学与软件科学作类比，这是基于这样的考量：软件工程学很大程度上受到建筑科学的影响，并且软件比建筑物更具灵活性；因此软件与建筑是有可比性的，但是软件对感性质量的要求会更高、而对物理质量的要求则不如建筑那么高（我想这是很自然的：尽管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 Building，Christopher Alexander著，中文译本由赵冰翻译，知识产权出版社2002年2月出版。
《设计模式》，原书名Design Patterns，Eric Gamma等人著，中文译本由李英军等人翻译，机械工业出版社2000年9月出版。
Robert C. Martin, Designing Object-Oriented C++ Applications Using Booch Method, Addison-Wesley, 1992.
