ronety的博客

何时重构在软件开发编码的过程中，有些人认为“重构”就应该在软件开发完成后，专门找时间来进行，不然就不叫重构了。但我们反对专门拔出时间来重构，重构应该随时随地进行。不应该为了重构而重构，你之所以重构，是因为你想做出别的什么事，重构可以帮助你把那些事做好。三次法则（The Rule of Three）第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是做了；第三次再做类似的事，你就应该重构。【Tips：事不过三，三则重构（Three strikes and you refactor）

常见的不良编码习惯什么样的代码需要被重构呢？《重构——改善既有代码的设计》一书中已经有了非常全面的论述，下面就是从该书中，总结出来的“代码的坏味道”。Duplicated Code(重复的代码)重复代码是最常见的异味，往往是由于Copy&Paste造成的，最单纯的重复的代码就是“同一个类（class）内的两个函数含有相同的表达式（expression）”.Long Method（过长的函数）过长的函数是面向结构程序开发带来的后遗症，降低了程序的可读性。Large Class

定义和特性说明敏捷本身提倡与重视的就是“以人为本，以代码为核心”的思想。因此面向代码的设计、持续优化和测试等技术成为敏捷开发的核心技术。重构的理论基础源自William Griswold于1991年的博士论文《Program Restructuring as an Aid to Software Maintenance》，但是作为一项敏捷实践广为应用的推动力，确实源自Martin Fowler的经典著作《重构–改善既有代码的设计》。Martin Fowler 在书中这样定义重构：所谓重构就是这样一个过程

敏捷开发方法框架ScrumXPOpen UPLean敏捷开发管理实践项目管理迭代式开发多级项目规划完整团队风险价值生命周期冲刺规划每日站会任务版燃尽图故事点评估开发代码规范测试测试管理变更管理团队变更管理敏捷开发工程实践需求管理产品订单业务流程草图用例驱动开发用户故事架构演进的架构演进的设计基于组件的架构设计开发结对编程测试驱动开发重构测试单元测试并行测试测试分层变更管理持续集成自动构建