文档介绍：以前很推崇重构,现在也很喜欢,不过现在明白了不要为了重构而重构,重构后带来的风险作为一个开发人员一定要事先预估好,另外要利用一些手段去避免有bug出现,比如单元测试有时候,会有程序员跑到我这里说他们不喜欢某个东西的设计,“我们需要给它来个全面的重构”,来纠正里面的错误。哦,哦。这听起来可不是个好主意。而且这听起来也不是重构…重构(Refactoring)这个词最初由MartinFowler和KentBeck给下的定义,它是一种修改,使软件的内部结构更容易理解,在不改变软件的可见行为方式前提下使软件更容易变更…它是一种有节制的整理代码、使bug产生几率最小化的方法。重构的结果是引用了快捷方法、去除了重复代码和死代码,使设计和逻辑更加清晰。是在更好的、更聪明的使用编程语言。是在优势利用你现在知道、但当时的开发程序员并不知道——或并没有加以利用的信息。不断的简化代码,让它们更容易理解。不断的使它们在将来的变更变得更容易、更安全。在这个过程中发现了bug、修改bug,这不是重构。优化不是重构。强化异常捕捉、增加预防性代码不是重构。让代码更容易测试不是重构——尽管重构能达到相同的效果。这些所有的事都是有益的。但这些都不是重构。程序员,特别是做维护工作的程序员,清理代码是他们的日常工作之一。这是基本工作,是必须要做的。MartinFowler等人的贡献是使重构代码的最佳实践方法格式化,并把常见的、证明切实有效的重构模式——重构的目标和重构的步骤——进行归档分类。重构很简单。尽可能在写代码前先写测试能够防止你犯错误。小规模的、独立的、稳妥的对代码进行结构上的调整,每次调整完后都要进行测试,确保你没有改变代码的行为特征——功能和以前一样,只是代码上看着不同。重构模式和现代化的IDE里的重构工具使重构变得容易、安全和代价低廉。不要为了重构而重构重构可以被当成一种能给你的代码变更带来帮助的措施。代码重构应该在你进行代码变更前进行,这样能让你确信你对代码理解了,使你更容易、更安全的把变更引入代码。对你的重构动作进行回归测试。然后进行纠正或变更。再次测试。之后可能需要对更多的代码进行重构,使你代码变更的意图变得更加清晰。再次进行全面测试。重构,再变更。或变更,然后重构。你不是为了重构而重构,你重构是因为你想做其它的事情,而重构能帮助你完成这些事情。重构的范围应该受你需要实施的代码变更或代码修正来决定——为了让代码变更更安全和更简洁,你应该做些什么?换句话说:不要为了重构而重构。不要对那些你不打算进行变更或不会变更的代码进行重构。为理解而做简略重构(ScratchRefactoring)MichaelFeather的《WorkingEffectivelywithLegacyCode》这本书里提到了简略重构(ScratchRefactoring)的概念;MartinFowler称之为“为理解而重构”。这是用来对付那些你不理解的(或不能忍受的)代码,清理它们,这样在你打算真正动手修改它前,你能对它们是干什么的有了更好的理解,同样也对你debug这些代码有帮助。一旦你能清楚了一个变量或方法的真正意图,重命名它们,给它们一个更合适的名称,删除那些你不喜欢看的(或觉得没有用的)代码,拆解复杂的条件语句,把长程序分解成数个容易理解的小程序。不要惦记着复查或测试这些改动。这是为了让你的重构