在代码重构中蜕变

　　这几天，要对我半年前写的代码进行一些整理工作，在看代码时发现当时有很多地方写得不够好，俗称的有“坏味道”，呵呵，重构，必须的。

　　几年前通读过《重构，改善既有代码的设计》一书，虽然对各种重构模式或方法记忆有限，但精髓还是记住了：改代码而不改变软件的外在表现，循序渐进。

　　其实，重构是一个开发人员的基本工作内容，是在每天的开发过程中都要用到的。离开了重构和测试，代码质量是难有保障的。有人会说没有用到重构，其实最简单的例子，当你发现一个类中有几处用到了相同的代码，你把这几行代码提取到了一个私有函数中以供复用，这就是一次重构。所以说，别跟人炫耀你会重构，这是基本功。

　　好久没更新博客了，借此说说我的一点心得吧。

　　1.目的明确。代码是一种平衡的产物，很多地方都在保持着某种平衡，有功能与性能的平衡，有可靠性与可维护性的平衡等等，每一次动手，都要有一个目标，是想改进局部代码，还是想改进类结构，只有针对不同的目的才能实施不同的方法。

　　2.评估影响。改动前，最好能有个预估，对可能产生的影响做到心中有数，以免引起不必要的后果。在“坏味道”的代码中是很有可能牵一发而动全身的，要注意安全。如果只是对类的私有成员的改动，那通常影响的范围有限，如果涉及到对公有成员或保护成员的改动，那就要注意了，简单的评估方式是充分利用IDE的搜索、引用等功能，把引用过此成员的代码行全部找出来，看看影响的范围有多广，如果有些代码不在你的控制之内，那就要慎重考虑这个重构了。

　　3.慎改结构。设计人员或架构师在定义类结构的时候一定有他的综合考虑，在没有充分理解之前，请慎重吧。不要拿设计模式去套现有的结构，设计模式是个指导，如果学完设计模式还在硬用来套用，那这种僵化的思维还不如不学的好。所以，当想要做这样的重构时，请与你的设计师、架构师或有经验的同事协作，除非你自己就是设计师。

　　4.小步伐前进。每次改动尽量小，这样可以把影响限制到小范围。就像一个公式一样，如果同时改变其中的几个变量，那很难说是哪一个影响了结果，但如果一次只改变其中的一个，就可以确认其对结果的影响。尤其是当代码已经完成了用户需求，这时的重构只是为了让代码更好，切忌不要影响到已经得到用户确认的外在表现。

　　5.测试。无论你的开发是否是测试驱动，在重构时测试是保证代码正确的必要手段。修改-编译-测试，重复这个过程，直到达到目的。

　　当你花了几分钟或者几个礼拜，已经让代码大为清爽的时候，回过头来对比曾经的“坏味道”，我想，你会喜欢上代码的，重构会发生在你写下一行代码的时刻，变成了编码能力了。

　　少一行代码，就少一分出错的可能，别心疼你删除掉的代码，虽然那是你的心血，但那已经是历史，在重构代码中蜕变已经完成。