我所理解的计算机(三) 之 大型软件开发与摇滚乐

          人们有把世界上的东西尽可能数字化的倾向，但是世界是多样的，相对而言程序的表达方式是单一的，程序只拥有用一个个过程和数据结构组成的描述手段。在相当程度上，这与人们观察现实世界的习惯有偏差。使用过程化语言写应用逻辑程序有点像用钳子拧螺丝，除了用拧力还得握紧，不如使用扳子趁手。某个东西作为独立的客体，区别于其他的东西，必然带有一定自给自足和封闭的特征。所以产生对象的概念是自然的，在面向对象的编程中，程序员可以使用封装、继承和多态等新的描述手段。

         最早的面向对象的语言是smalltalk，它到现在也是非常成功的语言，仍然不断有新的思想从smalltalk社区里冒出来。最重要的面向对象的语言要属C++了，它C语言扩展而来，并且兼容了C语言。兼容就意味着让众多的C程序员更容易接受C++，但也意味着复杂、难用。（传言C++之父Stroustrup说过他发明C++的动机是C太容易学习了，所以C程序员难以拿到高薪）。不过与其说面向对象的语言多么难用，不如说程序员懒得改变他们旧有的写程序的方式，我能看到无数的人虽然用C++，但是仍然在用C的方式写程序。

         新的思想普及需要时间，但是语言工具的更新换代已经引起了巨大变化。企业应用中针对业务逻辑开发程序越来越多使用了对象化语言。使用对象技术的经验也形成了程序员交流时津津乐道的模式（Pattern），新的独特的词汇集合（对象工厂、访问者……）正不断形成和扩大。

        面向对象语言编程和关系数据库是我接触最多的两个东西。但是它们有着著名的不匹配关系，一般关系数据库只支持基本数据类型存储，而对象中的引用、继承这些概念在关系数据库里是没办法表示的。现在正讨论的热火朝天的OR（Object Relationship）mapping技术就是试图直面这个惨淡的问题。企业级的数据库也开始在数据库内部为支持OR mapping做相应的扩展，对外宣称叫做对象数据库。这些努力会给程序员带来一些方便，但是问题还远没有达到解决的程度。

         对象技术应用到桌面窗口开发的最引人注目的成果是RAD（Rapid Application Development）开发方式，设计开发界面程序的程序员可以在一个所见即所得的环境中，通过拖动界面元素进行可视化的开发。这使得桌面程序员的门槛进一步降低，造就了大量速成程序员。

         使用面向对象的程序语言，可以在语言一级操纵各种对象。但是不同语言中对象的实现是完全不同的，不同语言的对象虽然概念类似，却是老死不相往来。如果把对象的概念超越语言的限制，形成各种语言都能使用的东西，就产生了组件。组件要么是有二进制的标准形式、要么是在各种语言的要素之间定义一个映射。不过需要使用组件的地方并不是那么多，因为并不是谁在各种场合都用多种语言写程序。鼓吹组件的人还经常提到它给软件重用带来的好处，我觉得只能当成传奇故事听一听，不当真的时候还挺美妙的，如果不小心相信了，那麻烦可就大了。

        上世纪有个大事叫“软件危机”，是说当软件变大的时候，往往就失去了控制，经理就不知道什么时候完工、能不能完工。出现了很多失败的工程，用户对软件产生了信任危机。为了挽回赖以生存的声誉，程序员们提出了软件工程的说法，就是用管理盖大楼的成功经验来管理软件开发能够解决这个问题。潜台词就是说不是程序员无能，实在是经理太差了。其实根本不是什么“软件危机”，应该叫程序员危机，反映出的是程序员在必须协同工作时交流、表达和妥协能力的欠缺和没有经验。这种欠缺根源于程序语言表达能力的欠缺。所以工程是个伪问题，问题的解决需要工程团队的每个人都认识到产生问题的根源，并能把各自的收获转化成团队的共识。

        在程序员们多年协同工作的过程中，积累下来了非常多宝贵的经验教训。软件工程如果是有效的，那么它必定是充分利用了已往程序员留下的积累，并且在不断的沉淀和丰富这个积累。列举一下软件工程领域里比较出名的几样成果：并发版本控制工具（CVS）、统一建模语言（UML）、自动测试工具。现在很少有项目在不使用这些东西的情况下还能取得成功。每个程序员都在使用的集成开发工具（CASE）里，现在基本上都集成了上边提到的工具。如果不会用的话，作为一个程序员还是很没面子的。无论是注重过程的传统软件开发过程，还是注重源代码的极限软件开发过程，它们的理念都具体体现在使用的工具和使用工具的方法和习惯上。