重构 (refactoring)主要两个原则需要遵守：
1. 在不改变程式码外在行为的前提下，对程式码做出修正，以改善程式码内部的结构。
2. 要针对该支程式码 (一般以类为单位)撰写白箱的单元测试程式码 (unit test code)
。
违背上述两个原则，那就不是称为重构，而是重写了。 :-)
何时重构？ Martin Folwer 用了非常饶富意蕴的比喻：“嗅出程式码的坏味道”。
这里给您参考基本的两种坏味道，只要有违背，那就是提醒要重构程式码了。
1. 单一 method 陈述超过 30行 (atomic 原则，一个 method 只负责单一工作)。
2. method 参数不得超过5个。参数众多肯定是没有作好参数的资料传递物件 (DTO,
data transfer object)结构的组织。
重构的目的为何？当然是为了增进程式码的品质。重构的好处是什么？当然是让程式码更
具弹性可维护与延展性。重构是为了谁？当然要先为了自己，程式码简洁易读好维护，工
作才可能轻松有意义，而后才有可能扩展到团队乃至全公司，形成一种善文化。独善其身
，才有可能兼善天下。
※ 引述《srwhite (阿白)》之铭言：
: 事情是这样的
: 小弟最近接到使用者需求
: 要增加几个跟之前很像的功能
: 旧的那只程式已经历经许多测试 目前正稳定的运作中
: 但最初的需求很单纯
: 因此设计得不是很有弹性 不利于扩充及更改
: 第一次接到需求的时候
: 我想了一下觉得重构有点麻烦
: 于是直接复制了一份然后改了需要改的地方
: 变成两只有八成像的程式 各做各的
: 但最近又要再增加一个
: 于是我开始犹豫该不该整个打掉重构
: 避免程式码继续这样扩张下去 感觉很不专业
: 之后再有需求也比较好调整
: 但如果复制改一改大概只要一个小时
: 打掉重构可能要一个礼拜 还不保证会不会有什么多出来的bug
: 想请教大家在类似的情况
: 都用哪些标准来决定什么时候应该重构