重构心得（一）

目的：在不改变软件可观察行为的提前下，提高可理解性、降低其修改成本。
过程：在不改变软件可观察行为的提前下，调整其结构。
重点方向：消除重复代码。

重构应随时随地进行，不应该为重构而重构。

1、三次法则：当你对同一块代码，进行三次修改时，你就应该重构此部分代码。
2、如果收到一份错误报告，这就是需要重构的信号，因为显然代码还不够清晰－没有清晰到让你能一眼看出bug.

代码复审，有助于在开发团队中传播知识，也有助于让较有经验的开发者把经验传递给比较欠缺经验的人，并帮助更多人理解软件系统中的更多部分。

待续。。。

个人意见，真正影响重构的关键问题是：

这种看不到短期效果，没有实质生产率的事情，给你把“重构”当成个事来排进度已经是项目经理最大的容忍限度了，绝对不能在重构过程中引入bug，千万绝对必须一定不能在重构中给别人引入bug。

因此要重构的代码至少应该有95%以上覆盖率的单元测试保护。

但问题是，有些代码，你不先给它重构，根本就没法写单元测试。这时要么项目还非常小（及时引入TDD），要么你就得有一个心境平和的项目经理和一班任劳任怨的人工测试团队。

我现在所做的产品，并不是一个以项目成果为目的的产品，而是公司准备大量投钱的战略产品。所以，并不能完成以进度来衡量项目开发进度。
我们可以为了提高某模块的用户感知，而放弃其他工作，专注重构此部分功能，直到令客户满意及稳定为止。
至于单元测试，来说惭愧，因为我们是一个没有稳定测试人员的产品，只能靠全公司及几个战略客户来进行测试（几W用户）。这也是我认为重构如何重要的原因。