切邊

軟體嚴重損壞： 修復及防止策略

Dino Esposito

當它聽起來或許，算是，我們的生活取決於軟體。以自己的各種服務的使用者，我們知道很好如預期般運作的軟體可能真的儲存我們一天。不過，軟體取得更多複雜，因為它來建立複雜的真實世界的處理程序的模型。IT 管理人員、 架構設計人員和開發人員，必須應付的不同。

在本文中我會檢閱作法，協助修正 deteriorated 的系統，並顯示模式，可能會使系統變得不受控制的方式。術語 「 大球泥漿 」 (BBM) 來參照到系統的主要非結構化和填補，以隱藏之間的相依性組件，具有大量資料和程式碼的重複] 和 [圖層或弱點的影響不太清楚識別建立年前，複雜的程式碼叢林。若要閱讀更多關於 BBM，我建議非常片段的好李良 Foote，並從/伊利諾州大學的 / Urbana-Champaign，在其中您可以從下載約瑟夫 Yoder http://bit.ly/nfPe2Y。在本文中，作者不要最壞曾經問題; condemn BBM 它們只是建議是準備好面對 BBM 風險，並了解如何讓它保持在 [控制項] 下的架構設計人員和開發人員。

回顧軟體系統的動態

某些 30 年，軟體紀元，開始應用程式是最容易撰寫今天。我們不需要的 Gui。我們不必擔心美學太多，需要散發，延展性的問題或部署問題。而且，最後一次，但絕對不容忽視，我們必須比較不會實作的商務邏輯。

在進行時，軟體開發拍攝嚴重，牽涉到最佳的共識。很 amazingly，在 1990 年代初期我們已經有大部分的軟體開發和架構原則和配置的模式。在論證上，幾乎不具有已"發明 」 後。例如區隔，考量和相依性反轉的原則，例如物件導向程式設計 (OOP) 和外觀導向的架構和行為，例如依照可測試性設計沒有開發近幾年來。其中許多 rediscovered 及套用今天的架構設計人員和開發人員，但它們已存在十年。

但是，為什麼有這些準則和最佳實務已經交集中的 limbo 多年來呢？可能有許多原因，但一般的開發人員 refrain 是，"它的運作，這樣的原因應該我改善它 (和耗費資源的浪費的更多的時間) 嗎？ 」

不同的 JAVA 和 Microsoft 世界回顧動態

Mid-年代，在物件導向和語言，例如 JAVA (c + + 以上) 的系統提示您重建他們的軟體，更大型且較大的資料庫和大型主機的商務邏輯區塊移至許多公司。JAVA 開發人員，尤其是在企業環境中，必須處理比在一般與 Visual Basic 程式設計相關聯的快速應用程式開發 (RAD) 中找到更多的複雜性。它不意外的長寬的方向，相依性的插入架構 (例如彈簧) 和 (例如休眠) 的物件/關聯式自行 — 奇思一長串的程式設計 (例如 NUnit、 Ant、 Javadoc、 Maven 等等) 的工具 — JAVA 世界中的來源。他們是複雜性的平滑影響開發人員的開發人員所建立的工具。

在此同時，在 Visual Basic 的世界中，RAD 是所有新細明。Visual Basic 可以幫助公司時不使用大型主機程式碼建立預存程序的最上層的前端不錯。Web 服務的建立額外的外貌與提供大型主機程式碼多更好名稱"舊版服務 ＞。

與過去的 RAD 爭論 OOP 15 年是合理的爭用。當 Microsoft 提出 Visual Basic 中的物件導向的功能時，所以很難說明開發人員究竟為什麼那些奇怪的功能是如此重要。然後，它們實際上並未，指定的那些細的應用程式的複雜度較低層級。

。NET 大革命

Microsoft 的版本。NET Framework 會發生在重要的階段。發生當部分的 RAD 方法稍早選擇的大型公司已經受夠網際網路的且必須年齡，若要對齊之新的網際網路相關的商務程序重建的後端系統。在此同時，這些公司中找到 Microsoft 平台可靠、 功能強大且可延伸的架構。當然，花只有幾年來。NET 開發人員使用相同的大量的 JAVA 同事遇到十稍早的複雜性 swamped。大部分。NET 開發人員，不過，RAD 原則與 RAD 方法成長，開發。

在 RAD 世界中，您通常想適用的程式碼建置的應用程式加入大多是獨立的區塊。(和這些不是真的獨立，就會使它們的 abusing 的程式碼和資料重複這種方式)。

問題不使用 RAD 程式設計的範例。最有可能會造成惡名昭彰的 BBM 為實際問題套用 RAD (或任何其他的開發架構)，而不需校正，可以防止應用程式的成長和後續的乘法運算的複雜性，在 [控制項] 下。

清除 BBM 的徵狀

它似乎會自然法則的程式設計，每個單位的任何大小的軟體 (為它的類別、 圖層或整個系統) 會降低。在其先前提到的紙張，Foote 和 Yoder 呼叫它 「 結構 erosion 」 的軟體。個人，我想要呼叫它的軟體 biodegradability。當軟體單位維護或變更時，就會變成難以進一步維護或變更。名稱，而不論時至今日只是一部份的交易。 您不能忽略它，並嘗試執行這項操作將只會造成損害。

軟體 biodegradability 緊密地連接到專案的逐漸成長。將新的需求合併至現有的系統，這架構不該特定的需求，是永遠有問題。它並不表示它不能復原 ； 或不應該，完成 — 這只是藉由新增新的需求，您要變更的內容。單一變更架構，通常不會有明顯的影響，但是當個別的變更相當頻繁，系統的內容隨著時間變更，並且可能需要不同的架構，morphs。此程序也就被指當需求變換。

同樣地，逐漸成長是交易過程中，組件，而未準備好要應付的是 deadly 贖罪現代軟體架構的其中一項。一次加入一個新的需求，而不需重新系統考量整個每個步驟，您就可以建立 BBM 的理想的情況。

何種常見的徵狀明確告訴您您將必須在您系統的齒輪有點困難泥漿？BBM 會不會取得隔天構成，而且不會也大開始。解決這些徵狀，我稍後會討論，有助於避免它變得太大。

第一個警示鐘環當您在類別中進行變更，並得到中斷另一個、 明顯無關的類別中的程式碼。這是嚴格的軟體，接受變更，最後決定迴歸某種程度的特點在於棘手的效果。

第二個警示鐘環，當您在嘗試重複使用程式碼中執行的可重複使用的部分失敗。如果相同的程式碼無法運作，就會移到另一個專案之後，最可能的原因是硬碟尋找相依性] 或 [緊密結合的類別。這些也是軟體 rigidity 的主要原因。

緊密結合是很有幫助，因為它可以協助您撰寫程式碼的速度，而且該程式碼可能執行較快。它不是，不過，讓程式碼可維護性。在專案中，分別成長 (就像大部分的今天的專案)，可維護性顯然是您想要列入考量的主要軟體屬性。

最後，第三個警示鈴聲響起時要套用修正程式的函式，而無確信套用理想的修正程式 (或無法執行這項操作)，因此您依靠另一個解決方法。

一個 (或甚至幾個)，這些徵狀，幸好存活下來任何系統。不過其基礎的機制是相當陷阱的。如果您忽略其中一個這些徵狀，您可能需支付使系統更錯綜複雜的風險。

比方說，我們來看 (有時稱為 「 immobility 」) 的第二個徵狀。您必須將加入的新功能，您覺得很放心，稍微調整和重複使用現有的函式。您試過，因為您所預期的類別可重複使用，它無法運作，但實際上，緊密地連線到其他人。您有另一種方式匯入多較大的多個模組內的函式集。在這種情況下，一般 (但天真) 方案複製一些程式碼，而不會嘗試更簡潔的重複使用的類別。程式碼重複暫時，修正問題，但只會 BBM。

BBM 的可能原因

很少單一開發人員建立的 BBM。BBM 有許多原因，而主要的原因通常會對目前的層級開發的外部進行研究。低的管理員，以及客戶真的不知道想要的目標，以開發人員清楚和模稜兩可的資訊來傳遞。小組有足夠的遇到一般軟體開發，而且在特定網域中，這會自動導致任意選擇連續固定透過妥協和因應措施。最後的結果是整體架構削弱在其基礎。

軟體專案中所有人都可以進行許多以避免 BBM 及平滑明顯的影響。讓我們來檢查您發現自己在 BBM immersed 時所採取的基本步驟。

嚴重損壞修復策略

當您面對的 BBM 時，理想化就是只需重新撰寫應用程式根據已檢閱的需求和新的架構選擇。但是，完整的重新寫入絕不會就您可以考慮的選項。您可能存活泥漿？

Foote 和 Yoder 使用 evocative 影像引入只合理] 選項，您必須在這些情況下： 掃除常下的這麼糟，並繼續您自己的生命。但是我想我可以合併彙算三個步驟中軟體嚴重損壞修復策略。第一個步驟停止任何新的開發。第二個步驟隔離層級 (當不層) 的讓人頭痛指向和排列要測量的點上的任何迴歸分析工具。最後，在挑選每個隔離的問題分層，必須特別小心，請比較完整且更鬆散聯繫架構重構它們。

第二個之後您停止開發 muddy 專案，您就可以開始思考一連串相關的測試。Immersed BBM 時，您將最後一個項目中是傳統的單元測試。在此內容中的相關測試是跨越多個圖層，有時層的整合測試的排序。這些測試會首先，執行速度緩慢，但 — 更重要的是，它們可能會變慢寫入。您必須以隔離 (可能) 大量的行為，並可以在測試一樣接受指揮的外貌後面將它們隱藏起來。撰寫外貌可能不是很容易，但它通常是最小的可能。也是大部分的時間和工作的事。這些測試會有幫助，對於您的下一個步驟，因為它讓您使用自動化工具來測量迴歸，當您執行的最後一個步驟。最後一個步驟是由重構的工作的第一個問題解決的過度緊密的結合性的 painstaking 所組成。

計劃策略，以避免 BBM

防止處理向來是。有三個基本的優點，以及可能會造成 BBM 平手，我稍後會討論這一個團隊。假設這些天遭受高層級的需求變換大部份的專案，逐漸成長應該是事實，而不只是有可能。若要防止 BBM，您必須擁有有效的策略，以應付逐漸成長的功能。

可維護軟體的方法宣告完美的現代軟體是今天的需求是有足夠的彈性，以適應將來的需要。先前所述的三個的第一個 virtue 就是網域的經驗。當您不能有實際的網域專家在您的小組時，至少必須深入了解網域的擁有人，這可能讓您新的網域專家。網域經驗會引導您至合理斟酌最有可能會需要並要求的功能。因此，您可以輕鬆地事先計劃時清楚並謹記的 YAGNI (您 Ain't Gonna 需要它) 原則。

類別的責任共同作業 (CRC) 卡方法已協助我以瞭解的網域我遇到的第一次的技巧。我看到 CRC 卡來教導您自己的網域，找出適當的設計成更多。相反地，設計，是適當才驗證實際的客戶。使用案例 — 或者，更棒的是，原型 — 更聰明的選項。

原型可能會發生問題，因為客戶可能會想太多它們會強制您要擴充它，而非從開始設計新的設計。原型則通常是使用 throwaway 故意撰寫的是快速，因此，如果它的原則和模式的程式碼中。您只是不想要啟動 throwaway 的程式碼。

第二個 virtue 變得更好的開發人員/設計師學習的軟體開發和一般的最佳作法 sane 的原則。這裡的挑戰是在學習如何正確地執行簡單的動作，根據預設值。不要害怕的介面為基礎的程式設計和相依性插入。驗證每個類別對常 OOP 犯的錯誤。確保透過程式碼和靜態分析的正確性。如果您不確定某項功能的運作方式，使其可供測試，並撰寫測試。精簡和平均，大多數的方法不會再使用幾行比保留您的程式碼 (含有到期課程的例外狀況)。如果這些作法是您工具箱子的一部分，BBM 會有點遠留離開您的專案。

第三個 virtue 是了解專案的週期。並非每個專案都有建立系統會持續存在十年。短暫的專案不需要相同的設計特別小心。您可以更快跳上，並放入小心讓它們再將它們正確運作。在軟體，必須複雜性控制在它真的存在、 未建立位置不存在，且不應該是。危險，不過，在初始的信念，專案必須的短的時間範圍都無效的 ； 令人驚訝的成功和需求，並建立市集時。如果速度太慢發生後續的版本，您會執行 snatching 市場競爭者的風險，或者您執行建立真正緊密 (與急於) 的商業需求受限於 BBM 的風險。

軟體專案損毀修復

BBM 是常見的 anti-pattern，但在某種程度是可以套用至幾乎軟體專案的屬性。它是來自使用錯誤的工具來有效駕馭複雜。在本文中我會使用運算式，嚴重損壞修復，那是熱門項目 IT。方法的嚴重損壞修復專家，不過，可以套用到軟體專案太： 防止中所花費的金額是以多個修復所花費的金額。今天，衝到您的管理員辦公室!

Dino Esposito 是作者的 ＜ 程式設計 Microsoft ASP。NET MVC 」 (在 [微軟出版品，2010年) 和 coauthor 的 「 Microsoft。NET： 架構的企業應用程式 」 (在 [微軟出版品，2008年)。居住在義大利，Esposito 是在世界各地的產業活動演說。在 Twitter 上都追隨他twitter.com/despos。

感謝給下列技術專家來檢閱這份文件： Mircea Trofin