我已經繼承了一個ASP.NET應用程序，它在架構上是一個災難，但它的工作原理和它在實際生產中的使用。爲了在未來增強應用程序，我需要完全重新構建它，但是我需要保留現有的前端功能 - 所要求的更改是後端集成，而不是前端功能或用戶交互。如何從根本上重新構建系統，同時保留功能行爲？
基本的問題是 - 大量的業務邏輯存儲在特效庫中（其餘的是在UI代碼隱藏文件中） - 沒有可說的業務領域模型。我需要將邏輯從數據庫中重構出來（並從用戶界面中）重新編碼爲代碼，但應用程序的行爲從根本上被限制在這些存儲的特效中。所以問題是這樣的 - 你如何去完成這種完整的重構？
我明白在小步驟中的重構，我讀過福勒等。我真的在尋找經過類似過程的人的實際建議。
謝謝！
編輯 我應該說，理想情況下，我想在多發佈週期中重複進行重新設計。
恕我直言，最重要的事情就是開發很多好的測試，以覆蓋你想要保留的全部功能。
我知道在雜亂的代碼庫中編寫測試非常困難，但它仍然可以通過一些依賴關係中斷技術。我會推薦"Working effectively with legacy code"，因爲它全部是關於重構的實用方面。
我非常同意piotsrz's answer - 一套好的全面的單元測試正是您在重構時幫助保持行爲所需的。將這些測試添加到持續集成系統中，以便您對每位開發人員的每次提交都能得到快速反饋。
關於此主題的另一本好書是Refactoring to Patterns，它描述了幾種保留行爲的架構轉換的迭代技術。
這很痛苦，但第一個大問題是：您是否真的需要重新設計？如果數據庫設計或多或少都可以，那麼您可以設計新的東西，讓老人獨自一人？每一個反思都希望整理這個爛攤子，但是從商業用戶的角度來看，需要什麼樣的投資水平以及回報如何？
您已經將迭代更改標識爲一種方法。爲了達到這個目的，這意味着系統中存在某種程度的粒度，可以在不影響其他人的情況下更改某些部分。你的想法大概是提供了一些新的商業價值，並同時清理了應用程序的一部分 - 有效地分攤了許多有價值的交付物的變更成本，在交付新東西時實施了「垃圾收集稅」。那「稅」是可以接受的嗎？
所以我認爲粒度假設是你需要檢查的東西。識別一小塊。嘗試重構。你覺得它是如你所希望的那樣孤立的變化嗎？成本是否與您預期的一樣？重要的是...哪些方面在哪裏？您的代碼有可能比現有的存儲過程執行得不好。開發「稅」是一回事，運行時表現「稅」是一個完全不同的東西。
分別處理存儲過程和用戶界面的業務邏輯。並首先採取SP。一次一個：
類似地處理UI。在任何情況下都不如聽起來那麼簡單 - SP和「常規」代碼之間的映射最好不完全 - 但我不知道更好的方法。
我主張不是寫了一堆單元測試，然後重構;而是測試覆蓋今天重構的代碼。幾個單元測試，有點重構;起泡，沖洗，重複。您可以隨時中斷系統，並且比開始時系統更好;執行更改和查看結果之間沒有很大的延遲。
有趣的答案 - 最好的。由於數據庫上存在多個SP和代碼依賴關係，粒度是一個大問題。在這個層面上孤立起來很難，這正是我所擔心的。 – flesh 2009-07-31 12:02:05