用一个月重构了同事写的烂代码，我总结了8条重写烂代码的经验！

古城微笑少年丶 2023-09-26 23:43 111阅读 0赞

开始想聊这个话题的时候，我是打算放弃的；因为这个话题涉及范围之广，内容之多， 让我犯怵；

近几年，待过两家公司；一家经历过重构，另一家也打算重构......

其实要下定决心，推翻重来，是一个很有勇气的决定；

归根结底，不到万不得已，谁想这么玩，谁愿意花费大精力去做这些脏活、累活；

所以究其原因，也只能说是一种综合因素吧，就像古话说的，天时、地利、人和；

至于为什么这是个很有勇气的决定，因为做重构这事的团队风险极高；上至业务高层，下至底层码农，都有可能一个不小心就被刀；

我曾经待过的一个团队，经历过一次重构，不过那是一次失败的经历；

开发预估了两个多月的时间，业务大佬决定，期间直接对新需求停滞；但是，最终上到生产的系统，老问题还在，然后又多了很多的新问题；

再后来啊，业务大佬和技术主管都被刀了；然后系统回退成老版本，重新承接新需求，并且开发时间被严重压缩，导致技术部门没日没夜的加班；

下面，我大致做了归档和整理，从这八个方面重新聊一聊系统重构；

![58b84635df6fd524874dba7aed44dd15.png][]

## 原因 ##

**【重构原因】** 其实上面也提到过，这是一个综合因素，可能是各种各样的因素叠加，造成一个不得不重构的结果；

下面，聊一聊我所碰到过的因素；要是没聊到的地方，也欢迎大家补充；

**第一个**，可以归结为系统的稳定性或可用性：不管吹得怎么天花乱坠，你的系统总要可用吧，所以说可用和稳定是一个系统的最基本要求。开发一个需求还要全服务停用吗？业务量增长，系统还能抗下所有吗？那么问题来了，怎么保证可用和稳定？

首先，如果你是单服务系统，那么为了保障可用和稳定，需要对服务进行扩展，加入更多的机器来分担系统的性能压力，也就是常说的“服务集群”；

但是，往往我们的系统并不是单服务的，也就是我们常说的分布式微服务；这种情况下，就不得不扯到分布式的三大法宝：限流、熔断、缓存。相信要实现这三个法宝，有很多成熟的框架和工具等，这里就不过多阐述了；

**第二个**，开发规范问题：这也考验了团队leader对底下成员的约束力，以及是否存在代码review的环节；

假设一个团队，leader确实没有对成员强制约束开发规范，更别提代码的review了；最终导致的问题就是，各写各的，每个人都有自己的一套开发习惯和开发规范；最终就是一个大写的“乱”；

这样日积月累，一代目埋坑，一代目撤，二代目上，二代目撤...... 系统不知道经了多少开发人员的手，最终，新入职的冤种某天需要排查一个产线问题，仿佛误入了代码的迷宫，深陷其中，无法自拔；

**第三个**，推翻原先核心业务，重立新规：这个要解释起来比较麻烦，也碰到会比较少，然而，我恰恰就遇到了；

某天，业务大佬宣布，目前做的这套业务规则要被废弃了，他们重新拟定了一套全新的规则，意味着先前不知道几手的代码已经失去意义了，几乎90%都需要重新写；

都到这一步了，那就大刀阔斧的改革吧；出事了，emmm，业务的锅；

## 会议 ##

**【重构会议】** 既然已经确定要进行项目的重构，那么拉成员例会是必不可少的，不然就会一片迷茫，不知道干点啥；

![6f9f2dcd2acbeef485395d2baf8c7650.png][]

第一次会议，由技术老大牵头，叫上业务负责人，技术主管，开发全员，测试，产品，运维；

一般，第一次这种全体会议是没有结果，但是又非常必要的；因为上级领导需要知晓整个重构涉及到的点，影响的方面，开发的时间，以及整体的技术方案，参与的人员，还有需要的资源等等；

第一次会议消化完后，很快就是第二次会议；这个会议也是由技术老大牵头，参会的主要是技术主管和参与开发的人员和运维；主要是对系统重构进行总体的技术选型，讨论用到的框架，组件，实现的方案，部署方案等等；

这个会议持续的时间会比较久，大家搬好小板凳，准备打持久战，可能从上班开始，到下班点了都还不能结束；当然，还是会有中场休息时间的；基本可以各抒己见，提出自己的意见和看法；主要是围绕做什么？怎么做？做多久？这三个疑问点讨论；

接下来，就是由技术主管组织的技术部内部会议了；由于之前已经确定好了统一的技术栈和实现方案，这一次讨论都是在此基础上展开的；

当然这一次会议可能需要更久的时间，因为涉及到是微服务的话，就避免不了一个问题：“服务拆分”；

大家都知道，微服务是需要根据业务去进行拆分的；那么问题来了，业务的划分界限是什么？为什么A业务部分要包含A1，A2，A3；其实这里就需要大家达成一个统一的认知，也是这次会议要达成的最终目的；

这次会议最后，服务已经划分完毕，但是缺少去维护这些服务的人；那就需要对开发人员进行分组，每组有对应的负责人，看人员情况而定（*如果就两三个，甚至更少的开发，那就没必要分组什么的了，就是冤种，活都得你干*），每组对N个服务的开发和维护；

分组过后，组长会进行简短的组内会议，这次其实就是派活会议，认领各自的工作；也会明确一点，大家要干些什么？谁干哪些？每个人干完都需要多久的时间？

最后，会整理一份排期计划，上面每个人的名字赫然在列，当然还有任务列表，工时，等等；

![a2a38c060a212958e294207e6f802c80.png][]

一切准备工作就绪，最后就是开干了，当然后面开发过程中还有一些不明确的点，也会临时组织一些会议，让大家达到统一的认知；

## 需求 ##

**【并行需求】** 在系统重构的开发过程中，因为占用的周期会很长，投入的资源会比较多，所以难免还会遇到这样一个问题；

一天产品经理急冲冲的跑过来说，现在有一些需求很着急，需要将重构停一停，先把这些需求排期上线；至于为什么会这么着急，咱也不知道，咱也不敢问呀；

这时候就会面临一个恶心的局面，这次开发的需求，肯定需要在原先的服务中进行开发，那么重构的服务中，是不是还需要再写一遍？

王德发！说归说，骂归骂，办法总比困难多！这时候有一种方式，那就是派出个谈判专家，以三寸不烂之舌，动之以情，晓之以理；多说说技术难点、痛点，占用的资源，实现的难度等等，去打动他，说服他，让这次需求排在重构后面；

如果你成功了，那么恭喜你，**这次重构任务，大家帮你分担一半**；

什么？产品经理不同意；那就没有办法，只能在改动老服务的基础上，记录调整的点，最终在写新服务业务代码的时候，将改动的点一并加上去；

最后在提测的时候，通知测试同学，这些需求相关的地方，在重构的新服务上线之前都需要重新走一遍流程；

当然，还有一种情况，就是像我之前说的，需求即伴随着重构；这种需求也肯定是大版本，开发周期较长；这种情况是最理想化的，只需要按部就班的进行开发即可；

## 选型 ##

**【技术选型】** 这个话题，在上面的会议模块已经提到过了，这里再来详细的聊一聊；

当然，这次也仅限于比较流行的分布式微服务的技术选型；单服务的话，额，暂且不说吧；

其实也没什么好争议的，对于Java系统而言，无非就是spring全家桶无脑往上堆，服务器资源拉满；就像买汽车一样，越豪华的车，堆的配置越多，价格越贵，但是舒适性和操控性也就越好；

但是还需要考虑一些因素：成本、产品开源与否、技术社区活跃度、产品的成熟度、结合实际情况等等；

**成本**：时间成本、学习成本、金钱成本；

事情是人做的，代码也是人敲的；需要考虑团队成员擅长哪些技术栈，如果一门技术只有少部分人会或者都不会，那就需要结合开发时间，去斟酌需不需要用它，即便是热门的技术；

当然啦，如果老板愿意出钱，直接买各种付费的技术就行，我们只需要搭好基础的框架，然后往里面填充业务代码即可；如果不行，那就老老实实看看免费版，出了啥问题，只能自己排查去解决；

**产品开源与否**：说到这个，开源是关键，最香的词“**开源免费**”；

就像上面说的，一旦遇到了什么问题，其实有必要去看这门技术的源码去解决的；比如典型的SpringBoot自定义starter，需要定义“META-INF/spring.factories”文件，将文件中配置的类型信息加载到 Spring 容器；

一旦你闭源，那怎么玩？我怎么知道你内部怎么去实现的？只能看官方文档，看你自己吹什么什么功能；

**技术社区活跃度**：这个因素其实和产品开源可以归为一类，都讲的是一旦这个框架或产品出了问题，我们就可以去它的官方社区上找类似的解决方案；如果一个产品连社区都没，或者活跃度很低，那也就意味着你只能靠自己去解决了，那花的时间成本可就......

**产品的成熟度**：我们选用一款合适的产品，首先它得符合我们主要的需求，而后它才有其他额外的功能，这当然是最好的；因为一旦咱有一些特殊的业务场景，恰巧这些额外功能正好符合你这个场景，岂不美哉；这样就不必要接入额外的产品或组件了；

比如Redis，大家都不陌生；相信这个工具大家最多的是用它做缓存，它确实也是一款优秀的缓存工具；

但是，我之前在做OA软件时，碰到这么一个需求；用户申请一个会议，并且指定了参会人员，当在会议开始前15分钟，前5分钟，分别对参会人员发送一个提醒；

典型的发布、订阅的模式，然后正好Redis就有现成的功能，当时就是用了Redis的这个功能；

> 但Redis适合小型应用，如果是大型架构，相信还是会使用rabbitMQ或者kafka等更专业的MQ队列软件

**结合实际情况**：说到这个，有句老话说：“只有适合自己的才是最好”；在考虑需要用到哪项技术时，最理想的情况那就是直接付费购买，出啥问题，都是有技术支持滴，我出钱了，你得为我解决，但是，成本有限啊；

当然，有些人会说，技术选型这玩意，那是技术主管或者技术总监他们决定的，我们小码农只管拧好螺丝就行；是的，往往很多时候就是这样；但是，你不去大胆说出你的想法和意见，你怎么知道他们不会听取呢？格局打开，往上一层考虑就对了；

## 划分 ##

**【服务划分】** 这块内容其实可聊的没多少，但是，也是最难的一块；

首先，划分；怎么分？按什么标准去分？分多少服务合适？分好之后怎么去管理？安排那些人去管理？等等一堆问题；

我也只能浅谈下我之前做过的一次划分经历，因为每个公司遇到业务和场景是不同的，最终得到的结果也是不同的；而且，服务并不是一次划分就能结束，它是一个持续不断的过程；

当时我们是全部参与这次重构的开发一起拉会议的，在此之前，已经确定好了技术栈，就是热门的springcloud全家桶；技术主管先是浅谈一波他自己的想法，然后让大家在他划分服务的基础上，提出自己的看法，并且每个人都要说，因为不可能想法都是一致的；

我记得比较清楚的是，他划分中，有个序列号的服务，就是这个服务专门去生成序列号；后面几个人都点名这个服务也包括我；其实当时想的是，我们的系统业务里没那么大，能省一个服务，也是省一点资源；最终大家统一共识，将这种场景写一个工具类去处理；

最终讨论后，达到的共识，也只是一个初步的共识；随着业务需求的增长，一部分业务服务必将变得臃肿，那时候第二波拆分也就随之到来了；

## 规范 ##

**【开发规范】** 上面提到，造成系统重构的因素有很多，其中一个因素就是代码混乱，大家各有各的习惯和规范；

其实不难发现问题了，并不是每个人不知道开发规范，而是大家没有统一的一套规范，大家只是没有达成共识；

那就来解决这个问题，制定一套统一的标准，让大家都没有异议的一套规范；

这时候就不得不提到阿里的规范，现在广为流传的《阿里巴巴Java开发手册》，甚至基于这套规范，在IDEA上还有专门的检查插件可以安装；

当然，这样做确实省事，省去了leader对代码的review时间，包括我之前待过的一家公司，也确实就是这么做的；

其实仔细用过几次这款插件就会发现，有些检测其实大可不必，但是你又不得不去遵守它的规则，这时候反而徒增工作量；

遇到这种情况就需要看上级了，可以把这个疑问点反馈给他，或者反馈给身边其他的小伙伴，起码让他们GET到你要表达的点，引起大家的共鸣；相信越来越多的人反馈这些问题，上级不会坐视不管的；那么恭喜你，又去掉一块大家都认为不合适的规范，让你开发不绕弯路；

总之，总结起来就是一句话：没有标准，大家统一认可的就是标准犯规；

## 迁移 ##

**【数据、接口迁移】** 谈到这个，除非开发的是0-1的项目，否则在平时开发中，或多或少都是会遇到的，而非重构会单独遇到的问题；

而我们在入职一家新公司，或者长期在一家公司干活，遇到0-1的项目几乎没有；如果有，那么你的运气很好；

就拿我上面的经历来说，业务推翻了之前的规则，重新制定了新的业务规则，那就不得不引出一个问题，之前的老数据怎么办？

这个时候就需要跟业务确认，这批老数据是否可以按照某种默认的规则，做统一的处理；或者说，直接废弃不管；一般来说，按前者处理的方案居多；

考虑到重构，往往你的表也是重新设计过的，也有可能是老表和新表公用，一般来说后者的情况居多；

其实，说白了就是在老表里面去修改数据，在新表里面去新增数据，而我们要考虑的是这批数据怎么去调整比较合适；

按我们之前的处理方式，如果涉及到的表，字段等较少，存储结构也颇为简单，是可以直接用SQL脚本去解决的；另外，还需要考虑如果表数据较多，SQL执行快慢的问题；

还有一种情况，要是涉及到的场景很多，处理的表也居多，可以考虑写程序去解决；比如，写个任务，去手动执行这个任务，处理掉这批数据；当然，也得考虑数据量的问题，如果数据量大，用多线程跑批，或者多服务跑批等方式；

下面，来谈谈重构中的接口迁移；

要保证一个原则，就是对接口的出入参保持不动；不然，前端直接飞过来跟你聊人生；

但是，老服务的接口很多怎么办？还能怎么办，分工处理；

上面提到过，我们是分组的方式，每个组负责一部分服务，分工比较明确，所以相对来说，也比较快；

大家整理文档，老接口的URL是什么，新接口的URL是什么，出参，入参能不变就不变；如果真的需要调整的，需要给出合理的解释，大家一致通过后，然后自行跟前端去battle；

有些老服务还会运行一段时间，所以并不是所有接口都会涉及到迁移，这种接口，那就相安无事；

在迁移的过程中，肯定也会遇到各种问题；比如举个简单的例子，之前老服务的分页插件使用的是`PageHelper`；而在新服务中，由于用上了`Mybatis Plus`框架，那自然也就用它框架自带的分页插件了；这个时候就涉及到修改，你只能自己内部消化了；

最后，当你觉得一切接口都迁移完毕的时候，别忘记对自己迁移的接口，进行一次自测；不要怕麻烦，这个自测对于后面的联调和提测流程，都可以免去很多不必要的问题，也可以大大提高团队的效率；

## 方案 ##

**【实现方案】** 最后还有一点，业务场景的实现方案；这个听着有点抽象，其实在上面说的会议中，也会涉及；

不要以为这只是技术的决定，其实产品的参与也是很有必要的；你品，你细品；

我拿一个经典场景举例，A账户往B账户打钱，然后系统是微服务，很熟悉吧；

没错，就是分布式事务的一个经典场景，要保证数据的一致性，A被扣钱的同时，B要加上相应的钱；

分布式事务我不多说，相信很多同学随便一查，各种五花八门的方案；

但是这里我只讲一点，达到数据一致的时间节点；你是要什么时候保证这个数据达到一致，也就是说，强一致性还是最终一致性；

要求强一致必然是牺牲掉一部分性能的，要求最终一致性就有可能在一段时间内产生数据不一致的问题；

这个时候，就需要拉上产品经理，跟他阐述其中的缘由，说明技术方案上无法规避的点，让他做取舍；

有的时候，好的设计往往能规避技术上的难点，也可以节省开发的成本和时间；

所以，在讨论这块内容的时候，必须要有产品经理在场，提出设计上不合理之处；我们不能只局限于研究技术问题，其实换个角度，或者你质疑的点，就不存在了；

记得实习的时候，公司的老板讲过一句话“人人都是产品经理”，现在回过头一想，还真是那么回事；

大胆的提出自己的意见，做一个有自己主见的小码农；

## 总结 ##

对于系统重构，我就以一句话结尾吧，这也是引用了一位大佬的话，“对公司现有的资源和战略妥协，在技术栈和方案之间取舍”。

[58b84635df6fd524874dba7aed44dd15.png]: https://img-blog.csdnimg.cn/img_convert/58b84635df6fd524874dba7aed44dd15.png
[6f9f2dcd2acbeef485395d2baf8c7650.png]: https://img-blog.csdnimg.cn/img_convert/6f9f2dcd2acbeef485395d2baf8c7650.png
[a2a38c060a212958e294207e6f802c80.png]: https://img-blog.csdnimg.cn/img_convert/a2a38c060a212958e294207e6f802c80.png