英文原文：Tips for Effective Software Reuse

　　作者：Vijay Narayanan 譯者：王麗娟 發布于 2009年12月30日

　　構建軟件的每個人都會告訴你，實現軟件重用極具挑戰性。大規模、系統級的重用更是如此。開發人員要在最后期限內滿足需求、交付功能，同時還要優先保證重用就非常難了。如果你是團隊領導，這個處境只會變本加厲——你必須滿足贊助商的需求，在預算內按時交付功能，還要管理開發團隊。重用，重用什么？

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

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

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

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

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

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

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

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

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

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

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

• 功能在當前項目之外是否真正可重用？
• 將某些內容變為可重用的，是否會給現有的設計帶來重大變化？
• 是否理解了功能相關的問題域？
• 隨著時間的推移，這個功能會怎樣演進？

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

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

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

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

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

　　迭代1：用電子郵件通知用戶預定的業務事件

　　迭代2：允許用戶選擇，只接收某些業務事件的通知

　　迭代3：讓用戶自定義業務規則，繼而生成業務事件

　　迭代4：通過Web控制臺或即時消息應用發送通知

　　迭代5：能讓用戶邀請朋友一起接收通知

　　迭代6：將通知和工作流結合起來，讓支持人員進行審查

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

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

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

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

　　提示6——進行代碼審查

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

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

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

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

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

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

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

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

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

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

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

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

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

　　結論

　　技術實踐、協作和務實相結合，可以慢慢擴充你的可重用資產庫。本文介紹的這些小提示都是我在日常工作中為了提高成功率而反復使用的。我非常想聽聽你在促進有效軟件重用時總結出的經驗，無論它們是否有效。

　　英文原文：Tips for Effective Software Reuse