最近两周一直在忙于重构以前的一段代码。代码是一个很复杂的算法，总共有4个主要的方法，代码行数之和大概有4千多行。这个算法以前不是我写的是一位已经离职人员的大作，刚开始接受的时候我看的头都大了。现在想想造成这种情况主要原因主要有：
1 因为这是一个很复杂的算法，需求文档写的也不是很详细，导致理解起来很费力，最后是通过不断和测试人员不断交流，才了解了整个算法的大概。
2 看代码最可怕的事情是什么？结构不好、变量命名不规则、实现思路不符合常规。都不是，最可怕的是没有注释，我所要面对的是我可以自由发挥想象的代码，可是 一个算法不是我可以随意定的。刚接手代码时的主要工作就是，给代码添加注释，一边看一边补注释，最后可能达到每5行代码就可能有一行注释，就这样才把代码 的实现丝路搞得差不多了。
3 方法过长 4个方法，4千多行代码，平均每个1千行，但最大的那个方法有2千多行，看着无注释的两千行代码，我晕。
4 重复功能的代码 接受别人的代码，如果感觉是重复的代码，自己也不敢给立刻改造，需要把两段代码仔细的比较，生怕有纰漏，导致一些更可怕的问题，毕竟当时对代码和算法不熟悉
5 庞大的if else、for while 循环，看代码的时候需要对那些{},眼晕，代码太长了，如果你想了解一段代码的功能，难了。
6 数据类的命名 那位老兄懒点，有些后来添加的属性，他懒得添加代码，就用原来的方法，看看代码就给带沟里去了。
7 很多无用的变量充斥其中，让你四处查找该变量在哪用的，最后发现，没用，气疯了

    痛苦的经历，当时看这些代码辞职的心都有，型号当时在外面做项目，可以慢慢的消化，如果在公司，问题日清，恐怕我也要被清理走了。
下面说说我重构的过程，主要是针对上面提到的几点：
1 不用说了，理解算法，才能作出正确的实现，也才能保证修改的代码减少出错的机率。
2 注释以前添加了很多，现在在回头再仔细看，当时有些理解是不正确的，修正那些注释，同时把自己最新的理解添加到程序上。添加注释时对于实现长点的代码可以 用一些特殊的符号 象＃$等一些特殊的符号分隔开，注释里说明这段代码实现的功能，同时在开始和结束的注释上 添加一个简单的start、end，看起来舒服多了
3 方法过大，没有其他的解决办法，拆方法，但拆方法的时候要考虑变量的作用域，尽量确保一个变量的作用域在一个方法中，这样可以减少代码的出错的可能性，是在不行的就通过返回数据的方式，给变量重新赋值
4 对于重复的代码，没其他的办法，抽象出一个新的方法，让后在主方法中调用。但这种修改可能会造成一个不太好的现象，就是代码调用层次太多，调试起来也很麻烦，这问题只能等以后在做大的重构的时候，对实现思路的重构了
5 对于if else ,或者循环，看看是否可以通过continue、break 来减少嵌套层次
6 数据命名，这是每个程序员进入新公司的必修课，如果没人管，那只能说管理有问题。可以通过一些重构工具来修改变量、方法的名称、相应的工具会修改引用的名称，减少出错的可能性
7 多余变量已经要坚决删除，不是考虑什么效率问题，知识考虑代码的可读性。现在地很多开发工具可以表示出没有引用的变量，删除、重新编译看看有没有引起相关的错误

本来前些时刚看完设计模式，想用用呢，因为算法中有很多相对的算法可以通过策略模式解决，可是最后犯懒，以后再说吧。
一点感受，希望能和大家交流：）