但是，隨著應用的不斷發展，最初的架構往往面臨著各種問題，比如無法滿足客戶的需求、無法實現應用的擴充套件、無法實現新的特性等等。在這種情況下，我們如何避免一些坑，盡量比較成功地實現架構的重構，是很多開發者和架構師亟需解決的問題。
\\確定重構的目的和必要性
\\ 看起來這個規矩有些多餘，但是請不要忽略。每一次架構的重構都是「傷筋動骨」，就像做手術一樣，即使再成功，也會傷元氣，所以決策者們首先要分析架構重構的理由和其他備選方案，明確重構的目的是為了滿足業務需求，並且是不得不做的最佳方案，然後再考慮其他問題。 有時候，經過分析就會發現，也許還有其他解決方案，比如增加計算資源，或者重構的目的不是為了業務需求，那就沒有必要做了。
\\ 檢查清單：\\
定義「重構完成」的界限
\\ 如果確定要重構，那麼要把目標明確下來，也就是重構的邊界條件，怎麼才算是「完成」了重構，目標要有資料量化，或者有能夠測試的辦法。這也是乙個需求分析的過程，如果需求不明確，那麼規格說明書沒法寫清楚，負責重構的團隊也沒有明確的目標，不能以重構的時間或者主觀的判斷為結束的依據。前幾天和一朋友聊天，他最近在負責系統的效能優化，也要做一些重構的事情，開始的時候團隊的目標不明確，大家不知道優化到什麼程度，所以不敢下手。如果目標是提高10%，那麼可以從細節處著手；如果是提高50%，那可能要搞大動作才能實現了。後來目標明確之後，團隊才找到合適的辦法。
\\ 檢查清單：\\
漸進式重構
\\ 現在軟體研發最流行的就是快速迭代、持續交付、盡早反饋。這同樣可以用在架構的重構上，重構過程的難度不亞於構建乙個新產品，所以在設計重構的時候，要引入持續交付的流程，每乙個重構步驟或者模組都要快速部署並得到反饋，以便評估重構的效果，及時作出策略調整。有的讀者會說，我們的架構重構是釜底抽薪型的，沒法漸進，只能一蹴而就。如果是這種情況，可以考慮在另外一套拷貝的系統中做重構，經過謹慎測試之後，將資料和業務遷移過去。
\\ 檢查清單：\\
確定當前的架構狀態
\\ 在啟動重構之前，團隊要對當前的架構狀態有清晰的了解，也就是設定好基準，以便評估重構的效果。據我的經驗，負責重構的架構師或者開發者，往往還沒有搞清楚現有的架構設計，就開始重構了，結果經常出現這樣的情況：重構到某個階段，發現行不通，然後一拍腦袋說，哦，原來這塊的架構是這個樣的，是為了達到某某業務需求啊，這塊不能動，得想別的辦法。類似的例子在研發團隊中時有發生，也提醒我們要慎重小心。記得有位哲人說過，了解別人很容易，了解自己很難。
\\ 檢查清單：\\
不要忽略資料
\\ 資料的重要性不言而喻，業務都是以資料流為載體的，所以架構重構的本質就是對於資料流的重構。資料對重構的重要性主要體現在兩個方面：在重構設計時，需要考慮業務資料的需求，重構之後的系統對於資料的儲存、處理、分析等功能是否有影響；在重構過程中，考慮依靠資料甚至是實際的資料來驗證重構的效果，提供評估的支援。
\\ 檢查清單：\\
管理好技術債務
\\ 技術債務在平常的軟體研發過程中也是比較突出的問題，現在單獨拿出來強調是希望提醒開發者們：架構重構往往是為了償還技術債務，所以請不要在償還技術債務的過程中製造技術債務了。技術債務就像信用卡一樣，會有很高的利息率，就如同給團隊留下了大量的帳務開銷。組織應該培養一種保證設計質量的文化。應當鼓勵重構、同時也應當鼓勵持續設計以及其它有關**質量的實踐。在開發時間中應當專門抽出一部分以解決技術債務。如果沒有合適的照料，那麼真實世界中的**會變得越來越複雜難懂。
\\ 檢查清單：\\
\\
架構之重構的12條軍規（上）
但是，隨著應用的不斷發展，最初的架構往往面臨著各種問題，比如無法滿足客戶的需求 無法實現應用的擴充套件 無法實現新的特性等等。在這種情況下，我們如何避免一些坑，盡量比較成功地實現架構的重構，是很多開發者和架構師亟需解決的問題。確定重構的目的和必要性 看起來這個規矩有些多餘，但是請不要忽略。每一次架構...
架構之重構的12條軍規（上）
但是，隨著應用的不斷發展，最初的架構往往面臨著各種問題，比如無法滿足客戶的需求 無法實現應用的擴充套件 無法實現新的特性等等。在這種情況下，我們如何避免一些坑，盡量比較成功地實現架構的重構，是很多開發者和架構師亟需解決的問題。確定重構的目的和必要性 看起來這個規矩有些多餘，但是請不要忽略。每一次架構...
架構之重構的12條軍規（上）
但是，隨著應用的不斷發展，最初的架構往往面臨著各種問題，比如無法滿足客戶的需求 無法實現應用的擴充套件 無法實現新的特性等等。在這種情況下，我們如何避免一些坑，盡量比較成功地實現架構的重構，是很多開發者和架構師亟需解決的問題。確定重構的目的和必要性 看起來這個規矩有些多餘，但是請不要忽略。每一次架構...