最近在清理本组的代码，主要任务是合并重复代码，改善系统结构，因为系统历史很长，参与过的开发人员很多，里面的冗余代码非常多，清理起来真的是非常辛苦的事情：<
相信每个工作有一定年头的程序员都有一个自己的代码库，需要的时候要么copy，要么include，不管是自己写的还是抄的别人的，反正是顺手拈来，这也算是大家技术积累的一个方面。对于一个公司，特别是作产品的公司，我觉得代码的重用，组件的编写也是一件很有意义的事情。
现在抛开LOC那些术语，抛开什么软件工程XP，也不谈设计模式重构，谈谈我自己的想法：
1.重用是不是越多越好？什么时候要考虑重用？
我觉得不是的，可重用组件的编写要比一般的代码付出更多的精力，要适应更多的情况，要经过更多的测试，要有更加齐全的文档，所以说重用要适度，否则你的项目可能大大超出预算。一般的原则是：第一次使用直接写，当你写到第3次的时候，你就要考虑是否重用了，当然，很多组件，比如访问数据库的代理层，那是可以预见到需要重用的。
2.“改他人的代码不如自己重新编写”是重用的大忌么？
http://www2.ccw.com.cn/02/0244/b/0244b01_3.asp?看了一篇文章，里面是这种观点，但是觉得板子不能全部打在程序员头上，假如一个组件是测试严格，文档齐全的，在项目的压力下，有谁会愿意去自己再写一个啊！应该说 文档不全，每次出了问题总要trace into进去的重用代码，才是重用的大忌。
3. 一个项目组是否应该由专人编写重用代码？
个人觉得，与其讨论是否有专人编写重用代码，不如讨论是否应该由专人测试和管理重用代码及其文档，正如上面一条所说，重用组件的文档化和正确性是至关重要的，重用组件的每一次变化，都要经过严格的测试然后checkin，假如接口有变化，必须由专人负责通知或者修改相关代码。这里建立一个良好的配置管理是非常重要的，否则你就跌入到一个比dll hell更加深的地方去了：>
4. 重用或者组件是否是解决软件问题的灵丹妙药？
前段时间常常看到文章，大概就是以下的论点：由行业专家开发重用的组件，然后给各个公司使用；一个公司里面高级程序员开发组件，低级程序员搭建积木。极力的鼓吹组件编程，勾画出一幅美好前景。我曾经也迷信这个，但是现在觉得：无论是com/corba还是DotNet/Java中的解决方案，组件解决的是二进制代码重用兼容性的的问题，而不是软件开发的问题本身。
不要以为使用了组件，重用了代码就可以摆脱小作坊的生产方式，进入软件开发的大同时代。软件的复杂性在于其模拟的现实世界的本身，组件和重用永远只能解决一部分的问题。重点还是必须放在规范管理，重视需求方面。
大家看看目前重用的比较好的部分：
1.操作系统的内核对象,GUI对象
2.数学运算，加密算法
当然其他的还有一些，这些要么属于小粒度的重用(比如一个按钮的对象)，要么具有严格的规范和定义(比如数学运算和加密算法,一些协议的库)，进入行业领域以后，需求千变万化，重用的粒度越大，适用的范围越狭窄。写出一个适用于行业的framework，要么适用范围太小，自己公司能用就不错了，要么成本太高+使用复杂，别人买你的还不如自己定制开发。
|