软件开发还算不上是一门科学

很多大学里是把软件开发相关的专业划入工科的，这给人一种错觉，让人认为软件开发也是一个工程学科，就像土木建筑，动力机械那样。但这从根本上错了，土木建筑，动力机械的背后有确实的科学定律作为支撑，而软件开发的背后基本上什么都没有，远不是一种“科学”。

也正因此，“软件工程”的现实意义也就远不如“土木工程”，“动力工程”。

每个人对“科学”的定义可能不同，但在这里，我们可以做一个简化版的定义：当有一组在限定条件下颠扑不破的定律做支撑时，相应的知识，我们可以称之为科学，科学自身可以体现为一种确定性。比如说：牛顿的力学定律在低速时是不容违反的，是一种铁则，那基于此的各种知识就可以成为科学。

从这个视角出发，我们会发现，在软件的世界里，压根找不到属于软件的“牛顿力学定律”，有的只是杂多、纷争和不确定性。

面向对象应该是接受程度最高的分析和设计方法，但即使如此Eric?Raymond和Linus也仍然会站出来批判它。

参见：

• Eric?Raymond谈模块化原则，胶合层和面向对象的缺陷?孟岩译?http://blog.csdn.net/myan/article/details/1924?
• C++一无是处?http://news.csdn.net/a/20100612/218785.html?

简单来讲：Eric?Raymond认为OO会导致过度分层，Linus认为面向对象解决的是一些小问题，他们不约而同的反对OO。你能找到如此批判牛顿定律的人么？

但Eric?Raymond他们的观点又不由得你不重视，除非你认为Eric?Raymond和Linus信口雌黄或人品有问题，否则你可以批判，可以不同意，但你不能忽视他们的声音。他们的声音必然基于他们的经历，代表着特定的现实，而现实本身代表合理性。

面向对象之外，各种观点想法就更多，这导致了软件的世界是杂多的，不确定的，行业中人大多都为名词所苦。

随便看一下吧，有多少人可以精确分辨这些词间的差异：

• 框架(Framework)
• 架构(Architecture)
• 面向对象分析和设计(Object?Oriented?Analysis?and?Design)
• 设计模式(Design?Pattern)
• 契约式编程（Design?by?Contract)
• 测试驱动开发(Test?Driven?Development)
• 面向方面的编程（Aspect?Oriented?Programming)
• 模型驱动架构（Model?Driven?Architecture)
• 基于组件的开发（Component-Based?Development）
• 敏捷软件开发(Agile?Software?Development)
• 元编程(Meta?programming)
• 面向服务的体系结构（Service-oriented?architecture）
• Feature-oriented?programming

?编程语言就更不要说了，实在不知道有多少个，但反过来想，世界上真需要这么多种语言么？

这些不同的方法（概念或语言）只要存在，即使彼此有冲突，也必然有其合理之根基，这里无意分析其优劣，只是想说：软件开发的定论在那里？我们究竟又该根据什么来判定那个是适合的，那个是不适合的？这种众说纷纭，真是工程学科应该有的状况么？

如果所有这一切都只能归还给当事人，那就必然纷争不断，软件开发也就一定不是一种科学。在这样一种情景下，由于任何人都可能是错的，务实的程序员也就必须选择相信自己多过相信别人，那怕别人有天大的来头。

相信自己基于事实和逻辑的分析，即使错了，也可以成为一种进步的养分；相信别人，错了不会进步，对了也是别人对了，有什么意思。狂妄的程序员则可以挑战“牛顿”这一角色。

?杨昌济先生，曾经说过两句话，特别有意思，也契合软件开发的情景，因此把它放在这里，作为结尾：

1. 横尽虚空，山河大地无一可恃，而可恃唯我。
2. 竖尽来劫，前古后今无一可据，可据者唯有当前。

本文地址：http://www.nowamagic.net/librarys/veda/detail/962，欢迎访问原出处。