什么是重构----软件重构分析.doc

软件重构分析 以前很推崇重构，现在也很喜欢，不过现在明白了不要为了重构而重构，重构后带来的风险作为一个开发人员一定要事先预估好，另外要利用一些手段去避免有bug出现，比如单元测试 有时候，会有程序员跑到我这里说他们不喜欢某个东西的设计，“我们需要给它来个全面的重构”，来纠正里面的错误。哦，哦。这听起来可不是个好主意。而且这听起来也不是重构… 重构(Refactoring)这个词最初由Martin Fowler 和 Kent Beck给下的定义，它是一种修改，使软件的内部结构更容易理解，在不改变软件的可见行为方式前提下使软件更容易变更…它是一种有节制的整理代码、使bug产生几率最小化的方法。 重构的结果是引用了快捷方法、去除了重复代码和死代码，使设计和逻辑更加清晰。是在更好的、更聪明的使用编程语言。是在优势利用你现在知道、但 当时的开发程序员并不知道——或并没有加以利用的信息。不断的简化代码，让它们更容易理解。不断的使它们在将来的变更变得更容易、更安全。 在这个过程中发现了bug、修改bug，这不是重构。优化不是重构。强化异常捕捉、增加预防性代码不是重构。让代码更容易测试不是重构——尽管重构能达到相同的效果。这些所有的事都是有益的。但这些都不是重构。 程序员，特别是做维护工作的程序员，清理代码是他们的日常工作之一。这是基本工作，是必须要做的。Martin Fowler等人的贡献是使重构代码的最佳实践方法格式化，并把常见的、证明切实有效的重构模式——重构的目标和重构的步骤——进行归档分类。 重构很简单。尽可能在写代码前先写测试能够防止你犯错误。小规模的、独立的、稳妥的对代码进行结构上的调整，每次调整完后都要进行测试，确保你 没有改变代码的行为特征——功能和以前一样，只是代码上看着不同。重构模式和现代化的IDE里的重构工具使重构变得容易、安全和代价低廉。 不要为了重构而重构 重构可以被当成一种能给你的代码变更带来帮助的措施。代码重构应该在你进行代码变更前进行，这样能让你确信你对代码理解了，使你更容易、更安全 的把变更引入代码。对你的重构动作进行回归测试。然后进行纠正或变更。再次测试。之后可能需要对更多的代码进行重构，使你代码变更的意图变得更加清晰。再 次进行全面测试。重构，再变更。或变更，然后重构。 你不是为了重构而重构，你重构是因为你想做其它的事情，而重构能帮助你完成这些事情。 重构的范围应该受你需要实施的代码变更或代码修正来决定——为了让代码变更更安全和更简洁，你应该做些什么？换句话说：不要为了重构而重构。不要对那些你不打算进行变更或不会变更的代码进行重构。 为理解而做简略重构(Scratch Refactoring) Michael Feather的《Working Effectively with Legacy Code》这本书里提到了简略重构(Scratch Refactoring)的概念；Martin Fowler称之为“为理解而重构”。这是用来对付那些你不理解的(或不能忍受的)代码，清理它们，这样在你打算真正动手修改它前，你能对它们是干什么的 有了更好的理解，同样也对你debug这些代码有帮助。一旦你能清楚了一个变量或方法的真正意图，重命名它们，给它们一个更合适的名称，删除那些你不喜欢 看的(或觉得没有用的)代码，拆解复杂的条件语句，把长程序分解成数个容易理解的小程序。 不要惦记着复查或测试这些改动。这是为了让你的重构快速的推进——这能让这些代码以及它们的运行原理在你的大脑里产生一个快速但不完备的原型。 从中学习，然后丢掉它们。简略重构还能让你尝试各种不同的重构途径，学到更多的重构技巧。Michael Feathers建议说，在这个过程中要留意那些看起来没什么用处、或者特别有用的东西，这样当你完成此练习后、要真正修改它们时，才能把事情做正确—— 修改时一点一点来，讲究方法，边修改边测试。 什么是“大规模”重构？ 对代码进行简单的但又明显的重构：消除重复，修改变量和方法名称使其更有意义，提炼方法使代码更易懂、更易复用，简化条件逻辑，把无意义的数字换成命名的变量，把相似的代码集中到一起。通过这些重构，在代码的可理解性和可维护性上，你能得到巨大的回报。 相对于这些较小的、行内的重构，更加重大的设计上的重构与之有明显差异——这就是Martin Fowler所指的”大型重构”。大的、代价很高的变动，附带有大量的技术风险。这不是你编程过程中的清理代码和设计改进：这是根本性的重新设计。 有些人喜欢把对一个系统的重新设计或重写或重新搭建平台或返工叫“大规模重构”。因为技术上讲，这些并不改变软件功能特征——业务逻辑、软件输 入和输出仍和以前一样，“只是”设计和代码实现变了。它和常规重构的区别看起来就是：