业务重构

在重构一个结构繁杂，代码逻辑千丝万缕的业务系统时，除了对代码层面的重构以外，不少人会忽视对于业务结构的重构和简化。

目前正在遭遇着这个事情，一个异常复杂的系统，不断的在上面添加需求，代码量增大，函数的体积也在增加，Web服务也愈来愈臃肿。关于代码层面的解耦，方法论不少，但本质上就是“提取公因式”，即相同的代码不要写两遍。一般，良好模块的模块设计，很容易达成这种只写一次的目标。

还有的复杂度就是模块之间的依赖和调用，不少人就会想到，用消息队列去解耦。其实消息队列解耦只是在技术层面，把两个东西物理上分开了，逻辑上仍是要靠消息去驱动，复杂点就变成了什么时候发消息，发怎么样的消息。过于复杂的依赖和调用，在修改的时候，容易出现纰漏，好比漏发了某个消息。

其实我想说的不是技术层面的简化，而是业务层面的简化。业务人员首先要扪心自问一下，业务真的有必要设计的那么复杂吗？真的须要吗？若是你以为须要的话，那你再想一遍，真的须要吗？

有一些业务人员过分设计，复杂设计，盲目设计，原本简单的一个业务规则，硬是要设计成很复杂的规则，设计出很复杂的一个功能，可是该功能的使用率很低，可是对于这个功能的维护成本又很大，一不当心出的bug就是由它产生。

理论上，业务设计和程序设计并无区别，无非一个是用天然语言描述，一个用代码表述。业务设计也是能够画出流程图，状态图的。可是，若是一个业务设计天生就复杂，那么期望代码层面上很简洁，很清晰，无异于痴人说梦。

某种程度上说，业务的重构解耦，比代码层面的重构解耦更有意义。好的业务设计人员，应梳理出各个业务需求，尽可能设计出相互独立的业务，封装不变的业务模块，把恶心的，易变的业务需求单独切割，尽可能不要影响成熟业务模块的功能。