系统重构的注意点

相比全新的设计来说，重构相对更复杂，主要体现在：

• 业务已经上线，不能停下来；
• 关联方众多，牵一发动全身，如何尽量减少对关联方的影响，或者协调关联方统一行动，是一项很大的挑战；
• 旧架构的约束，重构需要在旧的设计基础上进行，这是一个很强的约束，会限制选择范围，即使是推倒重来，完全抛弃旧的而去设计新的，新设计也会受到旧设计的约束和影响，因为业务在旧方案上产生的数据是不能推倒重来的，新设计必须考虑如何将旧方案产生的数据转换过来。

有的放矢

通常情况下，当系统设计不满足业务的发展时，其表现形式是系统不断出现各种问题，轻微一点的如系统响应慢、数据错误、某些用户访问失败等，严重的可能是宕机、数据库瘫痪、数据丢失等，或者系统的开发效率很低。

期望通过设计重构来解决所有问题是不现实的，重要的是从一大堆纷繁复杂的问题中识别出真正要通过重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。否则就会陷入人少事多头绪乱的处境，团队累死累活弄个大半年，最后发现好像什么都做了，但每个问题都依然存在。

如何判断到底是采取架构重构还是采取系统优化，这里分享一个简单的做法：假设我们现在需要从 0 开始设计当前系统，新架构和老架构是否类似？如果差异不大，说明采取系统优化即可；如果差异很大，那可能就要进行系统重构了。

对于原来发现的非架构重构问题怎么办呢？
当然不能放任不管，在重构完成后，可以启动多个优化的项目去优化这些问题，此时优化主要由团队内部完成，和其他团队没有太多关联，优化的速度是很快的。如果没有重构就进行优化，则每次优化都要拉一大堆关联业务的团队来讨论方案，效率非常低下！

沟通协调

系统重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免地会影响业务功能的开发。因此，要想真正推动一个系统重构项目启动，需要花费大量的精力进行游说和沟通。要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。

合纵

与产品、运营等相关方沟通协调。

• 在沟通协调时，将技术语言转换为通俗语言。技术术语并不是很好理解，在跨领域沟通时，很难达成一致共识(产品、运营和项目人员等对技术属于的理解不一致)；
• 以事实说话，以数据说话，不要凭感觉。比如技术人员说系统耦合导致我们的开发效率很低，但是没有数据，也没有样例，单纯这样说，其他人员很难有直观的印象。可以说开发一个什么功能，由于系统设计的不合理，开会沟通讨论占用一个礼拜，实际开发就一两天。

连横

和其他相关或者配合的系统的沟通协调。
由于大家都是做技术的，有比较多的共同语言，所以沟通协调相对来说要容易一些，但也不是说想推动就能推动的，主要的阻力来自

• 这对我有什么好处
  有效的策略是换位思考、合作双赢、关注长期。简单来说就是站在对方的角度思考，重构对他有什么好处，能够帮他解决什么问题，带来什么收益。
  当然如果真的出现了对公司或者部门有利，对某个小组不利的情况，那可能需要协调更高层级的管理者才能够推动，平级推动是比较难的。
• 这部分我这边现在不急
  对于这个问题，有的人可能会认为这是在找借口，也不排除这种可能性。但就算真的是找借口，那也是因为大家没有达成一致意见，可能对方不好意思直接拒绝。所以这种情况还是参考上面这对我有什么好处问题的处理方法来处理。
  如果对方真的是因为有其他更重要的业务，此时勉为其难也不好，还是那句话：换位思考！因为大部分重构的系统并不是到了火烧眉毛非常紧急的时候才开始启动的，而是有一定前瞻性的规划，如果对方真的有其他更加重要的事情，采取等待的策略也未尝不可，但要明确正式启动的时间。例如，3 个月后开始、6 月份开始，千万不能说以后、等不忙的时候这种无法明确的时间点。

分段实施

通常情况下，需要重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，在识别出系统关键的复杂度问题后，如果只针对这个复杂度问题进行设计重构，可能会发现还是无法落地，因为很多条件不具备或者有的问题没解决的情况下就是不能做系统重构。所以，在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题，如下：

• 区分问题的优先级
  不能所有问题都一视同仁，需要集中有限资源去解决最重要或者最关键的问题，否则可能最后做了大半年，回头一看好像做了很多事情，但没取得什么阶段性的成果。
• 将问题进行分类，相似问题统筹考虑，避免方案出现反复；
• 避免迫于业务版本的压力，专门挑容易做的实施，到了稍微难一点的问题的时候，因为复杂度和投入等原因被搁置，达不到重构的真正目的，列清楚计划，逐步的去解决；

分段实施：将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题。这样做有几个好处：

• 每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易；
• 每个阶段的工作量不会太大，可以和业务并行；
• 每个阶段的改动不会太大，降低了总体风险；

优先级排序

将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题。

问题分类

将问题按照性质分类，每个阶段集中解决一类问题。

先易后难

首先看看先难后易的缺陷：

• 一开始就做最难的部分，会发现想要解决这个最难的问题，要先解决其他容易的问题。
• 最难的问题解决起来耗时都比较长，占用资源比较多，如果一开始做最难的，可能做了一两个月还没有什么进展和成果，会影响相关人员对项目的评价和看法，也可能影响团队士气。
• 刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错。

对于先易后难，可以避免上述的问题，同时还有如下好处：

• 随着项目的推进，一些相对简单的问题逐渐解决，会发现原来看起来很难的问题已经不那么难了，甚至有的问题可能都消失了。
• 先易后难能够比较快地看到成果，虽然成果可能不大，但至少能看到一些成效了，对后续的项目推进和提升团队士气有很大好处。
• 随着项目的进行，原来遗漏的一些点，或者分析和判断错误的点，会逐渐显示出来，及时根据实际情况进行调整，能够有效地保证整个重构的效果。

循序渐进

按照前 3 个步骤划分了重构的实施阶段后，就需要评估每个阶段所需要耗费的时间，很可能会出现有的阶段耗时可能只要 1 个月，而有的却需要 6 个月，虽然这可能确实是客观事实，但通常情况下，按照固定的步骤和节奏，更有利于项目推进。我((原文作者))的经验是每个阶段最少 1 个月，最长不要超过 3 个月，如果评估超过 3 个月的，那就再拆分为更多阶段。比如我们可以先划分阶段，每个阶段再划分任务子集，当任务子集比较小的时候，多个任务子集可以并行；当任务子集比较大的时候，就当成一个独立的里程碑推进。

如果一个阶段时间太长，即表明这么长时间没有什么可观的成果出来，如此其他相关方会有不少变数

--------来源《极客课程》∙ 学习摘要