先简单说一下感想，重构系统的这半个月，我感觉自己的发际线在慢慢变高。
按原本的计划我是要求领导给我一个熟悉这份代码的人跟我一起结对重构，可世事难料，那个人总共和我结对不到一天的时间，后面就离职了，后面就是我一个人孤单的一个人在重构。
我的思路原本是先将大的UI、主业务逻辑、数据库、设备控制解耦，再将各个模块与业务解耦。这套系统所有的模块功能都集成到一个类中，基本没有将数据与功能分类，所有的变量命名完全没有可读性而言，没有文档，没有注释，可想而知我没办法先将各个模块解耦，并且这样一下子脚步太大所有的东西都耦合在一起，容易出现未知的问题，查找起来也麻烦。
所以我决定先主业务逻辑中各个子业务逻辑剥离，在剥离的过程中我发现这套系统最大的两个问题，一个是乱七八糟的数据太多，另一个是代码全都是复制粘贴，完全就是一个失控的系统。经过半个月的重构我将主业务逻辑能剥离的都剥离出，剩下一下耦合不好解开的就放到最后解决，至于单元测试我没做，我打算在第二轮重构各个模块时再做，原因是我们现在只是简单的消除重复以及将相关功能归类，如果做单元测试的话后面测试用例改动太频繁不过我有对主要功能进行调试。
在这次重构中让我印象深刻有两点，一个是破窗户另一个是沟通。
破窗户：
我第一次那么深刻的意识到，破窗户居然可以大到如此地步，一个人一旦开始复制粘贴后面的人全用复制粘贴，这实在是过于吓人。
大部分的人都会随波逐流，在好的代码环境下编码也模仿的有模有样，在糟糕的代码环境下让代码变得越来越糟糕，即使是工作有一定年限的人也是如此，他们通常不会说自己这样写出来的代码有多差，而是说他们之前就是这样写的。
所以我认为我们应该在代码出现坏味道之前就重构它，不要像系统崩坏后开发维护成本很高的情况才去重构它。
沟通：
在重构的过程中，由于这代码真的是写给机器看的，所以我会比较频繁的跟相关人员沟通，但是我发现他们不是很愿意沟通，我需要想方法引导他们才能得到我要的答案，一份写给机器看的代码与不愿跟你沟通的同事，可想而知重构这份代码的难度，我自认为阅读代码的能力还算可以，因为有经常看一些开源代码，但这短短不到3W行的代码竞让我如此为难。不只是我同事，新公司大部分的人在做事方法及沟通上都存在比较大的问题，他们总是没有将一件事情高效的沟通完成，而在推卸责任或是对人不对事，这一点我们新来的一些人都是如此认为的，跟我同一批进来的一些同事倒是挺优秀的。
我对面部门的一个领导刚来十天就离职了，我觉得他是个大牛，对软件开发过程理解非常透彻，做事方法还有沟通方面真的做的非常好，技术方面我不敢判断，但从做事方法还有沟通我就觉得这人是个大牛，这个人离开确实可惜了，我想他应该是觉得这部门带不起才走的吧。