关于重构工作的一点思考
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于重构工作的一点思考相关的知识,希望对你有一定的参考价值。
最近两周一直忙着和重构相关的事情,本文将简要概述从开始制定重构方案,到具体执行的过程中遇到的问题,以及对重构的一点理性思考。
起因:
本系统是2015年11月开始建设,当时为了快速投入使用,大量的烂代码,后期一直保持快速前进,没有进行过实质性的重构。
具体表现:
● 分层不清,sql哪都有,dao有、service也有,就差controller没写了。同样dao也包含业务逻辑。
● sql用的是spring jdbc,并没有使用mybatis,导致sql写起来有些复杂,封装不够基本都是原始sql。
● 习惯于用sql来解决业务问题,导致sql异常复杂,难于调试,拿着打印出来的sql也不容易找到哪出现的问题。基本上是一个业务一条sql,sql难于复用。
● 职责不清,没有边界可言,每个类想写什么就写什么,域模型完全没起到应有的作用。
● 代码逻辑复杂,坏味道的代码到处都是。如箭头型的代码逻辑复杂,层次特别深,最多的达到10层。
解决方案:
本次重构作为第一期重构,主要解决域模型模糊,对部分类进行拆分合并,按照域模型进行模块划分。另外对于bad smell代码的提出一些常规的改进措施,可以参照《重构》一书这里不细说了。针对箭头型的代码主要采取卫语句模式进行重构。
遇到的问题:
本次重构涉及面广,因此向领导申请到了三个人一周多的工作时间,产品人员答应给我们一周时间,不提新需求。可是刚工作一天,就来一个紧急需求,涉及到战略问题,重构自然就要让路了,搁置一周后重新打开。重新工作后又陆续插进来一些小需求,最终导致三周才完成重构工作。这还没完,重构改动面大,测试也要了很长的时间。测试期间必然要开发新的功能,这就导致新改的需求,与重构的代码有交集,要不断的将新需求代码合并到重构分支上去,这就不得不面对代码冲突问题,对测试工作也带来的困扰。
积极的一面:
本人是新来到此项目组,通过本次重构,让我更加了解系统的来龙去脉,也看到系统一些深层次的问题,如原有的业务逻辑设计本身存在的问题,为后续工作的开展奠定基础。
总结:
本次的重构跨度将近一个月,将重构带来的收益都稀释掉了。我个人给本次重构定性为一次不成功的重构,但也谈不上失败,毕竟解决了实际问题,为后续开发提供了一规范性的指导。这阶段我在思考这背后的原因。大概包括:
● 重构涉及到的范围比较大,导致工时有些长
● 将一个小组全投入到重构中,抽不出人来解决其它需求了
● 没有能拦住业务部门的紧急需求,say no挺难的
重构至关重要,今后还会继续,当然策略也要修改,主要是小步快跑,如每次只修改一个模块,两三天就可以搞定上线。另外对于重构来说最重要的还是在平时,如果发现某模块要重构,在工作的时候就要无情的进行重构,可以适当的多争取一些时间。抽取出大量的时间进行重构真的是下策了。
以上是关于关于重构工作的一点思考的主要内容,如果未能解决你的问题,请参考以下文章