重构——让你的代码接近框架源码

前一段我们的项目搞了一次重构，我简单做了一个ppt，下面我们来一起分享下 


代码的坏味道 
1、重复代码（难维护） 
•提取公共函数 
2、函数过长（难理解） 
•拆成若干函数 
3、类过大（难理解） 
•拆成若干类 
4、参数多（难用） 
•将参数封装成结构或类 
5、万能类（改动频繁） 
•拆，将总是一起变化的东西放在一块儿，合久必分 
6、天女散花逻辑（需求变动改很多类） 
•将各个修改点，集中起来，抽象成一个新类。 
7、红杏出墙的函数（使用了大量其他类的成员） 
•将这个函数挪到那个类里面。 
8、数据团（常一起出现的一坨数据） 
•他们那么有基情，就在一起吧，给他们一个新的类。 
9、冗余类（如果不干活了就干掉他） 
•提取公共函数 
10、继承过多（父类里面方法很多，子类只用有限几个） 
•用代理替代继承关系。 
11、Switch惊悚现身（从本质上说，switch语句的问题在于重复） 
•考虑用多态替换他 
12、太多注释 
避免用注释解释代码，而是说明代码的目的，背景等。好代码会说话。 
重构是软件发展的必然： 
因为我们的软件总是由简单软件向复杂软件转变；当软件开始由简单向复杂软件转变时我们就需要重构。 


 



 



 







 





以上就是一个简单的重构过程，重构是在日常工作不影响正常开发进度中进行的，这个需要根据我买项目的实际情况自己把握。 
最后我在总结下： 
1·持续偏纠和改进软件设计 
重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。 
2·使代码更易为人所理解 
Martin Flower在《重构》中有一句经典的话：”任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。”对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？ 
软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。 
对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！ 
3·帮助发现隐藏的代码缺陷 
孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的”感冒”当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。 
4·从长远来看，有助于提高编程效率 
当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。 
改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的