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


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


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


业务重构_业务


其实我想说的不是技术层面的简化,而是业务层面的简化。业务人员首先要扪心自问一下,业务真的有必要设计的那么复杂吗?真的需要吗?如果你觉得需要的话,那你再想一遍,真的需要吗?


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


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


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

业务重构_业务_02