浅谈重构

最近看了世界软件开发大师 Martin Fowler  <Refactoring improving the Design of Existing Code>  , 熊节译的 《重构改善既有代码的设计》 一书， 感觉很受益， 因为手头有一个项目， 代码已经很多人之手， 已经很凌乱了， 正好可以，也必须考虑重构。  一年前， 在同事口中了解到重构， 但理解得并不深刻， 甚至就只知道它只是个专业术语， 感觉用不上， 以前总以为程序员，把一个功能完成就行了， 重构，浪费物力人力。 

后面， 在图书馆借了一本书， 粗略地阅读了一下， 收益甚微， 再到后来， 手头一个项目， 使得不得不重新整理代码， 也不得不重构了，才发现重构在代码量较大的软件开发过程中是很有用的。 

我手头的项目， 最初的功能相对单一很多， 后面， 需求的不断更改，新功能不断地添加， 导致代码量是越来越大， 加上不断有新手地加入，对代码流程的不重视和代码质量的不重视，导致后面代码越来越烂，  发展成一个项目几乎有上千的代码文件， 单个文件代码行数最高达到了两万多行， 而且， 从项目架构起来到交付下面程序员开发， 由于重不写注释， 代码很晦涩难懂， 加上cmake 的构建更使用整个框架难已整理。 

在后面的一段日子里，重构成了一种必须。 慢慢发现了很多重构的技巧， 也学到了不少东西。 重构就是一种在不改变代码功能的前提下，现实代码的优化，所以， 如果只注重功能， 而不注重代码质量的程序员或项目经理， 通常觉得这是没必要的， 这个过程也是一种对时间的浪费。 虽然， 重构确实有些花时间， 而且，不容易看到成效， 因为它改变不了， 也不能改变原来的功能， 所以， 别人不知道你在做什么 ， 不过， 我个人感觉从这个过程中， 是可以学到不少东西的。 

首先， 重构的过程中， 需要不停地完善代码， 不管是封装字段， 提炼类， 搬移函数，还是合并表达式， 提炼继承体， 引入外加函数， 它们都要求参与者对当前代码有一定的认识， 在这种认识下，发现此处代码的劣势和不足的地方并进行改动。 在这个过程中，渐渐发现，再次写其它功能代码时，会变得小心谨慎， 更加注重代码的编写规范和代码的流程逻辑。 

其次， 重构是一小块一小块地进行， 一小块一小块地测试， 这个过程会让参与者更加熟悉整个业务流程和代码逻辑。重构过的代码，变得整洁，不再杂乱无章，对后面代码功能的添加和程序的维护能起来不小的作用 。

当然， 什么都需要坚持， 特别是一个代码量很大的项目， 重构的过程，必须小心谨慎， 因为这个过程，粗心大意， 可能会影响到原来已实现功能， 甚至出现一些严重的错误，所以在重构的过程中， 需要一边修改代码，一边自己测试是否影响到原来功能。 而对重构方法的熟练掌握也是必要的， 需要注意到很多小的细节。