重构，从字眼看来，是一个比较抽象而且是相当泛的词。对于很多程序员来说，也许对它比较熟悉，看过很多，也听过很多，可是想要给它一个具体的定义，是比较困难的。当然，它的困难不是在于中国的文字难于琢磨，而是在于它的思想。
重构的主要目的，就是为了使代码更加简洁、让框架更加清晰、运行的速度更加快。也就是说，在编写代码了之后，在不更改外部代码的前提下，通过修改内部结构
的代码来改进代码的整体质量。从语言发展的历史可以看出，从低级语言开发到面向对象的开发，重构在这个成长过程中，扮演着越来越重要的角色。因为重构可以
加强代码的健壮性、可读性，更重要的是保持了模块间、接口间的相对独立性。不会因为修改了某一处代码，因为其之间的紧密依赖令其他代码无法执行，甚至导致
了整个系统零乱不堪。
所以，怎样能使一个大型的程序健康的发展，从重构的思想看，首先就得看你给它什么样的框架了，你的框架能放多少东西，而且在放的过程中，会不会因为某一模
块或者某一个接口的进入，伤害到其他模块的正常运行，甚至是崩溃。要保持模块间的相互独立性，尽量的降低里相互依赖性。所以，“封装”这个词眼贯穿了整个
程序的始末。
什么时候重构合适呢？这是一个不好具体定义的时间。简单地去讲，当在你的程序中，你第一次写了这些代码，可是在另外一个函数体中，又再次写了这些代码，也
许你这时候还可以忍受它的重复，可是当它第三次要求你去写的时候，你就得考虑该时候了。减少代码的重复也是重构思想的一个具体体现，这可以减少代码的冗
余，达到代码的简练境界。
还有，当你在一个实现函数中，如果写了很多行代码，这时候也可以考虑怎样去重构。因为在很长的函数体内，往往会降低代码的可读性，而且代码的层次感也是比
较差的，同时会减弱了代码的相对独立性。如果某一行代码有着较为特别的意义，让它独立成为一个函数也是绝对支持的。虽然函数体多，在看代码的时候，切换上
下文比较累，可是多费点我们的头部运动时间，保持了代码的健壮性也是值得的。
代码的重构没有时间表的安排的，要随着代码的成长，需要不断的检测，不断的思考它是不是该重构了，可不要等到代码累积到了连你见了都掉头跑的时候，才想起
重构，那真的是有点迟了。其实一份好的代码，就是功能不影响运行的情况下，不断重构，不断改进的，而不是一气苛成。
有一个好的建议，就是我们在看别人代码的时候，要思考一下，他的代码是不是需要重构呢，重构了之后，会不会提高性能呢？还有把各个接口和模块，用图画出来，考虑它们之间的联系。
最近在看书的过程中，看到这么一个方面，就是说一个团队在编写一个大型的程序时，从框架看是没什么问题的，可是就是运行时间比较慢，优化了还是提高不了其
速度，后来请了另外一个专业的团队过来，帮忙，后来的团队编写了一个性能测试工具，发现在这个程序中，有大量的重复字符串赋值、分配、释放，导致影响整个
运行速度。知道了这点之后，进行修改，这个程序的速度才大幅度的提高。就这点而言，我们在编写自己的代码时，是不是也该时时考虑呢？？？
今天的重构就说到这，有什么不好的请提出来，我还是那句话，目前我是一位刚出炉的“裸体”程序员，请多指教。