软件最大的追求是什么?

http://www.jdon.com/artichect/coupling.htm

松耦合一个反义词“紧耦合”,从我们学会玩编程这个玩具开始起,我们就面临两种选择:一种朴素的、无需训练的、近似自然的“紧耦合”路线;一种是经过科学培训的“松耦合”道路。

介个标题起的……
软件最大的追求就是卖给用户,拿到钱,发到奖金,回答完毕。

看到banq给的公式,突然想起Yin兄以前说过的,为什么关系数据库理论比OO理论更正统(当然原话8是这么说的)。banq的公式相信计算机系的学生都知道……它的最大特点就是啥都解决不了……呵呵。不过关系理论就不一样了,它在告诉你你的关系模型不是很好的同时,给了你完善的方案(或者说定理,范式定理,范式公式)来完善你的模型。虽然实际开发我们往往需要降范式话,但是我们同时也可以知道降范式化带来的优点和缺点,而且这些都是可计算的。

与上面所说相反的,所谓OO的“松耦合”能带来多大的意义,我们却不可能很清楚的了解到。几年前号称面向组件编程,耦合度确实比面向对象编程还低,貌似就要大量出现软件组装工厂的局面……但是现在看呢,意义是在有限的紧。原因很简单,耦合度降低的同时:
1、开发成本不可避免增高……别说什么灵活的可维护性、可适应性,我们没有权利替用户想需求,用户只要一个轮子,你给他造出一个汽车,用户认为这就是浪费。
2、最大的问题,“构件”(请原谅我用这个词)的粒度应该多大?……

不写了,上班先,

>“构件”(请原谅我用这个词)的粒度应该多大?……
粒度是不能量化到用数字来表达的,这不是方向,它外界标准是:无论你的组件粒度粗细,但是该构件自身必须是可替换的。

无论是面向对象或面向构件/面向组件/基于组件,衡量他们先进与否的一个重要指标是:其任一对象或构件/组件是否可替换?只有实现完全可替换,才能实现高度可扩展性和维护性。

因为这个尺度,迫使我们必须使组件粒度细化,就象我们必须将一个墙体再次细化成砖块一样,粒度越是细化,可替换性更强,细化到沙粒,则毫无疑问是最好,但是有时没有必要,只要细化到这个构件可以被替代即可。

这又是一种依据具体问题具体分析的典型思维方式,而不是有一个放之四海皆准的数学公式。


>软件最大的追求就是卖给用户,拿到钱,发到奖金,
完全同意,但是如何做到呢?就是以最低成本提供最好质量的商品。考虑到你这个思考方向,我特地修改文章,在最后加了一句:

所以,对于编程这个玩具,不在于你是否会玩,而在于你怎么玩?玩的水平。如果不明白这个道理,中国软件的萧条永远不会结束。

只有快速地、低成本地、玩出高水平的的软件,才能卖给一个个用户,而不是只能永远卖给第一个用户;才能持续拿到钱,而不是一锤子买卖,拿到钱,以后就没有了,最后,似乎有这个印象:搞软件的人象“披着高科技羊皮搞诈骗”一样。

> 粒度越是细化,可替换性更强,细化到沙粒,则毫无疑问是最好,但是有时没有必要,只要细化到这个构件可以被替代即可

这句话有很大的问题。什么样的东西是可以被替代的?一个类webservice可以被替代,一个类可以被替代,一个函数(方法)可以被替代,一个语句可以被替代,一个变量当然也可以被替代……
虽然粒度越是细化,可替换性更强,但是从复用的角度看,显然不是越细越好。
我们看一下程序演化的历史:
打孔纸带编程:好像不大好复用一个纸带,这个偶不了解
过程式的编程:用goto跳到程序某一个地方,可以实现语句级别的复用,事实证明这种方式是极其糟糕的;
模块式编程:复用提高到方法级别……到这个时候,软件才开始进入大规模的应用;
面向对象的编程:类级别的复用。很8错的一种东西。
面向构件的编程:构件级别的复用,比类更高级的复用。号称可以让编程像工厂组装那样,但是从来没有出现过这样的工厂和所谓的构件市场。
面向服务的编程:……好像有点意思,了解不深,不乱发表评论。

综上可以得到两点结论:
1、复用的粒度跟生产率相关,但具体关系不明,并不是说复用级别越高生产率就越高。
2、sorry,突然想不起来了

> >软件最大的追求就是卖给用户,拿到钱,发到奖金,
>只有快速地、低成本地、玩出高水平的的软件,才能卖给一个个用户,而>不是只能永远卖给第一个用户;才能持续拿到钱,而不是一锤子买卖,拿>到钱,以后就没有了,最后,似乎有这个印象:搞软件的人象“披着高科>技羊皮搞诈骗”一样。

这个这个,快速、高水平当然是很好的,但是残酷的现实告诉我们,同时做到低成本,这个不可能。banq可以做一下调查,看看是不是用了几个模式产品成本就能降低?偶要说得意思很简单:软件的成本关系到方方面面,低耦合对软件成本降低没有直接作用,过度追求低耦合更是成本居高不下的帮凶。比如说,我的应用只能跑在oracle上,你为了追求更低耦合度,抛弃oracle特有的分区特性,系统性能因此可能下降50%以上,然后我花大力气设计分布式缓存来解决性能问题……有必要吗?
庄周贫者,往贷粟於魏文侯。文侯曰:‘待吾邑粟之来而献之。’周曰:‘乃今者周之来见,道傍牛蹄中有鲋鱼焉,大息谓周曰:“我尚可活也。”周曰:“须我为汝南见楚王,决江淮以溉汝。”鲋鱼曰:“今吾命在盆Y之中耳,乃为我见楚王,决江淮以溉我,汝即求我枯鱼之肆矣。”

哈哈,yuxie兄古文功底相当深厚,想来惭愧,看老祖宗文字象看洋人文字一样,需要咀嚼才能明白啊。

其实我现在在做探索,通过构件库和框架+模式搭建产品,需要人员无需多,我曾经用eStore的组件库为别人在一周内搭建一个网上家庭旅馆登记系统,算是一个初次常识。

这是一个梦想,或者正在实现的理想。也是一个乐趣吧。

最近刚到一家美国公司不久,整个公司的产品就是一个销售网站。中国分公司100来号人的主要任务就是维护(当然老美那边也有差不多数字的人在做这号工作)。大概了解了整个程序的架构设计。整个架构基本上基于xml,耦合程度很低,连web表现逻辑都分成好几部分。这边公司我知道的都有10来个部门(估计还有一些我不知道的),每个部门分管不同的工作,整个一条流水线。以前虽然一直也作架构设计方面的工作,但现在才真的体会到架构设计中松耦合的好处。
当然这也和公司性质和项目投入有关,原来一直做项目的,进度和经费都有限,不可能在可维护性上关注这么多。但比较起来,老美的架构师就是不一样啊。

应该说很多关于架构设计方面的理论只有放到实际的应用中,看到实际的应用框架,才能体会到它的好处。设计属于比较抽象的东西,空说往往不能让人信服。反正偶是觉得在这方面又提高了一个层次了。

那dabb千万别吝啬将你新的体会写出来,对我和大家都是一个学习的机会啊。新的一年你终于有新的开始了。

松散之后,最大的感觉是系统庞大琐碎,有时靠一个架构师是没有精力顾及的,不同的架构师有不同擅长。

这也是yuxie的疑问,多出这么多组件出来,用起来怎么能快速呢?其实这就取决于这些琐碎组件的管理方式,而之间力推的Ioc容器是一种很好的组件管理方式。

我也力图通过Jdon框架进行这样的尝试:要用拿起来就能用;需要时,可以大卸八块,完全粉碎。就象阻击枪手的抢一样,可以分批携带,到现场能够快速组装成型。

耦合与质量类似,都是以成本为前提的。
前一段时间观摩了一个软件,号称“免代码编程”,本来不信的,可是看了演示之后,却叹为观止。真的是他们所说的那样,所有Model、Service,View乃至CRUD操作,统统不需要编程,就可以生成一个完整的应用系统。估计一个用例,30分钟到1小时即可完成!
可是这样的软件生成的“软件”的性能却不敢恭维,因为所有的表都是动态的,所有的查询也是动态的,所以缓存、数据库索引之类的提高性能的高招统统不好使:(,还有就是界面,十分单调。
不过,如果应用在局域网,用户量比较少的情况下(多数企业应用都是如此),到真是一个很NB的系统。想想,如果需求改变了,我等开发者不需要编程,只需告诉用户:“你自己添加一个字段不就得了...”
呵呵呵呵

请问能介绍一下您观摩的软件公司的背景吗, 诸如名称, 产品类型, 网址等可公开的内容.
谢谢!


他们给了我一个临时帐号li/1
但是估计不能用了。
这个系统给了我很多启发,就像动网论坛,有些时候不必追求技术上的先进和时髦,如何降低成本、如何应对需求变更才是最重要的。
曾经有个几万元的小项目,用户自己也清楚以后需求肯定会变更,于是提出:“可以自己添加字段”这个要求,我当即回绝,因为这个需求会导致整个系统变成一个“动态的系统”,它意味着所有SQL都是动态的,不是不能做而是成本太高了。可是现在想来,也许应该做,因为以后还会用到类似的需求。
不知道各位有没有遇到类似的需求:
1.报表格式不确定---我通常是给他们培训Excel^_^
2.字段不确定,解决方法同上。
3.查询条件任意组合,这个到可以做,但是查询性能难以保障。
回想起来以前遇到过很多类似需求,大项目就做了,小项目就拒绝了,但是如果能够整合这些需求...

新的开始不敢说。我现在也只是流水线上的一员而已,专门作维护工作的,也刚来,都还没有转正。所得的一些体会也是在学习他们的业务和作修改维护工作中自己摸索出来的。等过段时间有时间更深入了解一下,看看能不能写出点具体的东西。
因为公司不是做软件业务的,本身只维护自己的一个产品(一个销售代理网站,和很多所代理的公司有接口。好像接口交互的文档都是基于pdf的。一些业务关联更紧密的接口也采用weblogic integration作基础架构,估计用到一些业务流之类的功能了。接口方面我倒很有兴趣,不过不属于我现在的维护范围,只能做猜测了)。所以更关注软件的可维护性了。

>耦合与质量类似,都是以成本为前提的。
我觉得这个议题比较好,我的补充观点是:在初期追求耦合会增大成本,但是当你形成可以重用的框架和组件库时,则可以大大降低以后项目的成本,这有点类似固定资产投入,所以为追求高质量的松耦合而开发可重用的框架或组件库时,在财务上,这些成本应该和固定资产采取折旧方式一样,平摊到以后项目中,这样你的项目越多,成本就降下来了。

关于那个“免代码编”演示案例只是一个代码生成工具,不是快速开发框架,这两者有区别,代码生成工具衡量标准是:是否遵循MDA原则这个世界公认的体系?另外,我们更关心的是:生成后的代码是什么架构?是一种高质量的松耦合架构吗?

我以前看到本站广告,可以生成struts+spring+hibernate代码的生成工具,你生成的代码架构是现在业界公认的通用的良好架构,因此这样的生成工具是可信赖的。

其实,也不能完全否定“免代码编”这样的努力,他们目的也是为了应需而变,使得系统能够在需求变化时,快速适应变化。

这里随需而变又有面临两种方向:
1.进行粒度解剖,不断细化分层,追求松耦合结构,进而使用可重用的框架和组件库,这样,需求变化时,可能就是组件组装方式的改变,或者组件本身的替换即可,我相信组装抽换模块的理念大家在其他领域都有切身体会(如工业控制模块等),这是目前业界通用的探索方向,EJB/Spring发展也表示这样的趋势。

2.不客观认识软件的复杂性,不深入软件内部进行解剖科学分析,试图用大一统概念或追求一个神奇的工具将软件开发揉吧揉吧,然后嘴里一吹仙气,一个好的软件系统就从这个软件开发工具中出来了。

我想这两者是典型的中西方思维观点的区别,这也是后者现象在国内不断出现,总是能打动电信 税务 政府部门那些人的原因了。