【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
1. 引言
一般来说，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。
2. 运筹帷幄
可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去把这50个问题最终解决呢？
最简单的做法是每次从中挑一个解决，最终总会把所有的问题都解决。这种做法操作起来比较简单，但效果会很差，为什么呢？
- 第一个原因是没有区分问题优先级，所有问题都一视同仁，没有集中有限资源去解决最重要或者最关键的问题，导致最后可能出现做了大半年，回头一看好像做了很多事情，但没取得什么阶段性的成果。
- 第二个原因是没有将问题分类，导致相似问题没有统筹考虑，方案可能出现反复，效率不高。
- 第三个原因是会迫于业务版本的压力，专门挑容易做的实施，到了稍微难一点的问题的时候，就因为复杂度和投入等原因被搁置，达不到真正重构的真正目的。
以X系统为例，在我加入前，其实也整理了系统目前存在的问题，大的项包括：可用性、性能、安全、用户体验等，每个大项又包括十几二十个子项。但是实施的时候基本上就是挑软柿子捏，觉得哪个好落地、占用资源不太多，就挑来做，结果做了半年，好像做了很多功能，但整体却没什么进展。
我加入后成立了一个“X项目”，在原来整理的问题基础上，识别出架构和业务目前存在的主要问题是“可用性不高”和“可扩展性”不足，其中可用性不高有的原因是因为硬件资源不够用了，或者某些系统组件使用不合理，有的是因为架构上存在问题；可扩展性不足主要原因是系统耦合比较严重，这同时也是可用性不高的一个原因。
基于这些分析，我们制定了总体的策略：
上图是去年7月份的时候制定的，目前已经完成第一阶段和第二阶段的工作，第三阶段因为实际问题比我们预想的更加复杂，加上其它因素，目前还在进行中。
为什么确定这样一个策略呢？主要还是为了集中有限的资源，某个阶段集中解决某一类问题。这样做首先是效率高，因为阶段目标比较明确，做决策和方案的时候无需太多选择；其次是每个阶段都能看到明显的成果，给团队很大的信心。比如说第一阶段的“救火”，做完之后，系统很少因为机器过载、缓存响应慢、虚拟机挂死等问题导致的故障了；完成第二阶段的事项后，因为组件、外部系统故障导致系统故障的问题也很少了。完成前两个阶段后，我们就可以安心的做第三阶段的“服务化”工作了。
S系统的重构做法也是类似，但S系统当时面临的主要问题就是可用性不高，并没有系统耦合的问题，所以我们当时的策略是“先救火、后优化、再重构”，“救火”阶段做了扩容（防止资源不足导致系统被压死）和Nginx一键倒换功能（故障时快速切换）；优化阶段将一些明显的可用性问题解决（包括性能问题等）；重构阶段将原来的单点数据库改为多中心。
总结一下重构的做法，其实就是“分段实施”，将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题。这样做有几个好处：
1）每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易
2）每个阶段的工作量不会太大，可以和业务并行
3）每个阶段的改动不会太大，降低了总体风险
3. 小结
具体如何制定“分段实施”的策略呢？以下经验可以参考：
3.1 划分优先级
将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题。例如扩容在S系统和X系统中都是最优先实施的，因为如果不扩容的话，系统隔三差五一会来个响应超时报警，一会来个过载报警，一会来个大面积不可用。。。。。。这些问题耗费大量的人力和精力，也就没法做其它事情了。
3.2 问题分类
将问题按照性质分类，每个阶段集中解决一类问题。例如X系统的第二阶段，我们将多个底层系统切换到UC统一的公共组件，提升整体可用性。
3.3 先易后难
这点与很多人的直觉不太一样，有的人认为应该先攻克最难的问题，所谓的“擒贼先擒王”，搞定最难的问题后其它问题就不在话下。这样看起来很美好，但实际上不可行。
- 首先，一开始就做最难的部分，会发现要搞定这个最难的问题，要先搞定其它容易的问题；
- 其次，最难的耗时都比较长，占用资源比较多，如果一开始做最难的，可能做了一两个月还没有什么进展和成果，会影响相关人员对项目的评价和看法，也可能影响团队士气；
- 第三，刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错。
采取先易后难的策略，能够很大程度上避免“先难后易”策略的问题。
- 首先，随着项目的推进，一些相对简单的问题逐渐解决，会发现原来看起来很难的问题已经不那么难了，甚至有的问题可能都消失了；
- 其次，先易后难能够比较快的看到成果，虽然可能不大，但至少能看到一些成效了，对后续的项目推进和团队士气有很大好处；
- 第三，随着项目的进行，原来遗漏的一些点，或者分析和判断错误的点，会逐渐显示出来，及时根据实际情况进行调整，能够有效的保证整个重构的效果。
来源：oschina
链接：https://my.oschina.net/u/2858189/blog/753016