《重构》第一次进行系统重构，我是如何完成的？

      大家好，我是阿桃，一个想成为被点赞关注的程序员。

     工控行业、物联网行业、机器人行业软件开发可联系我

一、前言

        去年毅然决然离开福州来杭州发展，进入新公司后，组长觉得我对编程方面比部门其他同事会更在行一些，于是将系统重构的任务交给我负责，因为当前这套系统已经严重对研发人员开发维护的效率造成影响。对一套全新的完全陌生的系统也没有自动化测试系统进行重构，我首先提出的当然就是找一个对系统熟悉的同事进行结对重构，但是好景不长，结对的那个同事在两周后离职了，由于人员紧张只能我一个人重构这套陌生的将近10w行的系统，历时长达5个月的心路历程就此开始。

        我从事的是嵌入式软件开发，部门早前开发维护系统的同事对编程这块不太注重，怎么实现比较快就怎么来，所以充满了复制粘贴的代码，系统属于典型的非正交系统，当然这样的系统即存在几千行的功能不单一函数，没有编程规范，系统十分脆弱并且难以维护，毫无疑问这套系统的代码是我工作以来见过最糟糕的。

二、怎样进行重构

        本来重构应该是贯彻于日常过程中，因为包括你随着时间对软件的理解不一样、并且程序的复杂性是随着时间增长的等等，所以当你发现错误的东西时就该 毫不犹豫的进行重构，关于怎样进行重构，主要分为以下几步：

        1.在重构之前与组长沟通确保在重构期间基本上不会有新功能增加。

        2.由于系统早前没有任何自动化测试保证回归测试，所以这边只能要求给出重要的测试用例，尽可能保证每次小步重构的内容对系统重要功能并不造成影响。

        3.不断进行小步重构修改并测试通过直到重构任务目标完成。

        4.指定重构目标，考虑到只有我一个人负责并且时间问题，目前对于该系统最重要的是消除重复以及实现正交性，之后团队在日常开发维护过程中对设计的代码进行重构。

三、为什么重构主要消除重复与实现正交性？

         如果你紧密结合DRY原则以及运用正交性原则，你将会发现你开发的系统会变得更灵活、更易于理解、并且更易于调试、测试和维护，提高开发的效率。

1.关于重复

        可靠地开放软件、并让我们的开发更易于理解和维护的唯一途径就是遵守DRY原则，不要重复你自己。经过与同事们的确认，该系统中代码的重复主要有两个原因，时间压力以及在他们开始接手系统时就已经充满重复代码。与重复相反的一个概念便是复用，我们在开发组件时需要使其容易复用，如果不容易就不会有人去复用就会出现重复的危险，重复会大大降低效率（你可能遗漏某一处冗余的代码导致bug产生），提高复用性会使你产能增加。

2.关于正交性

        大多数开发者熟悉设计正交的系统，不过他们会使用像模块化、基于组件、或是分层这样的术语描述该过程。正交的系统主要有两个好处，提高生产率与降低风险。正交的系统各个组件解耦使改动得以局部话开发时间得以降低，解耦的组件能够促进复用提高效率。解耦的组件能使系统更健壮，组件之间有问题不会相互影响并能更好的进行组件测试。

四、重构引申出来的反思

        大家应该有听说过破窗户理论，本次就是典型的破窗户事情。如果在有好些破窗户的项目里工作，会很容易产生这样的想法，这些代码的其余部分也是垃圾，我只要照着做就行了，所以一但一个人出现复制粘贴后，之后的开发维护人员也照做了。

        很多人都会随波逐流，在好的代码环境下编码也模仿的有模有样，在糟糕的代码环境下让代码变得越来越糟糕，他们通常不会说自己这样写出来的代码有多差，而是说他们之前就是这样写的。

        所以我认为我们应该在代码出现坏味道之前就重构它，不要像系统崩坏后开发维护成本很高的情况才去重构它。