软件开发还远不是一种“科学”

很多大学里是把软件开发相关的专业划入工科的，这给人一种错觉，让人认为软件开发也是一个工程学科，就像土木建筑，动力机械那样。

但这从根本上错了，土木建筑，动力机械的背后有确实的科学定律作为支撑，而软件开发的背后基本上什么都没有，远不是一种“科学”。

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

每个人对“科学”的定义可能不同，但在这里，我们可以做一个简化版的定义：

当有一组在限定条件下颠扑不破的定律做支撑时，相应的知识，我们可以称之为科学，科学自身可以体现为一种确定性。

比如说：牛顿的力学定律在低速时是不容违反的，是一种铁则，那基于此的各种知识就可以成为科学。

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

面向对象应该是接受程度最高的分析和设计方法，但即使如此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... ...(编程语言就更不要说了，实在不知道有多少个，但反过来想，世界上真需要这么多种语言么？)

这些不同的方法（概念或语言）只要存在，即使彼此有冲突，也必然有其合理之根基，这里无意分析其优劣，

只是想说：软件开发的定论在那里？我们究竟又该根据什么来判定那个是适合的，那个是不适合的？这种众说纷纭，真是工程学科应该有的状况么？

如果所有这一切都只能归还给当事人，那就必然纷争不断，软件开发也就一定不是一种科学。

在这样一种情景下，由于任何人都可能是错的，务实的程序员也就必须选择相信自己多过相信别人，那怕别人有天大的来头。

相信自己基于事实和逻辑的分析，即使错了，也可以成为一种进步的养分；相信别人，错了不会进步，对了也是别人对了，有什么意思。

狂妄的程序员则可以挑战“牛顿”这一角色。

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

横尽虚空，山河大地无一可恃，而可恃唯我。

竖尽来劫，前古后今无一可据，可据者唯有当前。

补充一下，我发现这篇文章有争议的原因在于每个人理解中的科学的定义不同。

我是使用何新先生的定义的，参见《关于意识形态，学术，科学和真理》

关联文章：

软件开发是究竟是简单的还是复杂的

软件本质论

------------------------------------------------------------------------------------------------------------------------------------

理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。