逐个解决问题的三大缺陷，催生"分段实施"的必要性

通常需要架构重构的系统，基本都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，到了一个临界点，各种问题开始互相作用、集中爆发。架构师识别出系统关键的复杂度问题后，如果只针对这个复杂度问题进行架构重构，可能会发现根本无法落地——因为很多前置条件不具备，或者有的问题不先解决，架构重构就是做不了。因此架构师在识别出关键复杂度问题后，还需要识别为了解决这个问题，需要先做哪些准备工作、先解决哪些前置问题。经过分析，团队可能从最初上百个问题里，挑出其中一半是需要在架构重构过程中解决的，一部分是基础能力建设或准备工作，另一部分才是架构重构的核心工作。面对这样一份问题清单，最简单的做法是每次挑一个来解决，最终总能把所有问题都解决掉——这种做法操作简单，但效果会很差，原因有三点：第一，没有区分问题优先级，所有问题一视同仁，没有把有限资源集中投向最重要或最关键的问题，导致做了大半年回头一看好像做了很多事，却没取得什么阶段性成果；第二，没有把问题分类，导致相似问题没有被统筹考虑，方案容易出现反复、效率不高；第三，迫于业务版本的压力，容易专挑容易做的先实施（”挑软柿子捏”），到了稍微难一点的问题就因为复杂度和投入等原因被搁置，达不到重构的真正目的。书中以X系统为例：作者加入前，系统的可用性、性能、安全、用户体验等问题也曾被整理成清单，但实施时基本上就是挑好落地、占用资源不多的先做，结果做了半年，看似做了很多功能，整体却没什么进展——这正是三大缺陷叠加的真实后果，也是需要”分段实施”这套方法的根本原因。