重构

       重构的目的是为了解决问题，或是为了解决目前的问题，或是为了解决未来可能出现的问题。

       重构可以分为业务重构和技术重构，而大部分技术重构都是以更好的支撑业务为目的的，这里把这一部分也归到业务重构的范畴。

       重构的好坏在于有没有解决问题，解决问题的同时有没有产生新的问题。

然后以经历过的两个典型重构案例做以分析

1.苏宁易购话费重构

背景：原有系统将话费充值，生活缴费，保险等几大类业务一起打包为一个前台应用和一个后台应用，随着各业务线新的功能的不断加入和新增产品的加入，系统逐渐变的庞大，随之而来的是系统占用内存增大，启动时间变长，本地调试变得非常困难，下载代码就需要十几分钟，一切都准备好了后启动程序还经常遇到OOM的问题。

目的：为了解决单体架构带来的一系列问题

方案：做系统拆分，采用SOA架构

是否产生新的问题：是，主要是分布式事务和rpc调用的问题，不过都有成熟的解决方案

2.乐刻中台重构

背景：乐刻在上一次重构中已经做好了系统拆分，并抽象出多个业务中台和核心系统，但由于语言本身的特性，简单的系统拆分并不能解决某些特定场景产生的问题。

目的：解决PHP自身对高并发及一些常用web中间件（MQ，dubbo，数据库连接池等）不支持或不友好的问题

方案：用java重写业务中台

是否产生新的问题：否

我把上面两个重构都归结为业务重构，是因为两个重构都包含厚重的业务逻辑，而重构的前提是对业务有深入的了解，在这个前提下做技术选型，这样的原因是技术往往具有普适性，而业务不同，也就是说同一个功能可能会有A、B、C三种解决方案，脱离了业务则三种方案都可以，但如果深入理解业务，则可以选择最适合的一种方案。