持續(xù)迭代的復雜系統(tǒng)確實更難治理，各種評估方法和標準出來之后，會看到非常多的問題，從技術(shù)的角度來看很多都是不能忍，必須要去修改的，復雜系統(tǒng)對應的業(yè)務又比較重要，往往牽一發(fā)而動全身。

做架構(gòu)治理度量只是輔助手段，還是要從業(yè)務痛點入手，對問題進行優(yōu)先級排序。因為只有站在業(yè)務視角來看，優(yōu)先級才更有價值，有些代碼和架構(gòu)爛到不行，但需求很少，基本不改，線上問題也不多，當下修改的優(yōu)先級就非常低，甚至是沒有必要的。

業(yè)務價值較高的優(yōu)化動作大多涉及架構(gòu)和組件級別的設計，一旦要做優(yōu)化，動靜都不小，而且都是底層改動，涉及大部分甚至是全部的業(yè)務模塊，如果準備做不充分，基本都是一通治理上線就出大問題。這種優(yōu)化不能急于求成，前期準備要做好，要按一定的節(jié)奏來：

• 首先要有方案的可行性評估，效果評估，至少要找一個最復雜的場景做一次驗證，避免真正開始做之后才發(fā)現(xiàn)大量未知的問題。
• 其次是要有試點，方案上不能一次全部完成再上線，而要小步迭代，逐步驗證優(yōu)化效果。
• 最后還要保證有可用的回退機制，上線產(chǎn)生問題后，隨時可以回退到可用版本，不至于影響業(yè)務。

代碼級別的設計，即便做的很好，業(yè)務側(cè)效果并不那么顯著。優(yōu)化主要依賴于日常的實踐，這個要先定規(guī)范和標準，做好把關(guān)，先保證正在進行的要符合規(guī)范，逐步改善，是個長期活動。但代碼設計也非常重要，只有好的代碼設計才能支持架構(gòu)和組件級別的優(yōu)化，具有可行性且成本可控，否則重構(gòu)的成本可能比重寫還大，不如推倒重來。