重用之梦破灭了吗?

重用的软件的美梦,在过去20年中,几乎所有的主要技术都自吹自擂是可重用的。但是现实如何呢?

重用本来是节省软件开发,在90年代早期,面向对象说可以做到,但是却没有,到90年代后期,面向构件的开发说可以做到,但是也没有,往后,SOA说可以做到,还是没有,为什么重用如此之难?
Reuse: Is the Dream Dead?提出了自己看法,那是因为有一个公式现象:

Maximizing reuse complicates use.

重用越高,越难以使用。

作者认为越是重用度越高,就越复杂,复杂导致难于继续使用,如今各种框架如 Web frameworks, ORM frameworks, 和 security frameworks 等等名目繁多,但是他们都是水平方向,而非垂直方向,他们只是侧重基础底层和管道性代码,而非业务逻辑,所以,作者认为的垂直方向是从业务组件入手。

个人感觉这个方向是对的,就象DDD领域驱动设计就是从业务建模入手,DDD中也提出了模块化概念,一个模块可以包括一个聚合边界。那么。让我们来看看作者的业务组件入手,有哪些概念?

Granularity粒度
粒度是一个重要原则,但是粒度粗细很难衡量,作者认为:粗粒度构件更容易使用,而细粒度组件则更加易于重用,这是一对矛盾。

Weight重量
轻重是表示一个构件所依赖的环境范围,重量很依赖它的运行环境,而轻量则没有这种依赖,当构件需要在不同环境下运行时,我们通过配置来实现,跨环境重用越多,配置越多,导致每次使用配置麻烦,易用性差。

轻量构件更易于重用,重量构件更易于使用。

作者提出观点:如何在重用和易用之间取得一个平衡,根据实际情况进行取舍。

个人认为,作者只是提出了问题,没有直接给出解决方案,导致这种矛盾现象还是与松耦合粒度细分方法有关,到底按什么标准来粒度细分,面向对象过去提出按照Class结构来,现在面向函数提出按照functional功能来。

说白了一句话,如何细分后,又能方便的组合在一起,切分得下去,也组合得起来,Qi4j提出的面向组合式编程基本也是这个思路。当然,使用模块化方式组合也是一种方向。

[该贴被banq于2010-01-14 15:30修改过]

个人感觉banq说的是很有道理,目前软件的复用的确是软件开发的一大难题,如果要复用,粒度必须要是细粒度,不然就无法进行很好的复用,但是细粒度又给软件的开发造成了很大的困难,不过软件的复用困难也有好处,如果一个软件能够在各个软件上进行复用的话,我们程序员似乎也改集体辞职了

呵呵,其实复用在软件领域不断试验,云计算就是一种复用的新尝试,至少可以实现性能的复用,个别提供SAAS的也可以实现业务功能重用。

很好,很多基础结构的framework它们的代码组织很好,抽象性也很高,扩展性也很好,
但这仅是服务于基础结构而已,其实这些基础结构有时候用编程语言就可以解决,没必要那么复杂.
我想一些经验丰富的开发者,除了技术过硬之外,还能有自己的行业基础框架,有自己的架构自然就有了复用的基础.

从banq老师帖子真的学到很多,但还是想发发感概:最近在工作中越来越体会到其实很多项目都是“中国式关系”拉来的,只要实现就OK,注重程序稳健,性能,可扩展性的人和能够把代码凑到一块的人待遇差别不大(至少我待的公司是这样)。相比需求稍微变更和添加新功能就要大刀阔斧的改,和设计可扩展性高的程序导致工作量减少到最后领导感觉区别就是:一个加班完成,一个不加班就能完成的区别而已。感觉真是做软件的一种悲哀!也许这也是导致很多人都走向搞管理,不探究技术的人生路线。真希望学习设计之路能在banq老师带领下走的更远!也希望中国的软件环境能更健康的发展下去。

确实,在中国做程序员很难,尤其是在私人老板那里,我们公司现在在做一个网站,老板不看你软件日后是否能够很好的维护,功能是否能够很好的扩展,只看这个网站能否更省钱,至于其他的不管,只要目前能用就好了,我本来想使用基于java的网站,可老板看到asp开发的网站价格更低,于是。。。
我不是说asp开发的网站不好,但是asp实在是有些太落后了,开发出的网站肯定不会很好维护,但是基于asp的会省下几千元钱,唉,中国如果都是这样,软件怎么能健康的发展下去

重用之梦破灭的另外一个现象是:Spring将其OSGI的DM Server转给Eclipse了。

OSGI是打着模块化设计的另外一个复用组件设计,但是因为我之前一直认为OSGI有带套子嫌疑,包括JDK7将变相整入OSGI机制,这些都导致专门的OSGI服务器市场很小,

SpringSource在dm Server上倾注了2年多的专职研发心血,但貌似收效甚。SpringSource认为在目前的发展形式来看企业OSGi还难于成气候,借用一句流行的话来说就是:企业OSGI目前仍然是非主流。

http://www.theserverside.com/news/thread.tss?thread_id=59183

SOA过去了,OSGI也过去了,我看到好像只有OO在不断发展丰富,即将融入functional,DCI架构等等。
[该贴被banq于2010-01-15 14:15修改过]

在我们国家做软件这行是吃力不讨好!

面向对象讲究“对外封装,对内解耦”,内部要尽量细化,尽量重用,尽量细粒度,而对外则进行封装,封装的越多重用性就越低了喔。

天天陷入意识形态之争,有意思吗?没意思!

谈这些意识形态问题其实很有意思,因为现在很多厂商还在打着重用复用,以及所谓面向构件思想兜售他们产品,对于软件开发人员应该理性看待这些重用复用产品,不要再浪费时间和精力在一个无用的死方向上了,认清当前重用复用主流是什么?Class + functional是复用的方向。

Spring刚刚推出OSGI DM服务器时,很多人大捧臭脚,我一直不以为然,看看我2009年这篇文章:http://www.jdon.com/jivejdon/thread/36165#23122146,现在Spring自己都抛弃了它,把它转手了。

当然,花点时间学习更多新东西是对的,但是如果时间精力有限,有些东西还是不要浪费过多宝贵时间精力,有这个时间不如陪陪家人。

J道从来都是讨论方向问题,方向问题很重要,选择对的方向,可以起到事半功倍作用,相反走错方向,你再勤劳都是无用的。

这实际就是“做什么”和“怎么做”要进行分离解耦的哲学意义,“做什么”就是方向,这个哲理到处存在,如果不明白这个道理,软件永远做不好。
软件内的“做什么”和“怎么做”分离:使用future实现内置异步API
[该贴被banq于2010-01-19 11:51修改过]

粒度越细,是不是可以理解是对象单一职责的一种体现呢?

2010年01月20日 20:54 "freeren"的内容
粒度越细,是不是可以理解是对象单一职责的一种体现

是的,对象职责单一,就没有边际影响,没有副作用。

但是因为粒度太细,使用起来还是要综合组装使用,过去组合这个方法也由程序员做,那就累了,看不懂的人以为折腾,拆了再装,但是现在有动态语言或Java静态混合器Mixin等方式,就可以在编译代码时进行组合,无需程序员烦心了。

当然,编译阶段混合也是为了运行阶段组合,如果在运行阶段实现组合也是可以的,也就是说在运行阶段将业务逻辑what和实现技术How进行混合。DCI架构谈的也是这个问题。我个人认为使用EDA架构也可以实现运行阶段组合。

如果把程序员和用户看成是软件的两个端,程序员这端要把需求尽量细分,拆开来,讲究重用,变成一盘散沙,而到用户那个端,要按照需求将这些散沙组合成他们需求要求的建筑功能,以便他们能够使用这个软件。

奥妙和学问就在程序员和用户这两端之间过程,也是目前软件语言平台发展目标所在吧。


[该贴被banq于2010-01-21 10:27修改过]

做软件就像生活本身,也应该是有规划的。目前企业应用的概念太多了,但大多是一厢情愿的华而不实,除了带来误导并不能带来什么。所以目前阶段的企业应用开发,实打实的以关系数据库为中心还是一种主流。即使有如hibernate这样的ORM存在,但是仍然摆脱不了面向关系的影子。但是我们也要看软件的未来,看未来互联互通的大的发展需求,可伸缩的架构设计无疑是越来越重要的摆在了应用开发者的面前。就重用这个话题来说,只能说确实,重用很难,如果可以的话,一定是针对于某一特定商用领域的。

至于说到组合,如何能做到class或function级别的组合呢?做到这点更难吧。如果说最靠谱的,还是完整的服务的重用,而这样的重用就与重用的愿景差得有点远了。