实际上就是如果把复用范围限制在公司内部，是否具有可行性。 我个人认为就目前的软件公司运作方式来看，复用的成本太高。
我觉得是值得的
我以前的公司就有一些构件，是积累下来的，开发小项目很快，20天就能搞定
软件公司也没有明确的业务和技术方向，总是有什么单，做什么活，那么复用就成为不可能的了。如果软件公司把自己限定在一些业务和技术方向上，在现有的市场环境下，存活的机会就小很多了。
因为复用是已知唯一一种实现令人满意的品质和效率的方法。 另外复用和很多种，源代码、代码模板、测试代码、代码框架、甚至软件需求，都可以拿来复用。 以围棋为例，如果没有复用，很难想象可以下出有品质和效率的招数。正因为有了复用，低手和高手下出棋的品质和效率才有天壤之别。 另外，软件的品质85%是由管理层决定的。如果管理层下决心持续改进效率和品质，就会不断有人建议复用各种东西。
我们以前的单位倒是不愁没有项目做
如果公司是面向特定的1-2个行业，可以做一些业务组件。 如果公司是采用特定的几项技术，可以提供一些技术层面的组件。 如果公司的基础设施一直比较稳定（如.net或j2ee），组件的形式也更稳定一些。 当然，组件库的价值极大的依赖软件架构师的设计。如果严格的遵循开放关闭原则(ocp)，组件就能逐渐的成长（grow） 我们公司就在这样做，感觉采用这种方法后，新编代码的数量明显减少，但经常感觉需要重写一些组件。
从分布式系统来看，我们每个人不可能把所有的东西都做好。公司从利润的角度不可能去构建这样的软件库。但是自由软件者可以尝试实现这样的构建库中心。大家发挥所长，把自己的库加进去。这样别人在构建自由系统时，只要封装就行了。商业也可以构建一个这样的库件中心。任何客户可以登出他们的库，卖给别人使用。这样：中间件提供商，系统组件商，专业特别软件服务商构成未来软件开发模式。不是可以复用而减少现在这么多的浪费。写完这些东西，觉得怎么有点像webservice。其实不一样，那是服务的调用。而这是软件开发的分工协作和尽量利用历史财产，让大家有更多的时间去做其他的事情。
如果是一个大公司，或者想做一个百年老店的软件公司，建立构件库是很有必要的，如果是小公司意义就不大了。这首先要求公司各级管理层能有这个意识，要求在每次的软件总体方案中注明本次开发准备用哪些构件，准备开发出多少新构件，并交付评审，只有这样，将构件库的思想深入公司每个软件开发人员的意识中，这个工作最后才有意义，也才有价值，如果做好了，以后的开发就可能做到搭积木般。否则流于形式后，管理层看到的是投入很大，但产出很少，对建立构件库就失去了信心。
臭帖评价：