关于重构工作的一点思考

Posted 2020-09-27

　　最近两周一直忙着和重构相关的事情，本文将简要概述从开始制定重构方案，到具体执行的过程中遇到的问题，以及对重构的一点理性思考。

起因：

　　本系统是2015年11月开始建设，当时为了快速投入使用，大量的烂代码，后期一直保持快速前进，没有进行过实质性的重构。

具体表现：

● 分层不清，sql哪都有，dao有、service也有，就差controller没写了。同样dao也包含业务逻辑。
● sql用的是spring jdbc，并没有使用mybatis，导致sql写起来有些复杂，封装不够基本都是原始sql。
● 习惯于用sql来解决业务问题，导致sql异常复杂，难于调试，拿着打印出来的sql也不容易找到哪出现的问题。基本上是一个业务一条sql，sql难于复用。
● 职责不清，没有边界可言，每个类想写什么就写什么，域模型完全没起到应有的作用。
● 代码逻辑复杂，坏味道的代码到处都是。如箭头型的代码逻辑复杂，层次特别深，最多的达到10层。

解决方案：

　　本次重构作为第一期重构，主要解决域模型模糊，对部分类进行拆分合并，按照域模型进行模块划分。另外对于bad smell代码的提出一些常规的改进措施，可以参照《重构》一书这里不细说了。针对箭头型的代码主要采取卫语句模式进行重构。

遇到的问题：

　　本次重构涉及面广，因此向领导申请到了三个人一周多的工作时间，产品人员答应给我们一周时间，不提新需求。可是刚工作一天，就来一个紧急需求，涉及到战略问题，重构自然就要让路了，搁置一周后重新打开。重新工作后又陆续插进来一些小需求，最终导致三周才完成重构工作。这还没完，重构改动面大，测试也要了很长的时间。测试期间必然要开发新的功能，这就导致新改的需求，与重构的代码有交集，要不断的将新需求代码合并到重构分支上去，这就不得不面对代码冲突问题，对测试工作也带来的困扰。

积极的一面：

　　本人是新来到此项目组，通过本次重构，让我更加了解系统的来龙去脉，也看到系统一些深层次的问题，如原有的业务逻辑设计本身存在的问题，为后续工作的开展奠定基础。

总结：

　　本次的重构跨度将近一个月，将重构带来的收益都稀释掉了。我个人给本次重构定性为一次不成功的重构，但也谈不上失败，毕竟解决了实际问题，为后续开发提供了一规范性的指导。这阶段我在思考这背后的原因。大概包括：
● 重构涉及到的范围比较大，导致工时有些长
● 将一个小组全投入到重构中，抽不出人来解决其它需求了
● 没有能拦住业务部门的紧急需求，say no挺难的
　　重构至关重要，今后还会继续，当然策略也要修改，主要是小步快跑，如每次只修改一个模块，两三天就可以搞定上线。另外对于重构来说最重要的还是在平时，如果发现某模块要重构，在工作的时候就要无情的进行重构，可以适当的多争取一些时间。抽取出大量的时间进行重构真的是下策了。