经过与小伙伴们的讨论，以及对未来业务发展的考虑，我们发现后续应该会有越来越多的系统需要用到这个功能，于是我们决定将原本在营销发送平台的功能抽离出来，放入消息管理平台。而消息管理平台则作为消息中台，掌管所有与用户通信的渠道，包括：邮件、短信、Push 等等。
虽然做架构决策很快，但是怎么去做调整，项目之间的众多细节如何处理，却是一个非常苦恼的问题。对于我来说，我擅长与抽象总结归纳，因此对于整体架构上游刃有余。但重构的具体实现，如何设计得更有扩展性，则更考验程序员的代码实现基本功。
目前这块内容的重构还在进行，等到做得差不多之时，我再分享关于这块内容的重构经验。
总结这篇文章分享了我工作七年来的三次重大重构经验，也算是对我职业生涯里有关重构的一个总结。每一次重大的重构经验，都让我从中汲取养分，在下次重构时做得更好，让我更加游刃有余。经历过这么几次重大的重构，我也发现了不少重构的经验，这里简单总结下。
第一，先了解业务再重构。 先把业务了解清楚，再去重构，不然这次重构很大可能是失败的，并且会导致你提桶跑路。
第二，小步快跑。 无论如何，还是要保持小步快跑的方式，每次改动较少的地方，然后完成上线。而不要一次性改动太多的地方。
第三，注重沟通。 积极与领导沟通，让他明白你当前的进度，必要时咨询他的意见。切忌自己闷头搞开发，最后别人都不知道你在做什么。
第四，给出自己的方案。 要有自己的思考，能给出自己的方案。对于领导不切实际的方案，要懂得提出自己的意见，引导领导按照自己的思路去做，从而按自己的节奏走。
第五，做好充分的测试。 单元测试是最基本的内容，一定要做好单元测试。对于无法做单元测试的，一定要让测试同学做充分的功能测试。
好了，关于重构的分享，今天就聊到这儿。
谢谢大家的阅读。如果文章对你有帮助，点个 「在看」 ，或者 分享到朋友圈 吧。
文章首发于公众号「陈树义」及个人博客 shuyi.tech，欢迎关注访问。