程序员需要SOA吗？----SOA业务开发平台(二)

我93年开始学习编程，当时求伯君，朱崇君，吴晓军已经名满天下的，估计不少新一代的程序员，除了求伯君和金山在，其他的两位，许多人都已经不认识了。我还用过五寸盘，但当时三寸盘已经流行了。WIN3.1让人羡慕。

当时，显卡，CPU，内存都极为简陋。写程序必须对这些资源都吹毛求疵，想尽各种脑汁对付这个一穷二白的机器。也没有现成的图形库和算法库，现在对DirectX的进化尤其羡慕。

当时，面向对象，我还不知道为何物。目的，就是想写个游戏软件，省得我老给游戏厅老板送钱。

一直在乱写代码，代码多了，自己都if..else的绕的头疼，于是把代码分段，分成函数。对于客户来说，当然没啥感觉，反正他又不认识代码，他也不想看代码，用功能就是了。但是对于自己维护代码，修改代码，增加新功能却好很多，因为阅读容易了，所以写的就快了。但过去也是瞎分函数，其实就是感觉太长，理解起来脑子不够使了，就分成函数了，其实函数之间还是用公共变量连在一起，后来才发现了问题严重性，公共变量被函数赋值来赋值去，把我自己都搞晕了，都弄不清楚目前这个变量是什么值，当然程序的稳定性就没有了，为了调试错误花了我大量时间，客户也不满意，给收入带来了影响。想，怎么能解决这个问题呢，怎么不让函数间纠缠不清呢，于是下功夫冥思苦想函数的发源，用意。过去认为自己写个function就是函数了，其实只有函数的形，没有函数的神，函数根本没有起到函数的全部作用，只是让阅读看起来容易了一些，但是由于函数间用公共变量联系在一起（没办法啊，函数之间肯定有逻辑关系，当时想到的自然是公共变量的方法，但居然现在还有不少程序员在犯我93年的问题）。

过去也没有互联网，也没有现在发达的图书出版业，也没有现在众多的程序员，只能自己苦想，最后才在计算机课本上看到真正的函数描述。唉~~，平时觉得课本无用，到了要讲真功夫的时候，发现自己苦找的原来就在身边就在课本上（现在不少计算机专业的学生都说学校课程无用，让人叹息呀）。琢磨课本，于是才真正开始使用函数。函数，就要封装，自我封闭。有输入，有输出，才叫函数。函数对外是黑盒子，只要安心调用就是了，函数内部怎么申明变量，怎么给变量改变值，是函数自己内部的事情，函数自己负责自己，别的函数根本不用操心自己调用的其他函数的内存创建呀释放呀什么的，让函数之间尽量关联越少越好，就是通过函数的参数入口来联系彼此。

这下，修改代码，只修改某几个函数，增加功能，也是增加几个函数，函数之间耦合低，所以代码写的也稳定，写的也快了，阅读也快了。对于客户来说，他不知道我发生了什么变化，但是他能感觉得到我的软件稳定，修改的也快了，客户的满意度又回来了。这就是面向函数的好处（虽然没有人提面向函数这个词）。

函数是用的美不滋儿了。但问题又来了，函数太多也闹心啊。没封装函数前，是代码大流水让人脑子想不清楚了缺氧了。现在封装了函数，函数多的这个函数调那个，那个又调另一个，照样缺氧了。尤其要维护的时候，打开源代码，一片片的函数，都不知道这么多函数是个什么关系，到底要重点看哪些函数，哪些函数从属哪些函数？现在都是平辈儿，谁都分辨不出来。又闹心了。

96年，开始学习DELPHI，人家都面向组件了，自己的思维还不知道。自己连面向对象的概念都没有。但类啊什么的，倒是有耳闻了。但和过去用函数之前一样，只知道形，不知道神。用了很久DELPHI，也是只用人家的类和人家的组件，自己写点东西，还是函数。知道函数闹心，但也没想到用类去解决。

最后开始安心读DELPHI的类库源代码的时候（当时是自己也想做个组件，呵呵，连面向对象都没用过，就自己想面向组件？但当时自己根本没想到面向组件这一说法），越读越深，越读越感觉人家这代码写的好。但仍然愚蠢的不知道人家使用的是面向对象的妙处，只是自己立志也要写这样的代码。于是照猫画虎学着人家的样子写。这就是我开始面向对象的第一步，其实自己都不知道自己已经在面向对象了。

不知道是学人家DELPHI的类库作者高手的源代码的原因，还是自己应用面向对象的原因，反正过去函数扎堆成群的问题缓解了，我的软件稳定性又回来了，修改的也快了，客户的满意度又回来了。唉~~，每一次代码规模的扩大（没办法不成规模扩大呀，现在业务越来越复杂，当然代码越来越多），都需要一种方法解决问题。

写着写着，就自己开始琢磨了，为什么这样写会代码好维护，过去写了成群的函数就不好维护了。就开始自己对比自己写的过去的函数代码和现在照猫画虎的面向对象的的代码。哦，原来是把一些函数都分级了，有私有，有公共，有这个类，有那个类。原来是把过去200个函数，又切割分块了，就如同过去把1000行代码分割一样。

当然，各位看官又想到了，面向对象也不灵了，代码太多了，类太多了，又需要一种新的方法解决问题啦。不好意思，确实想说这句话。

自己回想，还是函数太多，还需要封装。阅读人家DELPHI源代码，人家用了一个新关键字，叫属性。这个属性有两种，一种是事件，我理解它是一种切入式编程，一种是正宗的属性。原来，人家用属性隐藏了函数。一个属性，可以有读的函数，也可以有写的函数。我过去是暴露了两个函数，人家只用了一个简单的属性就搞定，把函数都藏起来了。代码简单多了，调用也简单多了，容易理解多了，自己阅读代码也不需要关注那么多函数了，代码之间的关系关联性也更容易可见了。看来，还是需要继续多写代码，不多写代码，就遇不到问题，不多写代码，就琢磨不透现在这些技术到底是解决什么问题的，就无法深刻理解现在这些技术的精妙之处。还要继续多写代码，多琢磨代码。谁理解不透，就说明谁写的代码还是少。

？？真是奇怪，面向函数，面向对象，面向组件，居然这样？每次都是增加一点点新的东西，就换个名字？就这么简单？但确实挺管用，解决了自己头疼的代码多的问题。代码一多，脑子就不够使，就不容易阅读理解，不容易下手修改，当然改了也是不知道能不能稳定（能稳定才怪，自己都看不懂代码，还想稳定？）

从面向函数，面向对象，面向组件，发现自己的代码被越封装越高了。就如同过去写程序，我们需要调用各种WINDOWS API，最后DELPHI把API封装成各个类库，有的更封装成了组件，如ADO组件和IP组件，就简单多了。写代码快多了。

但是，还有人不满足（当然也包括我）。大家不知道有没有这样的感受，组件拖拽，确实开发进度比过去是快了许多，但是现在的组件是越做越复杂，N多的属性，N多的方法，N多的事件，我要干某个工作，我不知道哪几个属性互相配合才能有效达到目的，一拉开属性查看器，看见滚动条和折叠起来的更多的属性配置就头大，心想怎么现在的东西这么复杂。

没办法，吃了馒头还要吃蛋糕，人的欲望是无穷的，这都还嫌不好。心想，如果我做某件事，传几个参数，OK，就能达到我的效果那该多好。别让我再配置这个属性那个属性，让我调用这个方法那个事件的。

看来，需求越来越复杂了，代码规模越来越大了，程序员必须加快工作效率才能应付的上，现在组件变的越来越复杂，程序员的编写代码速度与客户的变化速度不匹配了，唯有封装的更高。一个函数就搞定的。

嗯。面向服务出现了，一个函数就搞定，内部组件的属性如何改变，方法如何调用，那是组件内部的事情了。