享受代码,享受人生

SOA is an integration solution. SOA is message oriented first.
The Key character of SOA is loosely coupled. SOA is enriched
by creating composite apps.
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

当前软件开发的反思

Posted on 2005-07-08 21:56  idior  阅读(3530)  评论(25编辑  收藏
积木


很久以来我们一直追求象搭积木一样
,象生产工业产品一样去生成我们的软件. 在面向对象出世之际我们以为我们找到了答案, 当它给我带来失望的时候,我们又将希望寄于组件技术, 然而迄今为止我们仍然无法实现我们的梦想.

面向对象技术在Design by Contract的指导之下, Design to interface几乎变成其代名词. 然而可以看到在利用接口实现问题的分解之后, 我们剩下的是什么? 将分解组合起来, 形成我们所需要的软件! 可是这个时候问题来了, 怎么组合? 如果是你自己分解的零件还好, 如果不是呢? 分工可是大工业生产的必要条件.

组件之间如何通讯?Corba, DCom以及后来的RMI, Remoting, 这些解决方案都牢牢的定死了组件实现的平台, 使得他们之间的交互成为枉然.

而组件自身无法提供足够的描述信息, 更使得装配式的生产成为遥不可极的梦想. 尽管在Java.Net中都提供了一些metadata, 但是诸如方法,属性如此少的描述信息又怎么能让我们从如此多的对象中找到适合我们的需要的零件. 对象之间的依赖关系?谁主谁从? 对象如何通讯? 同步异步? 对象的信息如何修改? 直接间接? 如此多的信息, 目前的metadata远远无法提供.

记得小时候想玩一个钟, 结果拆了之后却再也装不起来, 就丢在那了. 面向对象呢?...

通用

目前的开发方法与技术给了我们过多的自由, 使得我们可以在此基础上开发出几乎所有的应用. 但是当前大多的应用需要这样的自由吗? 看看下面的应用:

首先从数据库读取相应的数据, 把数据以一定的业务规则展现给用户, 而用户在获得数据的同时可以在一定的业务规则下修改这些的数据,最后将修改后的结果写入数据库.

我不知道有多大比例的应用符合上面的模式. 相信各位心中会有自己的答案.

我们获得了自由, 但是与之而来的也有复杂, 并且我们还失去面对变化的能力. C#JavaC,C++相比,让我们不用再理会复杂的内存管理等等底层的技术问题, 让我们更多的关注于所要解决的业务问题. 但是C#, Java是否也太通用了呢? 我们在摆脱了内存管理后还是要关心对象的生命周期的管理, 对象的持久化, 对象的显示等等技术问题, 他们并不是业务问题但是却与业务逻辑纠缠在一起, 想想你编程的时候有多少时间是花在这些技术问题上的. 或许我们需要摆脱某些自由来获得更多的方便.

看过勇敢的心的人无不被最后的”Freedom!”感动, 然而你能做到华莱士那样吗? 想想自己去喊 ”C” “Assemble” “01…”的样子

模型

UML 看似成功的建模语言, 仔细想想它在软件开发中的作用.

我个人平时喜欢写一些有关设计的随笔, 这时常常会用到UML. 如果你问我用它干什么, 我会说是为了形象化的说明我的意图,我的代码. 也就是说UML仅仅起到了文档的作用. UML是可以描述对象模型, 但是仅仅是从文档的角度而已, 程序员之间的交流手段. 它不是开发用的模型! 我们有用于开发的模型吗? 你知道吗?...

总结

有多少人(或公司)曾经将完成的软件做过好的总结, 请举手. 我个人目前还没有一个让我敢回首的软件(当然个人经历太少,才学了4年而已,各位肯定有自己的得意之作). 不过我相信大家对这个问题的答案足以让很多人脸红.

其实这又何以责怪程序员, 目前的纵多开发方法中又有几个提到了如何使用已有的软件产品(组件, Pattern…), 以及开发后如何从产品中提炼出通用的产品(组件,Pattern,产品线…). 在以满足需求为第一指导原则的软件开发方法中哪里考虑过这些问题? 既然开发方法都没考虑, 那么程序员又怎么会去考虑呢? 更何况,由于水平问题和我一样不敢回首自己作品的程序员比比皆是. 再说了, 你会总结吗? 怎么记录Pattern? 谁知道好的方法?

在高中读书的时候, 经常会做总结, 那时成绩比较好, 现在上了大学, 好像真的很少做了, 难怪考试不行了.

待续

参考资料:  <<Software Factory>>