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