看過博客園里幾篇關於重構的文章，感覺都不怎么實在。下面我來談談自己的一次重構經歷，希望對新人能有所幫助。
ALinq 這個產品維護了將近五年的時間，最近對它進行了一次重構。為什么要重構？主要是為了適應業務的發展需要。產品是服務於業務，而重構是服務於產品，歸根到底，重構是服務於業務。所以我一直強調，好的架構不是想出來的，而是做來的，經驗積累下來的。很多時候業務的發展，往往會超出你出初的預期，所以在產品的前期想設計出一個完美的架構是不可能的事。
這次的重構，出現了很多問題，一直陸續推出了好幾個版本，才開始穩定下來，還好我的用戶都是些忠實的用戶，用ALinq好幾年了，一直耐着性子，一個版本一個版本地安裝，然后試用，真心感謝他們。
重構的代價，其實還是挺大的，所以在重構之前，盡可能多做一些工作，使得付出的成本能盡可能地降到最低。重構前要做工作有下面幾個方面：
1、測試用例。這個是一定要的，並且，測試用例要全面。對於ALinq來說，就是單元測試+文檔了。在重構完成后，先跑單元測試，然后再按着文檔的描述，進行操作。界面的操作是很難寫單元測試，即使可以，付出代價也太大了，遠大於人工測試。
2、划分各個功能模塊，每個模塊的職責，也就是要做些什么。
3、提煉接口，這是必須的。
下面我們進一步談談為什么要進行重構，為了讓大家能夠更理解這次的重構，先來介紹簡單一下產品的功能以及產品的發展線路。
現有功能
先來看一下圖一，圖一展示的功能主要有顯示用戶的授權信息、檢查產品的更新，顯示產品的信息。圖二展示的功能有，將修改后的模型更新到數據庫，將修改后的數據庫更新到模型，就是模型與數據庫的同步，如圖三所示。
發展線路
1、增強用戶的體驗。主要有：
- 檢查更新，然后再到網站下載，接着卸載舊版本，接着再裝新的版本。我希望將來是一點菜單，就把一系列的動作全部完成。
- 授權信息，簡單點說就是輸入注冊碼。現在是，由於產品是一年內免費更新的，如果這一年內，產品升級了，或者驗證碼的算法改了，那么就得重新發送一次驗證碼到用戶的郵箱，並且，用戶還得保管好注冊碼，如果萬一不記得了，還得找客服（客服就是我了，當然作者也是我）重新要回注冊碼。我希望是用戶一點菜單，然后輸入郵箱就可以自動取回相應版本的注冊碼，如果再輸入密碼，就能從網上下載注冊碼，然后自動完成注冊。
- 向客戶推送一些使用技巧的提示，或者文章。這是新的功能，菜單上沒有。
關於用戶體驗要做的改進，現在想到的，暫時就是這些，當然，不限於這些。
2、數據庫與模型的同步，這方面的功能現在太弱了。准備加強建模以及建庫的功能，對於建模功能，未來有可能向PowerDesigner的方面發展。而建庫的功能，就是能直接在界面上很方便對數據庫進行修改。
那么現在面臨的問題是什么呢？這部份代碼是夾雜在視圖模塊里面的。而視圖模塊這部份的功能，是很穩定的了。視圖模塊，指的是把表從數據庫里拖出來，生成實體類，或者從工具欄里，拖個圖標出來，生成實體。如果不進行重構，易變的代碼和穩定的代碼交織在一起，那么易變代碼的修改，勢必會影響到已經相對穩定的模塊。我對重構的理解是把變和不變的分開，對架構的理解是封裝變化。
那么為什么會造成這種結果？
1、業務的發展
2、沒能預期到業務的發展
話說，幾年前的東西，怎么可能預測今天要弄些啥呢，哥是人，不是神。
到這里，明白為什么要重構了，以及重構的意義了吧。重構，不是你捧着本書，對着上面的教條，看哪不順眼，就來耍耍。架構，不是你看了設計模式的書，然后依樣畫葫蘆就弄得出來的了，而是必須依據業務的發展。是否重構，必須站在業務的層面去看待，而不僅是代碼層面。如果系統很穩定，業務也很穩定，一般情況下是沒有重構的必要的，哪怕代碼寫得再爛。
架構其實就是經驗的積累，然后加上思考。當你的經驗積累到一定的程度，架構自然就會有了。所以，建議剛入門程序員，應該多花時間代碼的閱讀、算法上。可別讓那些重構、模式的書都誤導了，隨便看看就行了，不要花太多的時間。
如果我的這篇文章讓你對重構有個更深的認識，那么我的目的也就達到了，謝謝閱讀。讀完請勿忘點擊“推薦”，再次感謝。^_^
（圖一）
（圖二）
（圖三）