新公司的第一个任务-重构系统(一) - 好文

辞职后想了一段时间，最终还是换了个城市工作，最近刚上班，陌生的城市还是有一股孤独感，麻将一缺三。

上班后的第一个任务领导就让我重构一下系统，我下意识就回答重构坑很深，想建议小步定期重构追求慢而稳，后面了解了下原因后也只能上手开始搞了。这套系统代码量只有不到3W行代码，不过这套系统的代码是我见过最糟糕的代码，十分脆弱，一个UI的类把所有的组件都耦合在一起了，业务逻辑的许多行为都在UI类中，存在几千行的函数里面功能不单一，没有注释命名也不清楚，具名变量没有几个都是魔数，等等等等，确实可以说是一份会让人奔溃的代码。

因为重构的任务确实难得，所以想记录一下自己重构过程的一些心得以及即将要踩的坑。

下面说一下目前自己重构的思路：

一、解耦

重构之前领导要我搞个架构设计给它，其实我认为重构这套系统很多架构设计需要考虑的东西都不需要，最重要的还是水平层次的UI、业务逻辑、数据库以及设备控制解耦以及垂直层次的业务间解耦。这套系统耦合太高，开发成本真的是高，因为都是项目型开发只会修改几行代码适应不同项目还没有什么深刻认识，前几天我问一个准备在系统增加功能的同事，是不是加个功能就寸步难行了？他回答是。

花了点时间把系统的解耦划分好，大致方向就确认好，也定制了一些重构过程中的机制。

二、测试保证

重构还是要追求慢而稳，改的越多坑越深，很慌。

部门内部质量保证的机制太少了，没有静态代码检查工具也没有单元测试工具，所以重构前就先把单元测试框架给搭建起来，当然关于测试我只打算测试重要的部分，粒度太细的话整个过程成本高效果也不高，测试的目的只保证重构没出错。

三、重构工具

想看看有什么可以用得上的重构工具，后面查了下没什么合适的就不打算用了。

小结

前两天就已经开始重构了，真的不容易，这份代码太折磨我了，不过重构完一小部分后，代码一下子就让人舒服多了，现在我只期望我运气能比较好，坑肯定在所难免只求坑不要太深。

热门工具换一换