持续迭代的复杂系统确实更难治理，各种评估方法和标准出来之后，会看到非常多的问题，从技术的角度来看很多都是不能忍，必须要去修改的，复杂系统对应的业务又比较重要，往往牵一发而动全身。
做架构治理度量只是辅助手段，还是要从业务痛点入手，对问题进行优先级排序。因为只有站在业务视角来看，优先级才更有价值，有些代码和架构烂到不行，但需求很少，基本不改，线上问题也不多，当下修改的优先级就非常低，甚至是没有必要的。
业务价值较高的优化动作大多涉及架构和组件级别的设计，一旦要做优化，动静都不小，而且都是底层改动，涉及大部分甚至是全部的业务模块，如果准备做不充分，基本都是一通治理上线就出大问题。这种优化不能急于求成，前期准备要做好，要按一定的节奏来：
- 首先要有方案的可行性评估，效果评估，至少要找一个最复杂的场景做一次验证，避免真正开始做之后才发现大量未知的问题。
- 其次是要有试点，方案上不能一次全部完成再上线，而要小步迭代，逐步验证优化效果。
- 最后还要保证有可用的回退机制，上线产生问题后，随时可以回退到可用版本，不至于影响业务。
代码级别的设计，即便做的很好，业务侧效果并不那么显著。优化主要依赖于日常的实践，这个要先定规范和标准，做好把关，先保证正在进行的要符合规范，逐步改善，是个长期活动。但代码设计也非常重要，只有好的代码设计才能支持架构和组件级别的优化，具有可行性且成本可控，否则重构的成本可能比重写还大，不如推倒重来。
