軟件重用的價值毋庸置疑，在《用敏捷方法進行軟件重用》一文中曾指出：軟件重用長期以來一直被極力宣揚為可以大量節省時間，也許另一個項目中的人可以重用你的代碼，而不用重新開發。但實現軟件重用***挑戰性，大規模、系統級的重用更是如此。

開發人員要在***期限內滿足需求、交付功能，同時還要優先保證重用 就非常難了。如果你是團隊領導，這個處境只會變本加厲——你必須滿足贊助商的需求，在預算內按時交付功能，還要管理開發團隊。重用，重用什么？

#T#筆者參與了幾個項目，團隊的生產率都非常高，我認識到軟件重用是可行的。這并不是說勉強做到重用很容易、有方法可循。抑制重用的一個關鍵因素是，從組織的政 治、文化背景來說缺乏領導力和遠見，而且沒有與業務贊助商需要的內容相結合。有些重用的嘗試以失敗而告終，是因為他們太過雄心勃勃了，為了設計***的內容 而花費大量精力去做大規模的先行設計。還有其它一些失敗的原因，比如缺乏靈活的設計、規劃不充分，或是資金問題。溝通效率和對現有可重用軟件資產的了解也是一個關鍵因素。

本文將根據我從幾個項目中總結的經驗，介紹一些成功進行系統級重用的小提示。這些提示并非盡善盡美，我只是想讓開發人員和團隊領導能對各種策略（技術和非技術的）有所理解，從而成功地進行系統級重用。

提示1——關注領域特定的軟件資產

業務資產能讓你的應用或產品線獨樹一幟，讓你的組織與眾不同，最終讓你從競爭對手中脫穎而出。開發、發布、迭代改進領域相關軟件資產的速度越快，你就越能迅速地滿足不斷變化的業務需求、讓客戶滿意。如果你只關注于構建可重用的業務資產，那這不僅對業務交付有好處，同時還能在未來的項目中進行重用。

開發人員往往滿懷熱情地編寫技術方案，專注于可重用組件和服務的構建，而解決的問題卻在公司內部或開源社區有解決方案。既然你非要這么做，那你就必須盡量避免為已有的解決方案編寫新的代碼。這不正是軟件重用嗎？

提示2——正確命名軟件資產

無論你是給方法、類、組件、庫命名，還是給服務命名，要想取個好名字，首先得想清楚軟件的目的和功能。合適的名字可以幫助我們找到已有的可重用軟件資產。另外，在重構已有軟件資產、使其更容易被重用時，這一點也卓有成效。

當你發現doEverything()這樣的方法或類似于SendDataToXYZSystemService的服務時，花點兒時間給它們重新命名。評 估應用的現有功能時，不好的名字常常會花費你更多的時間。如果名字太過愚蠢，你可能就識別不出已有的功能，而去創建一個重復的。

除了繼續遵守一般的準則外，好名字還應該與問題領域聯系在一起——基于業務功能給軟件資產命名是個不錯的主意。如果你要將更新的訂單內容發布到另一個系統 去，那為什么不用PublishOrderUpdates替代SendDataToABCSystem這個名字呢？資產名稱全都簡單、清晰、準確時，你會 驚奇地發現這很有利于你重用這些資產。

提示3——不確定它們是否可重用？那就晚點兒再動手

領域中真正有趣的問題是需要經過深思熟慮的，需要與項目利益相關者協作，還需要多次迭代和最終用戶的反饋。這一要求對充分進行系統級重用來說是非常寶貴的。如果僅僅因為看起來可重用，那它實際上也許并不可重用……至少目前還不是。考慮一下這些問題：

◆功能在當前項目之外是否真正可重用？

◆將某些內容變為可重用的，是否會給現有的設計帶來重大變化？

◆是否理解了功能相關的問題域？

◆隨著時間的推移，這個功能會怎樣演進？

當你對潛在可重用資產的疑問多于答案時，不要急著概括、增加抽象層次或產品差異性。相反，著眼于那些只針對當前迭代或發布的業務需求和實現。正是因為你可能不清楚未知的內容，所以將想法或功能標記為可重用備選項，但不一定非要使其可重用。

在《軟件架構師應該知道的97件事》中，Kevlin Henney在其中一條里提到了“通用之前先簡單，重用之前先可用”這個概念。請記住，在項目的整個生命周期中，結合真實用戶的反饋進一步理解領域只會對你有所幫助，而不會影響你的目標。

提示4——迭代演進可重用的資產

當你認識到需要可重用的軟件資產時，規劃實現戰略就很重要了。如果你用大爆炸的方式處理資產實現，那你創建的軟件資產最終會脫離項目當前的需求；由于要增加設計、開發和測試的時間，顯然還會拖延進度。無論哪種方式，你都要花費大量寶貴的資源。

相反，可以通過多次迭代來演進可重用的資產，從而減輕這些風險。舉一個可重用資產的例子——給用戶發通知。我們將該資產命名為Business Notifier。我們提出一個簡單的計劃——通過數次迭代來逐步實現該資產的一百個附屬功能，而不是一下子就創建出來。

迭代1：用電子郵件通知用戶預定的業務事件
迭代2：允許用戶選擇，只接收某些業務事件的通知
迭代3：讓用戶自定義業務規則，繼而生成業務事件
迭代4：通過Web控制臺或即時消息應用發送通知
迭代5：能讓用戶邀請朋友一起接收通知
迭代6：將通知和工作流結合起來，讓支持人員進行審查

這顯然只是個范例，在特定迭代中加入的功能往往要基于業務需求、優先級、實現的難易程度和其它因素。比如不再優先處理資產時，你可以減少投資，反之亦然。 不論構建為可重用資產的內容是什么，都要在多個迭代中規劃其發展演進。這樣，你就可以減少風險，保持對業務需求的靈活性，還能只創建那些你愿意投資的資 產。

提示5——保持一致性要比遵循行業標準更為重要

跨應用創建可重用的軟件組件和服務時，力爭保持一致性要比符合標準更為重要。如果大量應用程序都使用了特定的可重用組件，那你就可以跟往常一樣，將現有接 口作為適配器，讓它在后臺調用行業標準的API。不過要注意，我并不是建議你盲目地為那些已經有成熟標準的內容創建新代碼。

這與要重用的水平業務能力相關。比如說，你在多個應用程序中都需要處理信用卡付款的功能，而在此時又沒有行業標準。創建應用可利用的支付API就很重要， 而不是等待標準奇跡般地出現。第二天，如果出現了一個標準，你可以修改現有的實現，這不會對你當前的應用有任何影響。好吧，也許我說得太過輕松了——你可 能需要細微的代碼修改和回歸測試。但最起碼你的處境會比較好，不用修改代碼庫中的代碼。

提示6——進行代碼審查

代碼審查能最有效地保證可重用資產被 正確使用。大多數時候，為了趕緊發布產品，開發人員提交代碼時并不了解其它地方已經實現了的功能。由于審查代碼要花費時間、遵循規則，所以在小規模內這樣 做的確是個好主意。關鍵之所在與其說是代碼質量，還不如說是一致性。你可能期望能有一個快速的方法指出哪些資產可重用，將其與代碼中的變化相結合。我在代 碼審查時經常會找出新的可重用資產。隨著時間的推移，你會看到多個代碼片段和應用功能中存在的模式和重復的代碼，這對起到增效作用很有幫助。

當你看到重構或創建可重用資產的機會時，不要把這些工作跟應用代碼的剩余部分摻雜在一起。將它們從源碼和版本控制中分離出來，作為一個獨立的實體。和其它 內容一樣，這也需要迭代地來完成，也不必在產品的最初版本中就有。隨著資產演進、變得可重用，可以重構、把它們放到它們自己的倉庫中，以便更好地管理。主 要問題是在它們可重用時把它們移出來。在主干代碼之外對它們進行版本化和演進，以便更容易地在新項目中集成。

提示7——沒有自動化的回歸測試套件，就不要發布可重用的軟件資產

如果你要在可重用軟件資產上押寶，把它推廣到全世界，那你必須要有一套回歸測試套件。為什么呢？沒有回歸測試，現有和潛在的消費者對資產就沒有足夠的信 心。重用的基礎就是不用再次實現已有的內容，從而獲得更好的質量——較少的錯誤、Bug、不對的需求實現。為了確保能兌現這一承諾，你必須得有完整的自動 化回歸測試套件。這不僅有利于當前的消費者，對以后的任何消費者也是有用的。

你可以創建可重用的腳本，完成編譯、執行、單元測試和回歸測試的報告。無論你構建的是組件還是服務，甚至是業務流程，這都是適用的。下一步合乎邏輯的事情就是把這些腳本集成到持續集成套件中去。

提示8——理解業務需求之后再去說服別人

大家總想說服開發人員或開發經理能同意重用軟件資產。但如果你還沒理解業務需求就一再地去勸說，成功的可能性并不大。不要試圖去說服，而是傾聽、體 會、真正理解需求。弄清楚業務需求，然后確定能被利用或開發的資產。為什么要這么做呢？因為當你真正去聽的時候，你可能會發現現有的資產能完全滿足需求，或者根本不能滿足需求。也許可重用的服務還需要滿足某個性能指標。或者利用現有的服務會增加進度風險。諸如此類。

關鍵是現有的資產要適用于眼前的問題。傾聽，評估，如果合適就說服——一定要遵循這個順序。

提示9——盡可能與開發團隊一起創建可重用的軟件資產

提倡系統級重用失敗的原因各種各樣，其中包括技術和組織方面的原因。 開發團隊是可重用資產的潛在用戶，如果沒有來自開發團隊的支持，你的計劃就不可能取得成功。我經常聽到開發人員對開發經理說，不想重用，也不想開發可重用 的功能，因為他們覺得實現可重用資產與他們無關。如何解決這個問題呢？不要試圖去說服他們，而是和他們共同創建可重用的資產。

如果有個需求是通過電子郵件發送通知，那就和原來的開發團隊合作，讓他們參與設計。更好的辦法是讓他們開發部分或全部的功能。如果他們和你聯合創建了該資 產，他們就不會覺得這個資產是強迫他們使用的黑盒子了。他們會在組織里和他們的合作伙伴分享該資產，從而幫助你促進重用——你會對此感到驚訝的。

提示10——從生產支持人員那里獲取可重用資產的需求

將可重用資產投入生產環境之前需要做一件事，就是與生產支持人員溝通。讓他們投入進來，分享你的設計，及早并經常獲取他們的反饋。這不僅能讓資產可被支持 （想象一個沒有日志、輔助工具、記錄關鍵指標功能的可重用資產），還能讓你擁有一個有價值的的合作伙伴。生產支持人員很快就會信任你的資產和服務，并要求 多個項目都利用這個功能。賣出重用資產是一回事，合作伙伴表示支持又是另一回事。