這個問題很實際，很多人在工作中，總會接觸到一些“陳年”系統，可能經歷了超過10年的迭代，而且開發者可能也已經換了好幾批了。在程式碼可能隱藏著無數的“神秘地帶”，讓人不敢觸碰，所以在接受這樣的系統能做的也只有針對出現的問題來打一些補丁，並不敢進行任何的最佳化。其實這種狀態已經是非常糟糕的了，無論是對於業務發展還是個人發展。所以針對這種情況最迫在眉睫的就是重構！！

重構可能存在的問題

那麼問題來了，一個迭代了N年的系統一定積累了龐大的功能，而且肯定有好多功能當初並沒有留下文件，以至於很多業務需求並不能直接理清楚。另一方面，這個系統肯定在接下來的一段時間繼續有新的功能加入，那麼如何在這種情況下進行重構呢？

重構的實施

重構的實施可能會面臨很多的問題，尤其是對於規模比較大的系統，所以我個人的建議是分步驟進行重構。

需求分析及全域性架構設計。這裡把需求分析和架構設計合併為一個步驟，是因為這兩者是密切相關的。因為舊的系統可能歷經的時間比較長，所以需要集合業務專家來一起梳理業務需求，理清楚現有的業務需求，分析現有的需求是否能夠滿足，以及未來需求的發展趨勢。這些資訊越完善，對於架構設計的作用越大。理清楚需求之後，就是要按照現有需求以及未來的需求發展來設計出合理的技術架構，在可靠性，安全性，可擴充套件性，可維護性等等方面要做到合理的設計。新舊雙系統同時執行。這裡主要是出於幾個原因，首先新的需求優先在新的系統中完成，除非新的需求對於舊系統中的某些功能需要高度依賴（在設計中應該儘可能避免這種情況）。然後將舊系統中的功能逐步向新系統進行重構遷移後，可以逐步的向新系統分配流量，發現問題可以及時切換到舊系統。這樣可以儘可能的保證線上服務的可用性。按照功能獨立性進行重構。這是一種可行性很高的操作方式。在舊系統中很多功能可以和其他功能的耦合度很低，這種功能在重構起來問題是比較小的，可以優先進行重構。然後耦合度比較高的功能要按照實際情況進行設計，儘可能的降低耦合度，這樣也是為了新系統有好的可維護性。然後功能在新系統重構完成後，測試透過以後，可以停掉舊系統的功能，然後開放新系統的功能。文件留存。這一步雖然很多人不喜歡做，但是這個是很有必要的，不僅僅是為了系統的發展，工作的交接，另一方面對於自己未來對於系統的維護也是有很大的作用的。

按照上述步驟，逐步的完成舊系統到新系統的重構。可以較為靈活的安排重構任務，也可以靈活的接受新的需求。不會使某項工作阻塞在某個階段。對於很多情況下都是比較合適的。

總結

系統重構是一個階段性梳理需求、沉澱技術架構、最佳化系統性能的重要手段。但是系統重構也是一個極具風險的操作，所以在實施中應該要想辦法儘可能的把風險降到最低，同時要能夠兼顧到系統可靠性，安全性，可擴充套件性，可維護性等等方面，這就需要架構師豐富的經驗了。最後要說的是，重構不是萬金油，好的開發規範才是系統穩定保障。

民用作業系統的生態是一個很關鍵的問題。如果重新做一個新的系統，如何說服軟體開發商為你這個新系統開發軟體或者把應用遷移到你這個系統上