首先我相信我們大家都確信，系統重構會有巨大的成本投入，業務可能需要暫緩、新系統引入的問題（ bug）會帶來業務的不穩定，存在研發人員投入開銷還有各種隱性成本等等。我們服務的商業公司，獲取利潤是最終目的，投入成本做乙個專案肯定要獲得收益。重構的目標一定要能夠獲得更大的提公升，無論是業務流程、系統效能或是其他方面，如果僅僅乙個很小的改善，完全沒必要大費周章。
因此重構之前權衡好成本，重構是否能夠獲得良好的收益？
無論如何進行系統重構都是一次傷筋動骨的過程，是涅槃重生還是飛蛾撲火，完全取決我們專案執行的過程中是否明確了目標，且一直聚焦於目標的實現。保持目標的聚集是能否取得良好結果的必要條件。
如果我們僅僅確立了目標，但沒有聚集於目標，反而在多個非重要的節點投入較大資源，必然會導致我們對目標的投入降低。工作中的原始資本投入都是 8 個小時，這就需要我們明確目標聚焦目標，把有限的資源投入到最重要的事情中，才能獲得既定目標的良好結果。
團隊確認了重構的目標之後，下一步要將目標量化，確定好目標之後就能夠確認邊界，圍繞在邊界內將需要實現的事項一一羅列出來，盡可能對每個實現制定可以用資料清晰表現出來的指標，比如使用者操作的響應時間縮短到 100 毫秒、單元測試的覆蓋率達到 80%、發現問題時長降低到 30 分鐘以內等等。
有了明確的資料指標我們才能評估最終是否獲得了良好收益，這些目標必須要在重構團隊，包括產品、研發、測試甚至包括業務方在內達成一致，團隊的目標需要清晰明了，防止出現過度或是不達標是最終不能獲得良好收益。
既然決定了要對系統進行一次重構，那麼我們肯定要做到的就是要比之前做的更好，如果之前介面響應時間在 100 毫秒，而經過重構之後反而到了 200 毫秒以上，那麼大家辛苦付出的努力是不是也更加不值得。而進行重構往往是一件十分引人注目的事情，乙個微小的問題反而容易在眾人注目下變得非常嚴重的問題。為了減少引起不必要的麻煩，重構團隊就更加要注重各個方面的問題，無論是系統效能、使用者體驗還是 bug 數量等。
技術團隊進行系統重構的工作的時候往往忽略掉了業務方，認為這是技術團隊內部的事情，不需要知會業務方，這個想法是非常錯誤的，進行重構的目標就是為了改善改進業務流程，而不去和業務方提前溝通進行閉門造車，最後的結果很可能和進行重構的初衷背道而馳。進行系統重構首先我們必須了解現有系統的業務需求，是否有待改進的業務需求點，是否有新的業務訴求等，這些需求往往會影響到我們重構的進度和目標，甚至出現南轅北撤的事情。
技術團隊和業務方往往對待問題的出發角度不同，思考問題的方式也不同，在進行重構之前和業務方溝通獲得業務方的支援，往往能夠事半功倍。
例如，我的團隊在進行一塊業務系統重構的時候進入到了系統切換的試執行的階段，由於拿出的方案給到業務方無法被業務方接受，業務方提出的解決方案我們還需要進行再次開發，對整個專案進度影響了足足乙個月時間之多。吸取教訓的我們在進行下乙個專案的時候提前和業務方進行了溝通，業務方從他們的角度給予了很多的意見和建議以及業務未來的發展方向的指引，我們發現這些建議和意見幫助我們更好理解業務的同時也大大的降低了我們工作量，減少了我們很多冗餘的設計。
參與過重構專案的朋友都知道，重構專案往往是個時間跨度很長的工作，少則一兩個月多則一年半載都有，如果不將整個重構進行合理拆分，而是採用全部開發完成，再進行系統切換的方式會對整個重構引入很大的風險。首先長時間的時間跨度內業務會進行持續變更，其次團隊面臨長時間沒有結果輸出面臨來自各個方面的壓力，還有系統問題持續累積，這種蒙頭狂奔的方式往往造成了專案失敗或是目標便宜。
而採用迭代方式進行重構，可以以更小的顆粒度持續交付工作成果，交付 - 試用 - 反饋 - 調整，持續有交付，持續有反饋，持續調整能夠保證團隊的目標不會偏移，形成乙個正向迴圈，保證最後的重構目標。
知己知彼，百戰不殆，系統重構是乙個與舊系統對抗的過程，不對舊系統的弄的清清楚楚怎麼能夠比舊系統做的更好呢？其實了解現有系統是乙個學習的過程，如果有舊系統的開發人員還在公司，那麼就事半功倍了，舊系統的開發同學幫忙給做次分享，省去了我們重構團隊很多的工作，比直接去讀**更能清晰明了的了解到舊系統的相關知識，以及有哪些需求點和應該注意的問題等等，通過學習和了解舊系統設定目標基準值避免引入老舊問題，也是避免重蹈覆轍的乙個好辦法。
不知道朋友有沒有遇到過，重構完系統發現，如果進行新舊系統的切換是個難題。我們以前遇到過由於沒有提前做好規劃和切換步驟，導致最後臨時抱佛腳，開始使用各種奇葩辦法做系統切換，有的還需要增加額外工作量，甚至各種辦法的刷臉求人，總之這不是乙個很好的體驗。
系統切換往往是在重構中被我們忽略的乙個步驟，但是這是非常重要的乙個環節，在做最初的計畫就應該考慮到如何進行系統切換，乙個設計好的切換方案也應該貫穿重構始終，避免因為切換方案引起服務不可用或是引入系統 bug。尤其是前期整個團隊付出巨大努力取得了一定成果的時候，在最後一步切換的時候出現問題，對團隊是個非常大的打擊，也使得業務方對團隊失去信心，帶來很不必要的麻煩。
一次系統重構大多數情況下會涉及到資料結構的修改，對資料結構進行修改必然引入很大的風險，尤其在一些老舊的業務系統重構精簡，業務去掉冗餘資料的時候，往往需要將老資料的業務資料重新寫入到新系統的資料庫。重構的目標是為了比舊系統更好，無論是效能還是業務方面，如果我們對資料的操作導致外部依賴舊系統的業務無法正常執行，那將是影響 sla 指標的問題。說到系統資料有些同學可能僅僅關注的是業務資料，其實資料也包含了系統執行所產生的日誌資料，無論新舊系統的日誌資料，都是很重要的，如果因為重構影響到資料的讀取、處理、分析，則是得不償失的事情。
技術選型是重構工作的基石，選擇一套成熟穩定的技術方案是重構專案完成的必要條件。有些時候我們引入最新版的資料庫雖說會有效能提公升但是也會引入一定的不穩定因素，之前我們團隊在使用 mongodb 的乙個新版本的時候，發現主從庫的資料並不能很好的同步，出現過丟失資料的情況，進入社群發現這個版本使用的使用者很多都反饋了這個問題，這時候我們不得不選擇了大多數人共同的乙個選擇，降低了乙個版本來解決問題，相信此類情況比比皆是。在不是很成熟的方案帶來並不顯著的效能提公升，反而還會引入不確定的風險的時候，我們需要權衡利弊得失，重構更是要保證系統的穩定性。
技術方案能否有足夠強大的支撐也是我們需要考慮的乙個方面，現在我們團隊面對的重構是從單體式架構往微服務轉變，舊系統的版本構建在是 php 語言上，新的系統我們由兩個選擇繼續選擇用 php 進行重構或是採用公司統一的微服務框架，我們毫不猶豫的選擇了使用公司統一的微服務，這樣做有幾個顯而易見的好處。
和公司內部進行互動更加方便快捷；
可以直接獲取成熟的經驗；
基礎服務有公司級的支援；
以上的好處，顯然對我們能否成功重構系統並且獲得足夠的幫助起到了顯著的幫助，反而採用 php 進行微服務，公司內部並無成功經驗可以借鑑，業內也並無太多可靠的方案可以進行選擇。乙個成熟可靠的的技術方案是我們能否更進一步的保障和基石。
參與過重構的同學都知道重構工作是一項枯燥乏味的工作，往往周期長、複雜度、難度大、牽扯廣、優先順序低，而且很有可能是一件費力不討好的工作。開發乙個業務方期待的新功能、新模組往往比一場翻天覆地的重構更能引起業務方的重視，也更容易獲取良好結果與反饋，反而不需要承擔大多的壓力。
但是越是面對這樣的情況越是需要加大對團隊的鼓勵增強團隊的信心，消除團隊的疑慮困惑，給予團隊持續的鼓勵，給整個團隊注入正能量，讓團隊保持積極向上的團隊氛圍，即使面對各種困難、問題，也始終對團隊保持信心保持樂觀，讓大家輕鬆愉快的投入到重構工作中，盡量不擔負額外的壓力。
系統設計經驗總結
極簡原則 夠用就好原則。設計世界上有兩類人，一種喜歡把事情越做越複雜 別人有的功能我要全有，也許是個賣點，單不一定被多數人接受 一種喜歡追求極致 如 喬幫主 蘋果產品持續有這麼多的粉絲，持續購買，對於大部分使用者來說外觀精緻，操作簡捷容易上手。商業成功原則 設計的好壞，最終其實只有乙個，市場是否認可...
ASP開發10條經驗總結
歷時半年，我獨自一人完成了乙個局級單位的管理資訊系統，共發布beta版29次，正式版本3次。asp oracle環境，285個asp檔案，功能涉及資料錄入 修改 模糊查詢 自動統計 資料分析和報表，這個專案正在申報省級成果，現將我的10條經驗總結如下，不對之處歡迎批評指正 1.不要再做asp是否過時...
ASP開發10條經驗總結
1.不要再做asp是否過時的討論，重要的不是你是否使用先進的技術，而是你的設計思想是否先進 2.設計時要考慮專案的通用性，永遠不要做沒有推廣價值的東西 為保飯碗除外 3.程式設計要簡潔，足夠好的面向過程遠遠優於蹩腳的物件導向 4.理論是為實踐服務的，所以不要被理論 尤其是設計模式 束縛 5.分工合理...