2021年3月21日

码海奇旅–一套汽车租赁管理系统的重构历程

作者 C哥

现代的软件及互联网行业里,软件项目的重构已经是非常普及的概念了,但目前大量中小厂的从业人员所接受过的技能培训来看,真正经历过项目重构的人应该少之又少,大部分情况还是处在不停地修修补补,实在不行重写一边的状况之中。

近几年我经历的几家公司基本也都是这个状态,原因很简单,业务收入并不稳定,不能长期稳定的执行一套系统。新的业务需求不断的添加到现有的项目里来,期间甚至还会经历技术人员完全断层的可能性。

在这样的行业现状下,具备重构能力的技术人员真是少之又少。

另一方面,我正在经历的这个软件项目刚好走完了他的第一个生命阶段,已经具备了一个相对完整的系统功能,但基于行业客户的需求,后面还有大量的变化需求会在可预见的未来里,会不断地被叠加到现有的项目上来。如果不能及时对项目进行梳理建模,重新规范软件的代码结构,那开发者的噩梦就会迅速到来。

其实,噩梦会来得更快些。上周一位技术人员离职,然后会有新的技术人员补充进来,技术债如果不能迅速进行阶段性结算,那项目代码变坏的速度一定会加速。

解决问题大思路早就有了,但一直没有合适的执行方法。考虑了一周之后,我决定马上执行这个项目的重构计划。

先介绍一下项目,这是一套汽车租赁公司的业务管理系统,前后端分离,服务器端项目分为3端进行开发,共计661个API入口,支持API的有801个模型方法,一百张数据库表,5万多行的纯手工php代码。项目规模并不大,因为纯手工代码,没有引入太多的外来复杂因素。再从业务角度介绍一下,汽车租赁行业的业务相对来说非常复杂,但并发量并不大。假设某企业有10000台车,每天的出租率在50%,租期都在1-2天,那这个企业每天的业务请求量也才10000单,包括5000单取,5000单还,这个业务并发压力对于互联网企业来说太小意思了。可是从部门职能来看,微型企业可能1、2个人就能撑起一个门店,一个管理规范的企业则需要十来个部门,从系统的业务模块来说,就有30个左右的业务模块。这些还只都是简单的数字堆砌。从业务执行的细节上再看,每个企业又都有自己相对独特的业务点,也就是说这30个业务模块,放到100个企业里,可能会有300个甚至3000个实现方法。

介绍完项目,再记录一下这次计划的目的和实施思路。

目前的项目是基于简单的MVC结构框架进行开发的,V层简化为API接口的输出,主要逻辑在Controller层和Model层。C层主要责任为完成业务逻辑的堆砌,M层则实现对数据库表的操作。基于对项目业务逻辑更进一步的理解,这次调整主要应该增加一个抽象模型层,所有的业务逻辑应该基于抽象的业务逻辑层进行实现,抽象逻辑层再调用不同版本、复杂度或性能的实现,以体现对不同业务细节关注深度的支持。完成这个阶段的系统调整之后,应该达到的效果为在保持API不变的前提下,所有的业务实现逻辑可以支持多个版本,从而实现对不同客户对不同业务细节关注的逻辑变化。

好,就到这里,开工。

-EOF-