遺留代碼不可避免

在我們的職業(yè)生涯中，有很多時候必須忍受遺留代碼。或許，你接受一份新的工作，遺留代碼是你的第一個任務;或許，你們公司重組，并且有個產(chǎn)品最終在 你這里完成。不論什么緣由，事實就是這樣。你想編寫一些新的優(yōu)秀的代碼，但是現(xiàn)在負責的是對于你來說全新的完全不熟悉的一段代碼。這個代碼看起來相當復 雜、陌生，但你卻不得不接受這項工作。

事實上，要是我擴展一下這個定義，你就能將任何一段先前編寫的代碼看作遺留代碼。你是否曾經(jīng)嘗試回顧六個月前你編寫的代碼?忍受你自己所寫的代碼并非總是易事，更何況對于別人所寫的代碼。如果你不遵循一些基本的指導原則，這兩種情況都是相當有挑戰(zhàn)的。

傳統(tǒng)的方法是，在你竭盡全力避免非有意的間接損害的同時，適當做些修改。不幸的是，因為對代碼的不熟悉，當你改變一個數(shù)據(jù)結構或者更新一個變量時，你無法確信將要發(fā)生什么。

與其在這種充滿危險的境況里盲目地徘徊，還不如制定一個處理的策略。不要只是作出改變后就期待萬事如意。相反，瞄準目標，用“BAT”將它擊出棒球場。

處理問題時，你可以三管齊下，構建(build)，自動化(automate)并且測試(test)。對遺留代碼可以使用這個BAT，并且給自己設置一個安全網(wǎng)。BAT方法將確保代碼如你所期的那樣繼續(xù)工作。它可以“捕獲”非有意的副作用，幫助你“消滅”它們。

構建

要解決的第一個問題就是構建。除非你能可靠地構建它，不然測試一個產(chǎn)品很困難。先解決如何在你的電腦上干凈地構建該產(chǎn)品，然后再編寫構建腳本。

有 時候這是個不成問題的問題，但通常構建不是總能夠如期待的一樣的干凈。構建通常局限于單一機器或者一個特殊的環(huán)境。在團隊中，當代碼在代碼所有者間傳遞 時，很容易積累一些臨時的構建需求。每個所有者可以添加他/她自己的特殊需求，并且混合在一起。當你接手這攤子事情時，廚房里可能已經(jīng)有了很多的廚子。

一個復雜的構建能夠引發(fā)整個產(chǎn)品一連串的問題。

當一件事情困難時，人們就很少去完成它。當一個構建困難時，人們就很少去構建它。這是人的天性。運行一個干凈構建的能力正在成為一種黑色藝術，在你的工作環(huán)境中，只有少部分人才能掌握它。

因為你無法測試你未構建的事物，使測試變得不頻繁。當人們最終運行他們的測試時，他們發(fā)現(xiàn)了更多的缺陷…不頻繁的測試使得缺陷有更多的時間積聚。如果你每天都運行測試，那么只需要你報告當天的缺陷。如果你等6個月后去測試，你將會有很多的問題去處理。

因此測試變得繁重。測試者厭煩了測試周期內的所有工作，所以他們試圖避免測試工作。沒人喜歡記錄十幾個或者幾百個缺陷這種無聊的工作。

開發(fā)者開始畏懼測試周期，因為他們感覺自己象被所有的缺陷報告進行轟炸。所以開發(fā)者開始怨恨，并且叨擾測試者。這使得測試周期更加痛苦。這真是一個惡性反饋循環(huán)。

復雜的構建給整個產(chǎn)品生命周期帶來一些問題。所以必須要保證構建是干凈的。

當任何人都能構建時，任何人也就都能進行測試，于是也就會更加頻繁地運行測試，產(chǎn)生出更小范圍的缺陷報告。一次少量的工作就意味著更少的瑣事。任何人都愿意搬動一桶涂料并且不用三思，但是如果讓人去搬五百桶涂料，看看他們會說什么。

你的目標就是創(chuàng)建一個能夠在任何開發(fā)機器上易于運行、易于維護的干凈的構建。使用一個構建腳本工具或者語言，例如Rake、Ant、Maven或者Nant.這些高層次的構建語言使你能聚焦于構建自己的應用程序，而不是構建、語言或者平臺等細節(jié)。

當你可以僅用一句命令(如ant all)來構建產(chǎn)品，你就能繼續(xù)到下一步。確保在不止一臺機器上測試這一步。

我想請你試著用BAT方式來處理遺留代碼。 看看與日常工作相比的區(qū)別是什么，是否需要用不同的手段處理工作。

自動化

現(xiàn)在你已經(jīng)可以在任何一臺機器上自動構建你的產(chǎn)品了，那么讓我們來使它自動化吧。

自動化的目標是自動化整個構建，在一臺干凈的機器上，在測試周期內，使人為干預最小化。使萬事自動化并非都有可能。但是我們希望達到的目標是，把那些可以被合理的自動化執(zhí)行的東西都寫入腳本。

有時，安裝和配置一個軟件要比編寫一個腳本來自動安裝和配置更為容易。只需一次性安裝的應用程序當然是首選。諸如編譯器，運行庫和已存的數(shù)據(jù)集都屬于這一 類。不要試圖花費兩個小時去復制已存的數(shù)據(jù)集。但是，如果你能在30秒內重建一個代表性的數(shù)據(jù)集，那么你便應該從頭開始。以一個干凈的已知的數(shù)據(jù)集開始的 好處非常大，但是并非總是符合實際。不要因為重建你的數(shù)據(jù)，將15分鐘的測試變?yōu)橐粋€小時。

要確保記錄下任何一個手動步驟及所有指令，它們可以為其他想復制運行環(huán)境的人提供幫助。

另一方面，為什么你應該整天監(jiān)視著全部的構建?時間是寶貴的。IDE或多或少都是可以進行增量構建(incremental build)和運行細粒度單元測試(small unit test)。很多時候，這種部分覆蓋(partial coverage)已經(jīng)夠用了。讓開發(fā)人員針對活動的代碼區(qū)域(active code area)，運行一組冒煙測試(smoke test)，就可以覆蓋大多數(shù)情況。

編輯推薦

JAVA認證考試報考指南 / 更多JAVA考試資料

（責任編輯：）

共2頁,當前第1頁  第一頁  前一頁  下一頁