打破常规，重立新规；
01
开始想聊这个话题的时候，我是打算放弃的；因为这个话题涉及范围之广，内容之多，让我犯怵；
近几年，待过两家公司；一家经历过重构，另一家也打算重构......
其实要下定决心，推翻重来，是一个很有勇气的决定；
归根结底，不到万不得已，谁想这么玩，谁愿意花费大精力去做这些脏活、累活；
所以究其原因，也只能说是一种综合因素吧，就像古话说的，天时、地利、人和；
至于为什么这是个很有勇气的决定，因为做重构这事的团队风险极高；上至业务高层，下至底层码农，都有可能一个不小心就被刀；
我曾经待过的一个团队，经历过一次重构，不过那是一次失败的经历；
开发预估了两个多月的时间，业务大佬决定，期间直接对新需求停滞；但是，最终上到生产的系统，老问题还在，然后又多了很多的新问题；
再后来啊，业务大佬和技术主管都被刀了；然后系统回退成老版本，重新承接新需求，并且开发时间被严重压缩，导致技术部门没日没夜的加班；
下面，我大致做了归档和整理，从这八个方面重新聊一聊系统重构；
02
【重构原因】
其实上面也提到过，这是一个综合因素，可能是各种各样的因素叠加，造成一个不得不重构的结果；
下面，聊一聊我所碰到过的因素；要是没聊到的地方，也欢迎大家补充；
第一个，可以归结为系统的稳定性或可用性：不管吹得怎么天花乱坠，你的系统总要可用吧，所以说可用和稳定是一个系统的最基本要求。开发一个需求还要全服务停用吗？业务量增长，系统还能抗下所有吗？那么问题来了，怎么保证可用和稳定？
首先，如果你是单服务系统，那么为了保障可用和稳定，需要对服务进行扩展，加入更多的机器来分担系统的性能压力，也就是常说的“服务集群”；
但是，往往我们的系统并不是单服务的，也就是我们常说的分布式微服务；这种情况下，就不得不扯到分布式的三大法宝：限流、熔断、缓存。相信要实现这三个法宝，有很多成熟的框架和工具等，这里就不过多阐述了；
第二个，开发规范问题：这也考验了团队leader对底下成员的约束力，以及是否存在代码review的环节；
假设一个团队，leader确实没有对成员强制约束开发规范，更别提代码的review了；最终导致的问题就是，各写各的，每个人都有自己的一套开发习惯和开发规范；最终就是一个大写的“乱”；
这样日积月累，一代目埋坑，一代目撤，二代目上，二代目撤...... 系统不知道经了多少开发人员的手，最终，新入职的冤种某天需要排查一个产线问题，仿佛误入了代码的迷宫，深陷其中，无法自拔；
第三个，推翻原先核心业务，重立新规：这个要解释起来比较麻烦，也碰到会比较少，然而，我恰恰就遇到了；
某天，业务大佬宣布，目前做的这套业务规则要被废弃了，他们重新拟定了一套全新的规则，意味着先前不知道几手的代码已经失去意义了，几乎90%都需要重新写；
都到这一步了，那就大刀阔斧的改革吧；出事了，emmm，业务的锅；
03
【重构会议】
既然已经确定要进行项目的重构，那么拉成员例会是必不可少的，不然就会一片迷茫，不知道干点啥；
第一次会议，由技术老大牵头，叫上业务负责人，技术主管，开发全员，测试，产品，运维；
一般，第一次这种全体会议是没有结果，但是又非常必要的；因为上级领导需要知晓整个重构涉及到的点，影响的方面，开发的时间，以及整体的技术方案，参与的人员，还有需要的资源等等；
第一次会议消化完后，很快就是第二次会议；这个会议也是由技术老大牵头，参会的主要是技术主管和参与开发的人员和运维；主要是对系统重构进行总体的技术选型，讨论用到的框架，组件，实现的方案，部署方案等等；
这个会议持续的时间会比较久，大家搬好小板凳，准备打持久战，可能从上班