浅谈项目代码重构

浅谈项目代码重构

 

       重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

 

1 重构无法避免

重构无法避免的原因：

（1）一个大型软件，持续不变的是需求，需求的不断变化导致设计架构和代码的不断改变，重构无法避免。

（2）一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的，导致重构无法避免。

（3）日新月异业务变更，导致功能的变化；每日业务数据量的增大，需要性能的提升；产品的深层次架构调整优化，需要革新原有代码。从而，导致设计的调整再所难免。

（4）一个IT团队中，不是所有的程序员开发风格都一样，这样就导致代码质量参差不齐，形成代码Bad Smell （代码坏味道Kent Beck），因此重构无法避免。

 

2 一个只会开发新功能代码，不会重构老功能代码的程序员，充其量只是一个合格的程序员。

 

       一个大型项目难免会有人员更替，一个程序员，也就不可避免需要维护别人代码，接管别人代码。程序员如果只是单纯开发新功能，或者只偏向喜欢开发新功能。这样的程序员会固步自封，不利于个人成长。

      

Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"

 

       一个优秀的程序员，不仅能写出优秀的代码，更应当有能力重构别人的代码，并且敢于向质量差的代码挑战。

 

3 如果你不敢重构老功能代码，说明你对该功能还不够熟悉，对原设计思路还不清楚，或是你的技术能力还有待提升

      

       当你给某一个功能开发一个新功能点，不要急于主管臆断，片面猜测，急于开发，而应当多看，多思考，然后再把新       功能代码和原代码糅合到一起，如果糅合后代码设计结构不够完美。那么需要重构原代码。

利用重构技术开发软件时会把时间分配给两种行为： [重构]与[添加新功能]，两种行为可交替进行，一会重构，一会添加新功能。

      

 

4 项目开发过程中，风险无处不在，重构可能带来新问题，以及上线发布的问题和风险，但，这不是不重构的借口。

 

       一个软件，只要改动代码，就会存在风险。重构的最终目标不是解决无法添加新功能的问题，而是提升软件本身的生命周期。

一、重构的好处：

（1）最大限度规避潜在长远风险；

（2）提升原有代码的可维护性、可阅读性(容易理解的代码很容易维护和增加新功能。代码首先是写给人看的，然后才是计算机看的)；

（3）增加该功能的可扩展性；

（4）延长整个系统项目的生命周期；

（5）学习别人的思想和学习别人的处理逻辑；

（6）有利于最快找到程序错误；（清晰的代码可以更方便的找到bug，重构可以写出更强健的代码）

（7）有利于提高编程速度，提高设计和编码水平；

 

       二、重构的时间

　　（1）随时进行重构（重构是一种开发的习惯，需要培养自己随时随地重构）

　　（2）事不过三，代码重复不要超过三次（否则就要“抽”出来）

　　（3）添加功能时候并一一重构（添加新功能之前，分析并重构，从而更方便添加新功能）

　　（4）修补错误时（通过重构改善代码结构，能够帮助你找出BUG原因）

　　（5）code review时（有经验的开发人员Review代码时能够提出一些代码重构的建议）

 

      三、构筑自动化测试体系，最大限度降低重构风险

    如果你想进行重构，首先要拥有一个可靠的自动化测试环境。

(1)自动化测试代码的价值

    程序员代码编写只占小部分时间，大部分时间用于调试和查找BUG。自动化测试能够大幅减少由于重构代码及新增功能引人的BUG。

(2)XUnit测试框架

    XUnit是一个单元测试框架，用于编写自动化测试用例。每次对代码重构后运行一遍测试用例，检查是否引入了Bug。

 

       基于上述，因为怕重构带来问题，只是一种借口。

 

引述别人的话：【重构已经变成了我的另外一种生活方式，变成了我每天的面包与黄油，变成了我们整个团队的空气与水，以至于无须到书中寻找任何神谕。】

                                                                                                        

 

附录：代码坏味道（Code Bad Smell）

重复的代码（这才是真正万恶之源，鄙视一切Ctrl+C/COPY）

　　过长函数，会导致责任不明确/难以切割/难以理解等一系列问题

　　过大类，职责不明确，垃圾滋生地

　　过长参数列（面向对象不是说说而已）

　　发散式变化，一个类会响应多种需求而被修改

　　散弹式修改（其实就是没有封装变化处，由于一个需求，多处需要被修改）

　　依赖情节（一个类对其他类过多的依赖）

　　数据泥团（如果数据有意义，就将结构数据变成对象）

　　type code，使用Class替代

　　switch，少用，考虑多态

　　过多平行的类，使用类继承并联起来

　　冗余类，去除它

　　夸夸其谈的未来性（过度设计）

　　临时值域，封装它

　　过度耦合的消息链，使用真正需要的函数和对象，而不要依赖于消息链

　　过度的deleate

　　过度使用其他类private值域

　　重复作用的类

　　不完美的类库，（类库老了，使用者也没办法阿）

　　纯数据类（类需要行为）

　　不纯粹的继承（拒绝父类的接口的类）

过多注释，（注释多了，就说明代码不清楚了，尤其是完全废弃的代码，就该直接删除）