第一，先了解业务再重构。 先把业务了解清楚，再去重构，不然这次重构很大可能是失败的，并且会导致你提桶跑路。

第二，小步快跑。 无论如何，还是要保持小步快跑的方式，每次改动较少的地方，然后完成上线。而不要一次性改动太多的地方。

第三，注重沟通。 积极与领导沟通，让他明白你当前的进度，必要时咨询他的意见。切忌自己闷头搞开发，最后别人都不知道你在做什么。

第四，给出自己的方案。 要有自己的思考，能给出自己的方案。对于领导不切实际的方案，要懂得提出自己的意见，引导领导按照自己的思路去做，从而按自己的节奏走。

第五，做好充分的测试。 单元测试是最基本的内容，一定要做好单元测试。对于无法做单元测试的，一定要让测试同学做充分的功能测试。

 

下面是别人的经验分析：

博主个人独立站点开通啦！欢迎点击访问：https://shuyi.tech

蓦然回首，我已经工作七年了。在这七年的时间里，做过了无数个项目，但要说大的重构，只有三个。第一个是在我工作三年时，重构公司的聊天 IM 系统。第二个是我在现在的这个公司，重构了整个业务线的业务架构。第三个是现在我正在做的，重构消息中台的技术架构。

IM 系统重构

2017 年的我，毕业三年了，但是从来没有重构过一个系统，就连一个模块也没有。而刚好就在这个时候，公司考虑到原有聊天功能不太友好，决定对原有聊天功能进行重构。于是组件了一个项目组，有两个架构师再加上我去做这个事情。

由于当时的我并不清楚如何设计一个 IM 系统，所以我分配到的是业务逻辑代码梳理，而其他两位同学则是进行架构设计，以及 IM 通信层面的代码编写。正是由于这样的分工，让我后面越做越难受。

这是一个积累了十年的功能系统，沉积了无数的业务逻辑，而且很多业务逻辑很多人也不清楚。当然了，单元测试肯定也是没有的，测试用例肯定也是没有的。在这样的情况下，我只能自己厚着脸皮一点点地去撸代码弄清楚业务逻辑。

后面回头来看，这种方式真的是最低效率的方法。如果不到万不得已，千万别这么做。最好的方法是找一个人捋清整体思路，之后再一点点弄清细节。另外，最好的重构方式不是一开始就重写，而是一个功能一个能地重写，这样才更加稳妥。

另外一个重要的点是向上沟通。很多时候我们都是按照上级的指令行事，但是却不提出自己的想法和方案。但对于重构这件事情来讲，如果不做好沟通，很可能会出大事。像这种大系统，功能众多、细节复杂，一开始就应该和领导打上预防针，并且争取分阶段、分模块开发，降低自己的风险。一般情况下，领导考虑到开发的风险，都会同意按照你的方案去做。如果领导执意要一次性做完，那你也尽到了自己的责任，后续出问题做不完，也不全是你一个人的问题了。

这个项目最终做一个多月才做完上线，主要的时间是在梳理业务逻辑上。在这过程中自己也一度快做不下去了，甚至做到后期有点抑郁了。现在回想来看，就是自己重构经验不足，心态又不好导致的。

文章首发于公众号「陈树义」及个人博客 shuyi.tech，欢迎关注访问。

业务线重构

熟悉的朋友都知道，我从唯品会出来后，就去了现在的公司。当时这块业务是从别的部门交接过来的，我们算是从零开始去熟悉这块业务。对比起上次的系统重构，这次的规模更大，直接是整个 CRM 业务线的重构。我作为技术 leader 则是参与组建了整个技术团队，并主导设计、推动落地了整个 CRM 的系统架构。

CRM 系统看起来就是一个 B 端系统，一个管理后台有什么好做的嘛。一开始我也这么觉得，但慢慢深入了解之后发现：这个东西还是不简单。经过一段时间的了解，我发现原有系统存在一些问题，例如：系统功能混在在一起，功能模块之间没有清晰的的划分；后台模块耦合在一个项目中，没有做合理的模块拆分；等等。

经过一段时间对业务的深入了解，结合对业界公司解决方案的对比，我设计出了全新的业务架构图。整个业务架构图将系统功能分为了三大系统：消息管理平台（MMP）、营销发送平台（MSP）、营销分析平台（MAP)。

经过与技术总监、产品总监沟通，他们对这个方案感到很满意，决定后续按照这个方案去推动。在整体产品、开发、测试团队的一起努力下，我们经过了半年的时间，将原有的 PHP 与 Java 系统共存的业务项目，成功改造完成了上面所说的三大系统。

对比起两年前的那次重构，这次重构是更大意义上的、业务架构层面的架构。 也是这次成功的系统重构经验，让我学会了如何从零开始去做一个业务，如何从零开始去重构一整个业务系统。后面有机会，我再写一写这块的文章。

文章首发于公众号「陈树义」及个人博客 shuyi.tech，欢迎关注访问。

消息中台重构

还记得前面说到的消息管理平台吗？其实这个就是消息中台的前身。在这之前，消息管理平台只是负责发送小批量的消息（100条以下）。但随着业务的发展，我们发现有很多系统也需要发送几十万、甚至几百万的数据。而在这之前，这个需求只有我们这块业务有。而这块业务实现则是我们单独放在营销发送平台实现，并没有抽离出来作为中台服务。

经过与小伙伴们的讨论，以及对未来业务发展的考虑，我们发现后续应该会有越来越多的系统需要用到这个功能，于是我们决定将原本在营销发送平台的功能抽离出来，放入消息管理平台。而消息管理平台则作为消息中台，掌管所有与用户通信的渠道，包括：邮件、短信、Push 等等。

虽然做架构决策很快，但是怎么去做调整，项目之间的众多细节如何处理，却是一个非常苦恼的问题。对于我来说，我擅长与抽象总结归纳，因此对于整体架构上游刃有余。但重构的具体实现，如何设计得更有扩展性，则更考验程序员的代码实现基本功。

目前这块内容的重构还在进行，等到做得差不多之时，我再分享关于这块内容的重构经验。

总结

这篇文章分享了我工作七年来的三次重大重构经验，也算是对我职业生涯里有关重构的一个总结。每一次重大的重构经验，都让我从中汲取养分，在下次重构时做得更好，让我更加游刃有余。经历过这么几次重大的重构，我也发现了不少重构的经验，这里简单总结下。

第一，先了解业务再重构。 先把业务了解清楚，再去重构，不然这次重构很大可能是失败的，并且会导致你提桶跑路。

第二，小步快跑。 无论如何，还是要保持小步快跑的方式，每次改动较少的地方，然后完成上线。而不要一次性改动太多的地方。

第三，注重沟通。 积极与领导沟通，让他明白你当前的进度，必要时咨询他的意见。切忌自己闷头搞开发，最后别人都不知道你在做什么。

第四，给出自己的方案。 要有自己的思考，能给出自己的方案。对于领导不切实际的方案，要懂得提出自己的意见，引导领导按照自己的思路去做，从而按自己的节奏走。

第五，做好充分的测试。 单元测试是最基本的内容，一定要做好单元测试。对于无法做单元测试的，一定要让测试同学做充分的功能测试。

好了，关于重构的分享，今天就聊到这儿。

 

参考：

[七年三次大重构，聊聊我的重构成长史 - 陈树义 - 博客园](https://www.cnblogs.com/chanshuyi/p/my-refactor-experiment.html )]

标签：重构,大型项目,架构,系统,单元测试,业务,自己,如何
来源： https://www.cnblogs.com/ministep/p/14956149.html