Brandon Olivares发起了讨论。他说，他刚刚在某些代码上用了30小时的时间，然后觉得这些代码可能会被重用，于是就觉得很矛盾，不知道是不是该把这些代码抽象出来，这样其他项目就有可能也用得到。
按照我个人理解来看，XP不鼓励假想某些东西可能会被用到，除非确实到了要用那个东西的时间点上。还是我的个人理解，刚才所说的东西也包括提取代码以供日后重用，XP提倡的是到了出现重复的时候再去做重构。
软件重用长期以来一直被极力宣扬为可以大量节省时间，也许另一个项目中的人可以重用你的代码，而不用重新开发。Brandon想知道其他人都是怎么决定在什么时候抽象代码加以泛化的。
Ron Jeffries***个回复，他讲了为什么跨团队重用的做法比初看起来要困难且昂贵得多：
我必须得给它打包，要是就我自己用的话这活就不用干了；我得给它写文档；我得让它更加抗造，把周边的一些问题去掉；我得给它提供支持，回答很多问题；我得训练别人用它。
如果我做了这些事情，代价就很高；如果我不做，别人用我的东西就很困难，给他们带不来多少帮助。
因为这些原因，Ron采取的是这种做法：
我只做适当的抽象，够自己用就好。如果我以后在一个稍微不同的环境下还需要用的话，我就会改进抽象。不过除非我的项目目标是给其他项目构建成品，我就不会浪费时间和金钱去给其他项目做东西。
还有一位认为，如果所有的项目都共享一套通用构建系统和测试套件，那重用就会容易一些。在这样的环境中，如果某个团队打算重用某些可以泛化的代码，这个构建系统就可以保证他们不会给其他需要这些代码的团队造成障碍。
George Dinwiddie、Ralph E. Johnson等人推荐到第二次（乃至更晚）用到同样代码的时候再做泛化。Adam Sroka把这个叫做“演化重用”，他认为这种方法比“为重用而设计”效率更高。一名叫做Tim的人发帖说，他这样给业务人员解释：“***次，你是给编码买单；第二次，你是给重用买单；第三次，它就是免费的了。”
George指出，更困难的地方在于怎么让其他团队意识到有些代码可以重用。帮助大家发现良机的沟通成本可能会很高。Jeff Langr说，让开发人员跨团队结对，可以解决这个问题。
Scott Ambler也加入了交流，他提到，开源也是重用的一种形式，它已经取得了巨大成功。他同时也提到，代码库、开发工具包乃至mash-up这些都是软件重用的成功案例。
【编辑推荐】
