淺談用敏捷方法進行軟件重用
Brandon Olivares發起了討論。他說，他剛剛在某些代碼上用了30小時的時間，然后覺得這些代碼可能會被重用，于是就覺得很矛盾，不知道是不是該把這些代碼抽象出來，這樣其他項目就有可能也用得到。
按照我個人理解來看，XP不鼓勵假想某些東西可能會被用到，除非確實到了要用那個東西的時間點上。還是我的個人理解，剛才所說的東西也包括提取代碼以供日后重用，XP提倡的是到了出現重復的時候再去做重構。
軟件重用長期以來一直被極力宣揚為可以大量節省時間，也許另一個項目中的人可以重用你的代碼，而不用重新開發。Brandon想知道其他人都是怎么決定在什么時候抽象代碼加以泛化的。
Ron Jeffries***個回復，他講了為什么跨團隊重用的做法比初看起來要困難且昂貴得多：
我必須得給它打包，要是就我自己用的話這活就不用干了；我得給它寫文檔；我得讓它更加抗造，把周邊的一些問題去掉；我得給它提供支持，回答很多問題；我得訓練別人用它。
如果我做了這些事情，代價就很高；如果我不做，別人用我的東西就很困難，給他們帶不來多少幫助。
因為這些原因，Ron采取的是這種做法：
我只做適當的抽象，夠自己用就好。如果我以后在一個稍微不同的環境下還需要用的話，我就會改進抽象。不過除非我的項目目標是給其他項目構建成品，我就不會浪費時間和金錢去給其他項目做東西。
還有一位認為，如果所有的項目都共享一套通用構建系統和測試套件，那重用就會容易一些。在這樣的環境中，如果某個團隊打算重用某些可以泛化的代碼，這個構建系統就可以保證他們不會給其他需要這些代碼的團隊造成障礙。
George Dinwiddie、Ralph E. Johnson等人推薦到第二次（乃至更晚）用到同樣代碼的時候再做泛化。Adam Sroka把這個叫做“演化重用”，他認為這種方法比“為重用而設計”效率更高。一名叫做Tim的人發帖說，他這樣給業務人員解釋：“***次，你是給編碼買單；第二次，你是給重用買單；第三次，它就是免費的了。”
George指出，更困難的地方在于怎么讓其他團隊意識到有些代碼可以重用。幫助大家發現良機的溝通成本可能會很高。Jeff Langr說，讓開發人員跨團隊結對，可以解決這個問題。
Scott Ambler也加入了交流，他提到，開源也是重用的一種形式，它已經取得了巨大成功。他同時也提到，代碼庫、開發工具包乃至mash-up這些都是軟件重用的成功案例。
【編輯推薦】
