建站
咨詢
售后
建站咨詢
新聞中心
軟件重用的價值毋庸置疑，在《用敏捷方法進行軟件重用》一文中曾指出：軟件重用長期以來一直被極力宣揚為可以大量節(jié)省時間，也許另一個項目中的人可以重用你的代碼，而不用重新開發(fā)。但實現(xiàn)軟件重用***挑戰(zhàn)性，大規(guī)模、系統(tǒng)級的重用更是如此。
十載的長白網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調(diào)整長白建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)公司從事“長白網(wǎng)站設計”,“長白網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
開發(fā)人員要在***期限內(nèi)滿足需求、交付功能，同時還要優(yōu)先保證重用 就非常難了。如果你是團隊領導，這個處境只會變本加厲——你必須滿足贊助商的需求，在預算內(nèi)按時交付功能，還要管理開發(fā)團隊。重用，重用什么？
#T#筆者參與了幾個項目，團隊的生產(chǎn)率都非常高，我認識到軟件重用是可行的。這并不是說勉強做到重用很容易、有方法可循。抑制重用的一個關鍵因素是，從組織的政 治、文化背景來說缺乏領導力和遠見，而且沒有與業(yè)務贊助商需要的內(nèi)容相結合。有些重用的嘗試以失敗而告終，是因為他們太過雄心勃勃了，為了設計***的內(nèi)容 而花費大量精力去做大規(guī)模的先行設計。還有其它一些失敗的原因，比如缺乏靈活的設計、規(guī)劃不充分，或是資金問題。溝通效率和對現(xiàn)有可重用軟件資產(chǎn)的了解也是一個關鍵因素。
本文將根據(jù)我從幾個項目中總結的經(jīng)驗，介紹一些成功進行系統(tǒng)級重用的小提示。這些提示并非盡善盡美，我只是想讓開發(fā)人員和團隊領導能對各種策略（技術和非技術的）有所理解，從而成功地進行系統(tǒng)級重用。
提示1——關注領域特定的軟件資產(chǎn)
業(yè)務資產(chǎn)能讓你的應用或產(chǎn)品線獨樹一幟，讓你的組織與眾不同，最終讓你從競爭對手中脫穎而出。開發(fā)、發(fā)布、迭代改進領域相關軟件資產(chǎn)的速度越快，你就越能迅速地滿足不斷變化的業(yè)務需求、讓客戶滿意。如果你只關注于構建可重用的業(yè)務資產(chǎn)，那這不僅對業(yè)務交付有好處，同時還能在未來的項目中進行重用。
開發(fā)人員往往滿懷熱情地編寫技術方案，專注于可重用組件和服務的構建，而解決的問題卻在公司內(nèi)部或開源社區(qū)有解決方案。既然你非要這么做，那你就必須盡量避免為已有的解決方案編寫新的代碼。這不正是軟件重用嗎？
提示2——正確命名軟件資產(chǎn)
無論你是給方法、類、組件、庫命名，還是給服務命名，要想取個好名字，首先得想清楚軟件的目的和功能。合適的名字可以幫助我們找到已有的可重用軟件資產(chǎn)。另外，在重構已有軟件資產(chǎn)、使其更容易被重用時，這一點也卓有成效。
當你發(fā)現(xiàn)doEverything()這樣的方法或類似于SendDataToXYZSystemService的服務時，花點兒時間給它們重新命名。評 估應用的現(xiàn)有功能時，不好的名字常常會花費你更多的時間。如果名字太過愚蠢，你可能就識別不出已有的功能，而去創(chuàng)建一個重復的。
除了繼續(xù)遵守一般的準則外，好名字還應該與問題領域聯(lián)系在一起——基于業(yè)務功能給軟件資產(chǎn)命名是個不錯的主意。如果你要將更新的訂單內(nèi)容發(fā)布到另一個系統(tǒng) 去，那為什么不用PublishOrderUpdates替代SendDataToABCSystem這個名字呢？資產(chǎn)名稱全都簡單、清晰、準確時，你會 驚奇地發(fā)現(xiàn)這很有利于你重用這些資產(chǎn)。
提示3——不確定它們是否可重用？那就晚點兒再動手
領域中真正有趣的問題是需要經(jīng)過深思熟慮的，需要與項目利益相關者協(xié)作，還需要多次迭代和最終用戶的反饋。這一要求對充分進行系統(tǒng)級重用來說是非常寶貴的。如果僅僅因為看起來可重用，那它實際上也許并不可重用……至少目前還不是?？紤]一下這些問題：
◆功能在當前項目之外是否真正可重用？
◆將某些內(nèi)容變?yōu)榭芍赜玫?，是否會給現(xiàn)有的設計帶來重大變化？
◆是否理解了功能相關的問題域？
◆隨著時間的推移，這個功能會怎樣演進？
當你對潛在可重用資產(chǎn)的疑問多于答案時，不要急著概括、增加抽象層次或產(chǎn)品差異性。相反，著眼于那些只針對當前迭代或發(fā)布的業(yè)務需求和實現(xiàn)。正是因為你可能不清楚未知的內(nèi)容，所以將想法或功能標記為可重用備選項，但不一定非要使其可重用。
在《軟件架構師應該知道的97件事》中，Kevlin Henney在其中一條里提到了“通用之前先簡單，重用之前先可用”這個概念。請記住，在項目的整個生命周期中，結合真實用戶的反饋進一步理解領域只會對你有所幫助，而不會影響你的目標。
提示4——迭代演進可重用的資產(chǎn)
當你認識到需要可重用的軟件資產(chǎn)時，規(guī)劃實現(xiàn)戰(zhàn)略就很重要了。如果你用大爆炸的方式處理資產(chǎn)實現(xiàn)，那你創(chuàng)建的軟件資產(chǎn)最終會脫離項目當前的需求；由于要增加設計、開發(fā)和測試的時間，顯然還會拖延進度。無論哪種方式，你都要花費大量寶貴的資源。
相反，可以通過多次迭代來演進可重用的資產(chǎn)，從而減輕這些風險。舉一個可重用資產(chǎn)的例子——給用戶發(fā)通知。我們將該資產(chǎn)命名為Business Notifier。我們提出一個簡單的計劃——通過數(shù)次迭代來逐步實現(xiàn)該資產(chǎn)的一百個附屬功能，而不是一下子就創(chuàng)建出來。
迭代1：用電子郵件通知用戶預定的業(yè)務事件
迭代2：允許用戶選擇，只接收某些業(yè)務事件的通知
迭代3：讓用戶自定義業(yè)務規(guī)則，繼而生成業(yè)務事件
迭代4：通過Web控制臺或即時消息應用發(fā)送通知
迭代5：能讓用戶邀請朋友一起接收通知
迭代6：將通知和工作流結合起來，讓支持人員進行審查
這顯然只是個范例，在特定迭代中加入的功能往往要基于業(yè)務需求、優(yōu)先級、實現(xiàn)的難易程度和其它因素。比如不再優(yōu)先處理資產(chǎn)時，你可以減少投資，反之亦然。 不論構建為可重用資產(chǎn)的內(nèi)容是什么，都要在多個迭代中規(guī)劃其發(fā)展演進。這樣，你就可以減少風險，保持對業(yè)務需求的靈活性，還能只創(chuàng)建那些你愿意投資的資 產(chǎn)。
提示5——保持一致性要比遵循行業(yè)標準更為重要
跨應用創(chuàng)建可重用的軟件組件和服務時，力爭保持一致性要比符合標準更為重要。如果大量應用程序都使用了特定的可重用組件，那你就可以跟往常一樣，將現(xiàn)有接 口作為適配器，讓它在后臺調(diào)用行業(yè)標準的API。不過要注意，我并不是建議你盲目地為那些已經(jīng)有成熟標準的內(nèi)容創(chuàng)建新代碼。
這與要重用的水平業(yè)務能力相關。比如說，你在多個應用程序中都需要處理信用卡付款的功能，而在此時又沒有行業(yè)標準。創(chuàng)建應用可利用的支付API就很重要， 而不是等待標準奇跡般地出現(xiàn)。第二天，如果出現(xiàn)了一個標準，你可以修改現(xiàn)有的實現(xiàn)，這不會對你當前的應用有任何影響。好吧，也許我說得太過輕松了——你可 能需要細微的代碼修改和回歸測試。但最起碼你的處境會比較好，不用修改代碼庫中的代碼。
提示6——進行代碼審查
代碼審查能最有效地保證可重用資產(chǎn)被 正確使用。大多數(shù)時候，為了趕緊發(fā)布產(chǎn)品，開發(fā)人員提交代碼時并不了解其它地方已經(jīng)實現(xiàn)了的功能。由于審查代碼要花費時間、遵循規(guī)則，所以在小規(guī)模內(nèi)這樣 做的確是個好主意。關鍵之所在與其說是代碼質(zhì)量，還不如說是一致性。你可能期望能有一個快速的方法指出哪些資產(chǎn)可重用，將其與代碼中的變化相結合。我在代 碼審查時經(jīng)常會找出新的可重用資產(chǎn)。隨著時間的推移，你會看到多個代碼片段和應用功能中存在的模式和重復的代碼，這對起到增效作用很有幫助。
當你看到重構或創(chuàng)建可重用資產(chǎn)的機會時，不要把這些工作跟應用代碼的剩余部分摻雜在一起。將它們從源碼和版本控制中分離出來，作為一個獨立的實體。和其它 內(nèi)容一樣，這也需要迭代地來完成，也不必在產(chǎn)品的最初版本中就有。隨著資產(chǎn)演進、變得可重用，可以重構、把它們放到它們自己的倉庫中，以便更好地管理。主 要問題是在它們可重用時把它們移出來。在主干代碼之外對它們進行版本化和演進，以便更容易地在新項目中集成。
提示7——沒有自動化的回歸測試套件，就不要發(fā)布可重用的軟件資產(chǎn)
如果你要在可重用軟件資產(chǎn)上押寶，把它推廣到全世界，那你必須要有一套回歸測試套件。為什么呢？沒有回歸測試，現(xiàn)有和潛在的消費者對資產(chǎn)就沒有足夠的信 心。重用的基礎就是不用再次實現(xiàn)已有的內(nèi)容，從而獲得更好的質(zhì)量——較少的錯誤、Bug、不對的需求實現(xiàn)。為了確保能兌現(xiàn)這一承諾，你必須得有完整的自動 化回歸測試套件。這不僅有利于當前的消費者，對以后的任何消費者也是有用的。
你可以創(chuàng)建可重用的腳本，完成編譯、執(zhí)行、單元測試和回歸測試的報告。無論你構建的是組件還是服務，甚至是業(yè)務流程，這都是適用的。下一步合乎邏輯的事情就是把這些腳本集成到持續(xù)集成套件中去。
提示8——理解業(yè)務需求之后再去說服別人
大家總想說服開發(fā)人員或開發(fā)經(jīng)理能同意重用軟件資產(chǎn)。但如果你還沒理解業(yè)務需求就一再地去勸說，成功的可能性并不大。不要試圖去說服，而是傾聽、體 會、真正理解需求。弄清楚業(yè)務需求，然后確定能被利用或開發(fā)的資產(chǎn)。為什么要這么做呢？因為當你真正去聽的時候，你可能會發(fā)現(xiàn)現(xiàn)有的資產(chǎn)能完全滿足需求，或者根本不能滿足需求。也許可重用的服務還需要滿足某個性能指標。或者利用現(xiàn)有的服務會增加進度風險。諸如此類。
關鍵是現(xiàn)有的資產(chǎn)要適用于眼前的問題。傾聽，評估，如果合適就說服——一定要遵循這個順序。
提示9——盡可能與開發(fā)團隊一起創(chuàng)建可重用的軟件資產(chǎn)
提倡系統(tǒng)級重用失敗的原因各種各樣，其中包括技術和組織方面的原因。 開發(fā)團隊是可重用資產(chǎn)的潛在用戶，如果沒有來自開發(fā)團隊的支持，你的計劃就不可能取得成功。我經(jīng)常聽到開發(fā)人員對開發(fā)經(jīng)理說，不想重用，也不想開發(fā)可重用 的功能，因為他們覺得實現(xiàn)可重用資產(chǎn)與他們無關。如何解決這個問題呢？不要試圖去說服他們，而是和他們共同創(chuàng)建可重用的資產(chǎn)。
如果有個需求是通過電子郵件發(fā)送通知，那就和原來的開發(fā)團隊合作，讓他們參與設計。更好的辦法是讓他們開發(fā)部分或全部的功能。如果他們和你聯(lián)合創(chuàng)建了該資 產(chǎn)，他們就不會覺得這個資產(chǎn)是強迫他們使用的黑盒子了。他們會在組織里和他們的合作伙伴分享該資產(chǎn)，從而幫助你促進重用——你會對此感到驚訝的。
提示10——從生產(chǎn)支持人員那里獲取可重用資產(chǎn)的需求
將可重用資產(chǎn)投入生產(chǎn)環(huán)境之前需要做一件事，就是與生產(chǎn)支持人員溝通。讓他們投入進來，分享你的設計，及早并經(jīng)常獲取他們的反饋。這不僅能讓資產(chǎn)可被支持 （想象一個沒有日志、輔助工具、記錄關鍵指標功能的可重用資產(chǎn)），還能讓你擁有一個有價值的的合作伙伴。生產(chǎn)支持人員很快就會信任你的資產(chǎn)和服務，并要求 多個項目都利用這個功能。賣出重用資產(chǎn)是一回事，合作伙伴表示支持又是另一回事。
網(wǎng)站名稱：有效進行軟件重用的十個提示
新聞來源：http://www.5511xx.com/article/djhdosh.html
