文章首发于公众号「陈树义」及个人博客 shuyi.tech，欢迎关注访问。
博主个人独立站点开通啦！欢迎点击访问：https://shuyi.tech
蓦然回首，我已经工作七年了。在这七年的时间里，做过了无数个项目，但要说大的重构，只有三个。第一个是在我工作三年时，重构公司的聊天 IM 系统。第二个是我在现在的这个公司，重构了整个业务线的业务架构。第三个是现在我正在做的，重构消息中台的技术架构。
IM 系统重构2017 年的我，毕业三年了，但是从来没有重构过一个系统，就连一个模块也没有。而刚好就在这个时候，公司考虑到原有聊天功能不太友好，决定对原有聊天功能进行重构。于是组件了一个项目组，有两个架构师再加上我去做这个事情。
由于当时的我并不清楚如何设计一个 IM 系统，所以我分配到的是业务逻辑代码梳理，而其他两位同学则是进行架构设计，以及 IM 通信层面的代码编写。正是由于这样的分工，让我后面越做越难受。
这是一个积累了十年的功能系统，沉积了无数的业务逻辑，而且很多业务逻辑很多人也不清楚。当然了，单元测试肯定也是没有的，测试用例肯定也是没有的。在这样的情况下，我只能自己厚着脸皮一点点地去撸代码弄清楚业务逻辑。
后面回头来看，这种方式真的是最低效率的方法。如果不到万不得已，千万别这么做。最好的方法是找一个人捋清整体思路，之后再一点点弄清细节。另外，最好的重构方式不是一开始就重写，而是一个功能一个能地重写，这样才更加稳妥。
另外一个重要的点是向上沟通。很多时候我们都是按照上级的指令行事，但是却不提出自己的想法和方案。但对于重构这件事情来讲，如果不做好沟通，很可能会出大事。像这种大系统，功能众多、细节复杂，一开始就应该和领导打上预防针，并且争取分阶段、分模块开发，降低自己的风险。一般情况下，领导考虑到开发的风险，都会同意按照你的方案去做。如果领导执意要一次性做完，那你也尽到了自己的责任，后续出问题做不完，也不全是你一个人的问题了。
这个项目最终做一个多月才做完上线，主要的时间是在梳理业务逻辑上。在这过程中自己也一度快做不下去了，甚至做到后期有点抑郁了。现在回想来看，就是自己重构经验不足，心态又不好导致的。
文章首发于公众号「陈树义」及个人博客 shuyi.tech，欢迎关注访问。 业务线重构熟悉的朋友都知道，我从唯品会出来后，就去了现在的公司。当时这块业务是从别的部门交接过来的，我们算是从零开始去熟悉这块业务。对比起上次的系统重构，这次的规模更大，直接是整个 CRM 业务线的重构。我作为技术 leader 则是参与组建了整个技术团队，并主导设计、推动落地了整个 CRM 的系统架构。
CRM 系统看起来就是一个 B 端系统，一个管理后台有什么好做的嘛。一开始我也这么觉得，但慢慢深入了解之后发现：这个东西还是不简单。经过一段时间的了解，我发现原有系统存在一些问题，例如：系统功能混在在一起，功能模块之间没有清晰的的划分；后台模块耦合在一个项目中，没有做合理的模块拆分；等等。
经过一段时间对业务的深入了解，结合对业界公司解决方案的对比，我设计出了全新的业务架构图。整个业务架构图将系统功能分为了三大系统：消息管理平台（MMP）、营销发送平台（MSP）、营销分析平台（MAP)。
经过与技术总监、产品总监沟通，他们对这个方案感到很满意，决定后续按照这个方案去推动。在整体产品、开发、测试团队的一起努力下，我们经过了半年的时间，将原有的 PHP 与 Java 系统共存的业务项目，成功改造完成了上面所说的三大系统。
对比起两年前在珍爱网的那次重构，这次重构是更大意义上的、业务架构层面的架构。 也是这次成功的系统重构经验，让我学会了如何从零开始去做一个业务，如何从零开始去重构一整个业务系统。后面有机会，我再写一写这块的文章。
文章首发于公众号「陈树义」及个人博客 shuyi.tech，欢迎关注访问。 消息中台重构还记得前面说到的消息管理平台吗？其实这个就是消息中台的前身。在这之前，消息管理平台只是负责发送小批量的消息（100条以下）。但随着业务的发展，我们发现有很多系统也需要发送几十万、甚至几百万的数据。而在这之前，这个需求只有我们这块业务有。而这块业务实现则是我们单独放在营销发送平台实现，并没有抽离出来作为中台服务。