去年到今年网上一个很热门的概念就是SOA（面向服务的架构），它真的是系统构建的最后的盛宴吗？日益复杂庞大的系统要求我们的各个部分都能够非常稳定的工作，在OO之后的组件，然后是构建之类的越来越大的封装，使得我们越来越想构建软件系统像构建楼房一样，但是建筑业经历了几千年的沉淀，其组件的结构和功能相对简单一些，而软件系统，其结构和功能千变万化，而且其需求的易变性往往是建筑不可比拟的，可以说需求随时在变化，使用大型的组件构建系统有它的好处：成熟、稳定，缺点是由于足够大，在可能不满足需求的情况下要进行修改几乎是不可能的；但是选用小的组件，需要学习的内容很多，没有足够的现成的功能，需要自己进行扩展，可能不够稳定，但是好处是在可控的范围内，遇到问题可能自己就可以解决。软件业总的趋势是组件越来越大可能是不可逆转的，但是决不是朝夕之间的事情，而且随着各种规范的出台，基于规范的系统构建将变得简单一些，不再需要对各种组件的不同特性分别学习，而是基于规范进行构建。在这个理想变成现实之前，我们还是需要自己来构建我们的系统，在开发的过程中我们可以有意识的将功能通用化，可以在其它的项目中公用或者给别人使用，apache基金会的做法是值得推荐的，在一些项目的开发过程中产生了很多更小的项目可以为其它的项目所用，jakarta的commons项目系列就是一个很好的例子，但是国内好像做得远远不够，最重要的是似乎并没有意识到这个问题，这个才是最可怕的。就我所参与过的一些项目而言就存在这个问题，而且很严重，每个人在遇到一个他不知道的功能时大部分情况下选择的是自己开发，而不是询问别人是否已经解决了，即使自己完成了，也仅仅是针对自己的问题，没有想到去通用化，即使做得比较通用，也不会写个文档或者邮件告诉别人如何用，在什么情况下用，而别人呢，可能也不大愿意用，这个实在是很多软件开发团队的最大的弊病：重复工作。我们首先应该从思想上解决这个问题，然后是从工具上解决，因为这样的共通功能太多了后如何查找需要的功能就是一个很大的问题。也许JR应该组织开发一个这样的知识管理系统？