软件重用

最近在极限编程Yahoo讨论组上，有些用户讨论了软件重用与XP实践——只在必要的时候才写代码——二者的明显冲突。Ron Jeffries和其他人一起探讨了代码重用的成本与收益，以及在敏捷环境中何时重用，如何重用。

这是一个典型的赶工期的软件开发项目。不但项目团队是临时组建的，并且大部份团队成员是经验尚浅的新人。

构件重用的目标是达到需求、分析、设计、编码、测试的重用。从此，一种影响软件产业发展的新的软件开发方法诞生了。

Don't Repeat Yourself，是软件开发的最佳实践，良好的软件开发应该是非自我重复的，同样按照非自我重复思想设计开发的软件，往往是好的软件。

使用重用技术可以减少软件开发活动中大量的重复性工作，这样就能够提高软件的生产率，减低开发成本，缩短开发周期。同时，由于软部件大都经过严格的质量认证，并在实际运行环境中得到检验，因此，重用软部件有助于改善软件质量。此外，大量使用软部件，软件的灵活性和标准化程度也渴望得到提高。

设计软件可以产生组件、架构和应用程序，如果在设计阶段更多地关注识别和设计组件和架构，那么在应用程序中就可以更多地进行软件重用。

EJB技术正在像其他辉煌过的技术一样走到了一个关口。2000年以前这项技术充满了传奇色彩，被大批企业不假思索地接受。然而理想毕竟是理想，经过了几年的发展，今天这项技术却正在被怀疑或者至少说让技术人员犹豫不决，现实的是J2EE的对手出来了，.NET似乎又有着后发的技术优势。大部分的探讨和争论已经开始转向这两个体系结构的对比。Java阵营内部同样发出了怀疑的声音，最直接的就是对EJB的攻击，因为人们发现原来这项技术所做的承诺似乎都走向了相反的方向

软件技术的不断发展给软件开发者带来了一个大问题：软件系统规模越来越庞大，开发周期越来越长，在一个系统中集成了各种功能使系统过于复杂，大多数功能不能灵活地装卸、单独升级或重复利用。而在削减开发成本的压力下，提高应用程序开发效率和质量，减少上市时间都使得开发人员承受着巨大的压力。

与我们之前谈的服务合同及松耦合直接相关的服务定向的一个方面就是抽取性。只有通过抽取性我们才能控制基础服务逻辑向外部世界展现的那部分。

软件重用（Software Reuse，又称软件复用或软件再用）的概念对于大家并不陌生。早在1968年的NATO软件工程会议上就已经提出可复用库的思想。软件重用的定义也很多，比较权威和通用的一种是：软件重用是利用事先建立好的软部品创建新软件系统的过程。

很多人认为，为了追求灵活性，将简单系统搞得复杂化是没有必要的，他们认为灵活性和简单性是矛盾的，其实他们只看到了问题的一个方面。

软件的可重用性一直是软件工程所追求的目标之一，软件工程界希望有一天能和其它工业领域一样，利用标准化的软件模块快速构建特定的应用系统。事实上，这种努力也取得了相当大的进展，但是与人们所期望的目标还是有不少差距，软件模块还远没有象汽车上的轮胎那样拆卸、维修、更换方便和简单。

复用即软件复用，是今年来被越来越多程序员重视的技术。本文通过对软件复用技术的分析，介绍了复用技术在提高软件效率、减轻软件开发压力方面的作用。

探究将软件重用到面向服务的体系结构(SOA)时对其起负面作用的因素，了解重用工程如何给SOA价值实现过程带来积极影响。

业务流程和技术资产可重用性的改进能使公司更快的进入市场，减少成本，实现更加一致的结果。近来面向服务的架构(SOA)使公司实现了商业服务、软件和数据的更频繁更广泛的重用，因此这个重要的概念获得了很多关注。

在本文中，学习如何用 Dojo 和 Ajax 开发可以与核心应用程序轻松集成的可重用组件。本文通过一个逐步的示例讲解如何开发一个可以向现有博客应用程序添加邮件功能的 Web 应用程序、生成邮件组件并处理复杂的跨域通信。

构件，我们更多的理解为一种资源，一种封装良好的，可供重复使用的代码资源。代码重用或者说资源重用是软件开发里面的老话题，在构件出现以前，人们也在以函数库的形式重用代码，构件是一种对代码组的更好的封装形式，它使得开发人员在设计时可以使用Drag-Drop这样的方式来开发应用，大大减少了手工硬编码的工作量，使新技术的学习曲线更加平滑、代码重用更加的容易，最终结果就是缩短产品的上市时间和提供更为丰富的产品特性。

这里主要讲的是我个人的项目体验, 所以要先来介绍一下项目背景. 我这里所说的项目主要是指大型游戏项目, 开发周期一般在1.5年以上, C/C++代码30万左右, 参与项目的程序一般在5人左右. 在这里我主要想谈三点感受

Carl Lewis最近发现了Dennis Forbes的一篇虽然有点老但仍然很有意思的文章，文章的主题是关于衡量代码重用。Lewis详细讲述了在Forbes的Blog上众多具有争议性的概念之一：与代码是资产的普遍观点相反，如果代码脱离了组织机构考虑创建这些代码时的原因的直接背景，代码本身而言并没有什么价值。Forbes还声称，如果没有明确地为通用性而设计的代码，尝试在多个项目间进行代码重用，甚至只是在同一机构里也是困难重重的。

抛开LOC那些术语，抛开什么软件工程XP，也不谈设计模式重构，谈谈我自己的想法