我认为软件系统中大部分功能都可以复用，应该能达到70%以上左右，这里
主要取决你所编写的代码的通用性。
所以中小规模软件公司，应当注意代码的复用，可以大大减少工程的复杂度、
并且可以有效的提供工作效率。
个人意见，望指教。

————————————————————————————————————
2 楼go_my_sky（凡石）回复于 2003-03-29 20:56:43 得分 0 能达到70%以上吗?
请说说经验.
————————————————————————————————————
————————————————————————————————————
4 楼tom_lt（老虎）回复于 2003-03-29 21:28:16 得分 0 软件复用，在中小规模的公司里，一开始不能规定复用率，只能通过逐步积累来达到。具体步骤可以是：在需求阶段，把业务流程细分，原子化；设计时，尽量做到脱离具体的语言等物理细节；编码时，注意程序的健壮性。公司建立标准库，把一些在各个项目中重复出现的过程标准化。在这些过程中，积累起初步的复用文档，积累经验，这样才能达到复用的效果。
Top
————————————————————————————————————
6 楼zhf_karen（zhf）回复于 2003-03-31 12:59:52 得分 0 达到70%的代码复用率可能要求过于高了,在一家软件过程控制比较好公司,今年的目标是达到20%,所以不要一开始刻意去追求代码复用率,因为你可能还不明白哪些代码有复用的价值,哪些没有,而代码复用的追求会在项目中造成一定的时间消耗.我们总不能在不知道将来用在什么地方上,就决定这个代码重用吧.

其实复用的东西很多,方案复用,设计复用,代码复用.其中最后一项是最困难的.就象产品和项目的区别一样,代码复用的效果重来就不好.快速部署和快速开发不是完全依靠代码复用来完成的.
Top
————————————————————————————————————
7 楼twinsant124（蚂蚁的天空）回复于 2003-03-31 15:22:38 得分 0 :

不要一开始刻意去追求代码复用率

:)
Top
————————————————————————————————————
8 楼jq0123（金庆）回复于 2003-03-31 17:05:07 得分 0 对小型组织：
复用率不应太高。
主要以代码复用的形式进行。

Top
————————————————————————————————————
10 楼Carven（Carven）回复于 2003-03-31 17:31:19 得分 0 目前有一批的中小企业的首要问题是业务无法重用，今天接的单和明天接的单完全不一样，这样子可能被重用的东西就非常的少，比如今天接了一个办公自动化系统，用notes做，明天接了个企业网站，用php做，这种情况下大家来谈重用简直是天方夜谭。所以问题要从更根源的地方抓下来，你有没有形成自己的稳定的产品线，有没有自己的核心力量。
在中小企业里，往往项目经理就是技术的骨干，也是公司倚重的力量，所以项目经理一定要站出来，帮助公司来形成、稳固自己的产品线和核心力量。因为你不站出来，完全不能重用的项目就会落到你身上。也许你只要对业务单位说几声no,做一两次明确的说明，就可以减少你几个月的焦头烂额。如果没有项目经理站出来，以业务单位赚到钱就是大爷的思想，什么奇奇怪怪的单子都会冒出来。
如果业务稳定了，重用自然就出来了，至少大家会懒得去重写核心的代码，而乐衷于为新的用户或新的版本打补丁。然后就是考虑对主要业务的代码在重构的基础上去重用了。如果业务不稳定，全部都是无本之木。
Top
————————————————————————————————————
11 楼elpam（叶枫）回复于 2003-03-31 18:48:13 得分 0 软件复用是必要的，对提高系统质量、提高效率、提高团队作战能力很有好处。

按照我所在公司的经验：

基础数据结构（如表、栈等）

操作系统核心对象

底层通讯对象（如socket）

标准协议

都是可以复用的
Top
————————————————————————————————————
12 楼eastsun（）回复于 2003-03-31 18:59:37 得分 0

不管什么方法。

最根本的是代码本身的清晰，可读性高。

这是我的体会。
Top
————————————————————————————————————
————————————————————————————————————

14 楼zhf_karen（zhf）回复于 2003-04-01 09:00:39 得分 0 如果仅仅是工具软件,比如我写一个封装过的ftp程序,那么这是非常容易想象的,也是大多数公司都在做的,这不存在讨论的必要,因为对于一个项目来说,他所占的比重太小.就象过度设计一样,我们反对的仅仅是过度重用.

事实上,我们可以提炼出那样的重用,比如我使用OJB来封装数据库差异甚至是LDAP的差异.可以通过业务抽象,比如,可动态配置的可视化的用户配置等等.这样的模块可以在80%以上的项目中,通过配置来直接使用.我感兴趣的是那样的重用.而这不象简单的Function重用一样,需要考虑产品形态,需要考虑重用的接插性,等等.所以,适合在项目中提炼结合产品定义说明,但是不适合在单一项目中提出相关的要求.这超过了项目的要求,简直是把项目和产品合并

其实,我们所讨论的大多数项目,表层变化很多,但是底层的东西变化中的很大一部分是可以把握的,比如都有类似数据库的操作,都有大量对XML的操作,都有权限系统,都有对界面的可动态调整,都有打印功能,再大一些,都有简单的BI操作,都有类似工作流的东西.那么,下面的工作就比较清楚了.
Top
————————————————————————————————————
15 楼Gooder（Gooder）回复于 2003-04-01 10:28:09 得分 0 其实我认为，一开始就想达到很高的复用率是不太可能的，因为一开始对项目的了解并不多，必须要经过一定时间的摸索，积累，才能发现，哪些功能应该是分离，哪些功能是可以合并，哪些是可以设计好留待以后复用。所谓复用，也就是说能给大多数程序所利用，所以必须要积累。
Top
————————————————————————————————————
16 楼xiedejin2000（动力火山）回复于 2003-04-01 13:26:55 得分 0 我觉得我们中国现阶段的软件公司在软件工程这方面的积累做的实在不够。而且在交流方面更是欠缺。其实在交流的只是我们底下的这些无足轻重的程序员。所以说在今天的中国，我们更多的是在重复劳动。
Top
————————————————————————————————————

17 楼twinsant124（蚂蚁的天空）回复于 2003-04-01 14:29:53 得分 0 :

业务稳定了，重用自然就出来了

:)
Top
————————————————————————————————————
18 楼yckxzjj（Delphi编程驿站［www.delphidak.com］）回复于 2003-04-01 17:12:50
代码的重用性，我个人认为还是在不断地积累中得以体现！
Top
————————————————————————————————————
19 楼rzh（小江西）回复于 2003-04-01 17:16:58 得分 0 按开发语言对公用单元进行模板化开发，自然而然就能共用了！不同开发语言之间，那就另论
Top
————————————————————————————————————
20 楼justaswind（）回复于 2003-04-01 17:22:43 得分 0 我所在公司，虽然单子各不相同，但开发工具就两三种，应该可以重用，但是上层没有这个意思，毕竟要建立重用规范是要花很多时间的，领导不愿花时间和金钱来做。重用只限于每个程序员对自己的代码的重用。不能交流经验，使大家水平都得到提升:(
Top
————————————————————————————————————
21 楼codecool（缄默者）回复于 2003-04-01 18:11:24 得分 0 重用应该工作在不同的层次上，从组织的角度来讲，架构的重用比较多。从个人的角度来讲，强调功能与代码的复用。
重用不应该发生在设计阶段，至少不应该是主要的考虑，商业软件往往强调的是快速的提交，所以应用稳定的框架开发，不会过多强调重用的事情。能够重用的往往仅仅是特定功能的类。
Refactor也是重用的一个重要手段。
架构的重用是一个长期的，积累的过程，像游戏中的引擎，不是任何公司都有能力维护的。
而代码级的重用，往往因为没有很好的提炼接口导致重用错误：所谓的“拷贝了功能的同时，也拷贝了Bug”

所以我个人认为，将来的发展趋势将是所有能够重用的层次都会外包到企业外部。
只有当不同层次的企业从事不同业务的开发，底层的逻辑余平台相关的内容才能够更好的分离

MDA可能是比较接近这个结果的一个可行的解决方案。
www.omg.org/mda
Top
————————————————————————————————————
22 楼zysmaster（）回复于 2003-04-01 20:12:40 得分

首先，我要像上文中提到的“动力火车”朋友一起叹息中小软件企业的开发模式：在重复开发着本应该可重复使用的模块。
复用的概念：可重复利用的对象。对象的范围太广泛了，包括可见的物体
、不可见的物体，包括物理实体、逻辑实体等等。那么，我们首先要深刻的
理解对象这个概念，就连“你”也属于这个范畴之内的。既然，谈“复用”
前提要明确对象，那么我们在谈“复用”之前，一定不要“骑驴找驴”不知道
自己在哪个地方。我们必须先告诉自己：我在开发：中国人写的软件。
软件复用的概念好像在“复用”的概念上加了形容词就应该缩小领域。
但是，请问“什么是软件”？你能说清楚，什么是软件吗？我看未必吧。
软件本身就是一个混沌的指示词，因此，别妄想这个小小的“软件复用”
概念能够让你得到片刻的轻松。世界上好像跟编码相关的事物都可以叫做
“软件”，太广泛了，就像广袤无垠的星宇。“软件”这个词与“宇宙”
这个词有什么区别，你能说清楚吗？词性范围上，我可以残酷的告诉大家，
——是一模一样的。
这怎么办？难道有些人到今天为止：不知道什么是软件？我说：是的。
所以，我这里就像界定“宇宙”这个概念中“地球”一样，界定“软件”
概念中“基于数据库的行业软件”。这样，我相信我们都清楚地明白“范围”
是多大了。于是，我们可以研究什么是“软件复用”了，千万别忘了我们刚
才给软件复用所加上的隐含界定!
(晚上，要回家了，明天再说吧，对不起。)

Top
————————————————————————————————————
23 楼liujiangshan163（羊羔）回复于 2003-04-02 02:36:42 得分 0 过多的复用会浪费很多成本，除非有精于此道的人做此工作，
中小型公司作项目的指导思想就是用现有的好材料快速的完成项目。复用是生产材料的公司的事情。
Top
————————————————————————————————————

26 楼tshow（夜羽）回复于 2003-04-02 10:10:47 得分 0 谈点我的看法：
对于中小软件公司，开发人员有较强流动性，所接单子大部分业务功能没有什么延续性，就很难谈到软件重用这个层面上来，即使项目管理人员或者公司上层有这种想法，也未必能很好实现，经常有心无力，原因在于重用的最大前提是公司知识管理的完善，没有良好的文档管理和长期的积累过程，很难做到软件重用。对于组件，采用第三方的组件可能称之为重用，但那不是我们这里想讨论的。就像楼上说的利用现有材料快速完成项目，这应该是大部分小软件公司的心态，竞争激烈，能完成项目挣到钱就可以了，那里有多少人愿意花费时间和精力来规划软件重用啊
重用是一个很好的思想，对于业务行业稳定的软件公司，应该在项目规划时就开始考虑重用，最基本的代码复用也得写好文档，从代码、模块到架构复用一步一步积累，自然水到渠成
Top
————————————————————————————————————
27 楼tshow（夜羽）回复于 2003-04-02 10:18:20 得分 0 哎呀
俺写的怎么就贴上一句啊？？？剩下的呢？给谁吃了：）ft
不想再写了，大意就是注意文档积累和项目总结，复用是一个水到渠成的过程，刻意追求似乎不太现实
Top
————————————————————————————————————
28 楼arlbo（曾阿博）回复于 2003-04-02 10:30:58 得分 0 复用的概念：不仅仅是“对象”。
复用主要有两个方面的：
（1）软件开发生命周期的文档、代码和标准。文档与代码的复用，大家应该容易理解。其中标准，如文档标准，管理模式，可以认为是管理方面的。CMM的管理思路就是复用并优化“标准”。
大家要做到这些才是牛。
（2）上面有朋友提到的“架构”。Rational 公司提出的RUP，就包括有统一架构。我以前不太理解。当我们公司把“权限管理模块”、“流程配置模块”等模块作为基础平台的公共模块时，我才有点点理解（也许错了）。
统一架构就是统一开发平台和管理模式。这样，不管今后接什么样的单子，都可以利用现有的开发平台（我公司是基于J2EE的，）和公共性的模块（正如zhf_karen朋友所说）。

所以，从业务这个角度看，复用可以分为几个层次：
（1）数据复用---如：员工基本信息。
（2）信息复用---如：员工权限动态配置。
（3）流程复用---如：员工统一访问口令、基本工作流程。

这些复用都是程序（都是代码），也就是复用代码了。


Top
————————————————————————————————————

30 楼fanjun（红狼）回复于 2003-04-02 11:35:03 得分 0 同意zhf_karen(zhf)
对于中小公司，业务很难稳定的，可以做抽象出一些与具体业务无关的东西作为一个可复用的组件，通过配置文件来满足不同的项目要求。将具体业务封装到另一个组件中，这样可以提高复用性，又可以避免因为项目不同而出现的问题！
Top

————————————————————————————————————
33 楼renwanly（★★★★）回复于 2003-04-02 20:11:09 得分 0 小子认为应该大家先假定这个贴子里的人物都是一家虚拟软件公司（我们先叫这家公司为VCom公司）的人员，现在VCom的老总zysmaster()告诉了大家VCom的主营业务是XX行业数据库软件的开发（我们先假定是行业物流管理软件开发），而我们进行讨论的这60天就是公司的从注册到成长为一个国内知名品牌的软件公司的过程（当然也有可能由于我们错误的方向而破产——仅仅指开发过程的控制），我们基于此点来讲开发过程控制及软件复用不是更好些吗？不象现在的“画饼”，如果大家同意我们先来构架一个这样的公司，由楼主最终决定这是一家怎么样的公司，我们再进行讨论，如何？？？
Top
————————————————————————————————————
34 楼arfayr（阿飞）回复于 2003-04-03 03:08:04 得分 0 软件复用的程度其实也跟我们国内企业充斥的大量中小软件企业有关系。目前国内大部分软件企业重视眼前利益，没有长远利益。产品开发如此，项目实施如此。复用在某一个行业内可以达到70%以上，比如MIS系统，除了业务不同，剩下的公用功能都是可以复用的，不同的业务中也可以抽象出很多可以复用或者简单修改就可以复用的模块。而这些，对于中小软件企业师不屑于做得。甚至一些有实力的软件企业也不会这么去考虑问题。

我曾经开发过MIS的开发平台，复用的不仅仅是代码，还可以是设计思路、开发模式。业务不同归根到底是业务逻辑不同，实体对象的确也很大不同，但是基本上可以作到代码自动产生。比如人员和设备两个实体类，仅仅是属性不同存储方式不同，根本上是可以实现自动化的。针对一个新的业务中，实体可以自动产生，仅仅专注于业务逻辑和业务流成的开发，大大提高了复用程度。应用程序组织也可以复用，开发一套平台，自动的挂接任何组件。一套系统，实际上就是新开发的一些组件和一个配置平台。这种方式已经有几家公司在经营了，但效果不是很好。

国外的一些大公司，会有专门的人整理内部资源。新的项目和产品会综合考虑现有的资源（可以复用的模式、方案、框架、代码、流程等），然后会合理有效的进行复用。
他们的复用程度有时候让人惊人。

软件复用一个很好的想法，如果公司能够采用并且肯下功夫去发展使用，那可真是我们大家的福音啊
————————————————————————————————————
36 楼zysmaster（）回复于 2003-04-04 09:28:16

我已经观察了很长时间了，没有一个人能够真正切入“软件复用”的
本质。现在，你的提法正好是我最初的设想。
不过，我有个条件：必须懂理论，有实践，是技术副总，或者主管。
因为我不是在开玩笑。我美国一个朋友也在和我一样进行同样的研究。
我想综合我们所有公司的力量树立我们中国程序员的形象。你们知道美国如何
评价我们中国软件程序员吗？可恨！
你的想法，让我几乎失望的心情有了初醒般的萌动。我今天晚上就回家
写出我的要求。
真是，茫茫人海，总有沉默中爆发的勇士!

Top
————————————————————————————————————
37 楼zhf_karen（zhf）回复于 2003-04-04 10:10:12 得分 0 好吧,那么我们看你的大文吧.不过,我提醒几点:
1.国外人如何看待中国程序员,那是别人的事情,当你成熟起来了,别人的看法自然会改变.不必感到可恨.真话难听,但不可恨.
2.懂理论,有实践,技术副总或者主管.不必刻意提出来,如果有想法,说说何妨,错了可以改嘛.再说那样的条件也不高,搞得和高层会议一样,何苦来.不要用职位去挤压.有理说理,别用职位来衡量谁有权利说话,谁没有权利说话.这里不是公司.只是一个讨论的地方.
3."。“软件”这个词与“宇宙”这个词有什么区别，你能说清楚吗？词性范围上，我可以残酷的告诉大家，——是一模一样的。"
"你对软件得理解可能过于庞大了.把范围圈定在一个合理的程度上,是讨论问题的前提.不要说词性一样,就是概念可以类比.强奸和奉献在词性上是一样的.里面的区别你也不能分辨吗?有事说事,别用一些不恰当的比喻.这容易引起误导.我实在不知道你想表明什么.

你说没有人懂软件复用的本质,真的让人难以反驳,那么你能告诉我什么是本质吗?大家如何就不懂这个本质了?我看arfayr(阿飞)兄写得就不错,有理论,有实践.当然,复用需要积累.这需要一个过程,不是一蹴而就的.

好吧,不说了,干活了,等待你从沉默中爆发吧."让我几乎失望的心情有了初醒般的萌动"真象看一个三流的抢手写的东西,有点做作.

呵呵,说到这一点,我想起另一个句子,没有其他意思,让大家放松一下而已.写出来,一个北京的作者,在蓝急速网吧被烧以后,写着"我一晚上如同在烈火中煎熬, 无法入睡,我感觉他们的死,是因为我的责任(没有教育他们不去网吧? hehe)......."如果记者真的那样,我无话可说,但是也没必要把自己昨晚的感受让所有人感受吧.而具我对那个记者的了解,恐怕昨天晚上还是睡得着得. 呵呵,无他,仅仅感觉有点象当年自己在学校写的一些烂东西,还特感动自己,呵呵,有时间整理整理,也可以去恶心恶心别人了,问题是,一个成年以后的人,还是会写出那样做作的东西,就很让人有点感觉怪异了.
Top
————————————————————————————————————
38 楼zysmaster（）回复于 2003-04-04 10:18:26 得分 0 我收到了。谢谢。现在有四个人已经开始干了。
————————————————————————————————————

45 楼snowtop（）回复于 2003-04-04 14:00:51 得分 0

軟件開發過程復用的東西很多,有開發文檔,業務處理,行為方式等.
我同意樓上一位仁兄的說法.復用的程度視處理業務的不同而不同
我主要開發關於企業管理方面的系統,熟悉了行業規則後,積累了許多模塊的相似出,總結數據庫應用程序的操作規則.
實現當然不是想做就做了的事,需要實踐,通常經歷幾個同類業務的項目後,很容易實現大規模的工作復用.
Top
————————————————————————————————————
46 楼zxl_l（凌龙）回复于 2003-04-04 14:03:45 得分 0 从编码角度说：对任何的开发工具的编码（命令、函数等）规则、可用类都是可重复的，在这基础上开发出各公司依据业务需求生成的基类，这是可重复的资源。
从实现功能的角度说：采用面向对象的模块化设计开发，应用软件可选择模块进行重组，即重复。
有很多东西，表面上看可重复，实际不一定，不然开发工具就更先进了。
Top
————————————————————————————————————
47 楼zxl_l（凌龙）回复于 2003-04-04 14:09:52 得分 0 zysmaster：
　　我不喜欢你一开始就把自己放在是其他人教师的层面的语调。从这点上你不适合做软件开发的管理者，如项目经理、主管。作为管理者协调、沟通能力很重要。