业务重构

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了业务重构相关的知识,希望对你有一定的参考价值。

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


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


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


技术分享


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


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


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


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

技术分享

本文出自 “一只博客” 博客,请务必保留此出处http://cnn237111.blog.51cto.com/2359144/1968159

以上是关于业务重构的主要内容,如果未能解决你的问题,请参考以下文章

用领域驱动设计实现订单业务的重构

Golang 重构 Python,知乎社区核心业务实践

利用模板模式重构JDBC操作业务场景

利用模板模式重构JDBC操作业务场景

重构_使用模板模式替代重复业务操作

业务代码重构