【代码优化与重构技巧】学会拆解

前言

上个月一同事离职交接给我一个项目。那个项目因为涉及到不同操作码要做不同的业务处理，就把代码所有的操作码业务大块逻辑写到一个方法中，中间不同的就用if/else做判断。

当我看到代码的时候，梳理业务逻辑梳理不清楚。因为判断太多，还要认真的区分哪个操作码进入哪个判断里面。这种代码看完以后会一头雾水。

学会拆解

问题

看完整个项目后总结了几个典型的问题：

• 这个主模块逻辑的代码将近2000行，妥妥的一个大类。另一个方法可能超过200行。
• 拼凑功能，将所有业务逻辑写到一块。代码太长且难以理解，并在后续排查问题难以排查。
• 代码的耦合性太强，可复用性很差。

解决办法

如何避免上面所说的问题呢？

不要企图让一个类或者方法涵盖许多的内容，而应该是要把将大类拆解为一个个小功能模块。

其实就是拆解，确保各功能模块清晰、独立。

• 将大类拆解到各功能模块之中：缓存、调用各外部接口、mq操作等相关的方法就单独拆为一个单独的类和方法，保证各个模块功能单一。
• 不同的业务操作码拆解为单独的方法/类：每个操作码有不同的操作，那就拆分一个单独的模块出来给它。
• 相同部分的代码就把它单独拆解出来，成为公共模板方法：拆解各操作码方法后会有相同部分，相同部分就抽取为模板方法。
• 与数据库打交道的dao层以表为维度拆分类：每个类相关的操作就是一个类。
• 引入设计模式：不同的操作码有不同的操作，可以引入策略模式+工厂模式来处理。
• 拆解的每个方法的命名要见名知意：看到方法名称就明白方法的作用是什么。

达到的目的

最终达到的目的：

• 每个模块都是一个独立的作战单元，对外是稳定的。也就是说：不稳定的方法要依赖于稳定的，它并不随着外部不同的调用变化而变化。
• 业务逻辑职能清晰明了，后续即使删减操作码的操作，也只会影响到某个方法/类，而不对整体产生影响，也无需回归测试。

经过拆解，从原本的30个类，拆解为现在的60个类。虽然类变多了，但是功能模块变得更清晰，代码的耦合性很低，即使后续增删功能，对整个业务逻辑产生非常小的影响。