【代码优化与重构技巧】学会合并和持续更新代码_代码工程一边升级但是又在一边添加新需求,如何合并代码工程追加

前言

上一篇写的是【学会拆解】，这篇就写【学会合并和持续更新代码】。

问题点

同事离职前交接的代码，除了前面提到的代码除类太大、业务大块逻辑写到一个方法中之外。还有几个问题：

• 重复性的冗余代码太多，很多复制粘贴的内容，复用性非常低；
• 很多没用到的代码和配置，还有很多新老兼容留下的开关。已经不清楚哪个开关开着，要调用哪个系统；
• 一个大的工程项目拆分太细，调用链太长。在排查问题时牵扯的项目太多，需要排查多个项目甚至涉及多人，排查和沟通成本太高；

学会合并

关键在于梳理清楚上下游调用关系，提取出关键内容。

如何解决

• 在主业务逻辑方法应只写主流程，含有相同的业务处理逻辑应合并到一个方法中：比如主业务逻辑含有ABC三个业务处理逻辑，那ABC就可以拆出相对独立的三个方法。在主业务方法中，只需要调用ABC三个业务方法即可；

• 抽取出相同内容的函数：相同的内容就提取出成模板方法，相同的字段就抽取出来共用的实体类，常用的就抽取出一个共用的依赖包；

• 多个项目要调用同一个接口，抽取一个项目来供依赖使用。不应每个项目都写同一份相同的调用方法，否则在后续接口做调整时，每个涉及到的项目都要做调整；

• 接口和返回值抽象化。比如策略+工厂模式就是因为方法是抽象化的，所以可以路由到具体的实现。还有比如获取缓存值，可以直接用泛型表示，而不该拆分为多个不同的调用方法。

• 减少调用链。不必拆分的太细，能直接调用就直接，不要经过几次转化；

• 涉及到核心的更新，单独提供一个接口提供更新。比如保存和更新核心的基础信息，应合并到一处进行更新。不应分散到各个项目组更新，否则出问题时难以排查到底是哪里更新错了数据；

• 多项目更新同一个sql时，应集中到一起更新。在并发量比较大时可能会出现死锁和顺序性的问题（生产的确遇到）；

• 处理同模块核心业务模块收敛到一个项目中。举例，有发送微信、短信、语音和对应渠道的回执项目。原本拆分为各个项目中，代码过于分散。在具体的业务处理应收敛到一个项目中，具体的调用入口只是个壳，只提供入参校验，具体的实现可通过mq或者调用实现；

• 有公用jar包提供的方法，就不要重复造轮子。比如日期类，判空、加密等等；

• 方法参数过多时，合并为一个实体类或者Map，这样使方法更通用，后续即使增删字段，也无需修改方法；

• 相同功能的类和方法就抽取到一个方法中，而不是各写一个类。比如加密，检验，日期、http等等；

• 校验性的内容，自定义抛错，在try/catch处理。在入参需要大量校验时，一个个写相同校验部分显然不合适。应考虑使用自定义抛错类型，代码中传入抛错信息。

• 去掉不必要的临时变量；

最终达成的目的：

• 高内聚低耦合。提高代码的阅读性、复用性和降低维护成本；
• 减少不必要的代码逻辑。降低代码的耦合性，使代码更清晰；

持续更新

仅仅合并了代码还不够，因为在开发过程中总会遇到配置调整和新老版本兼容的问题。那么可能就会有很多不用的代码。如果放任不管，可能后面就看不懂以前写的内容了。比如

关键在于持续的去除掉不必要的代码内容。

• 去除掉不用的配置。说不定哪天老的配置下线时，重启就会生产报错；
• 用不到的代码就该删除。
• 试点运行的代码，不需要时应及时删除；
• 去除掉开关。当初上线为了试运行兼容而增加了很多的新老代码切换，等系统稳定一段后就删除掉；

最终达到的目的

• 做好断舍离。不用的就删除掉。
• 持续更新。自己的项目要维护好。

不论是拆解，还是合并和持续更新，最终的目的都是为了使得代码能够清晰明了的梳理清楚，提供代码的复用性和健壮性，便于未来拓展和排查问题。写代码就犹如一门艺术，需要不断修炼内功，才能写出优雅的代码来。