[置顶]甚么是重构，甚么没有是重构
有时候，会有程序员跑到我这里说他们不喜欢某个东西的设计，“我们需要给它来个全面的重构”，来纠正里面的错误。哦，哦。这听起来可不是个好主意。而且这听起来也不是重构…
重构(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所指的”大型重构”。大的、代价很高的变动，附带有大量的技术风险。这不是你编程过程中的清理代码和设计改进：这是根赋性的重新设计。
有些人喜欢把对一个系统的重新设计或重写或重新搭建平台或返工叫“大规模重构”。因为技术上讲，这些并不改变软件功能特征----业务逻辑、软件输入和输出仍和以前一样，“只是”设计和代码实现变了。它和常规重构的区别看起来就是：一个是重写了一段代码，一个是重写了一个系统，只要你是一步一步做下来的，你都可以称之为“重构”----不管你是长年累月被困于将一个老系统换成新代码，还是对系统架构进行大规模的改造。
“大规模重构”会变的很蹩脚。你可能需要花数周、数月(甚至数年)才能完成，需要你对软件的很多局部进行改动。软件会因此不能运行，需要分多次发布这些变更，需要你做临时的台架(scaffolding)和变通方案----尤其是你采用短周期的敏捷开发方法时。这时Branch
by Abstraction这样的实践方法就派上用场了，它能帮你在长周期内管理代码中的变化。
而且在开发新代码的同时你还要维护旧代码，这使得代码版本控制很麻烦，变更起来不方便，致使代码很脆弱，易犯错----这正和重构所预期的目的背道而驰。有时这样的情况会一直持续下往----这种新旧代码交替的过程永远不能完成，因为能获得最大利益的部分都是最先完成，或者因为最初带来这个想法的顾问已经干别的去了，或者是预算被消减，而且你也讨厌维护这样一个拖拉的项目。
这些是重构----那些不是
在这种重型的项目开发过程中混入重构的概念是舛错的。它们从根本上就是另外一种工作，带有完全不同的开发成本和风险。它混淆了人们对什么是重构、重构能干什么的认识。
重构可以、也应该融入到你写代码或维护代码的过程中----作为日常开发/质量管理的组成部分，就像写测试和代码审查一样。重构应该被安静的，持续的和低调的完成。它需要我们把工作精力分出一部分给它，它需要在我们的工期评估和风险评估中考虑到它的存在。如果做的正确，你不需要去解释或向外人验证这部分工作。
花几分钟、一两个小时做重构，就像是你开发过程中的一种修改，是工作的一部分。如果它让你花了数天时间，或者更长，那不是重构；那是重写，或重新设计。如果你需要明确的留出一部分时间(或整个sprint周期)来重构代码，如果需要为清理代码而申请批准，或把清理代码作为一个开发需求，那你不是在重构----即使你用了重构的技术和工具，你仍然做的是另外一种工作。
有些程序员认为对代码进行根本的、重大的修改是他们的权利和义务，在重构的名义下进行重新设计、重写，为了将来，也不辜负自己的技艺。重新设计和重写有时候是你正确的该做的事情。但出于坦诚和表述清楚，请不要把这些活动赋以重构的名义。
[本文英文原文链接：What Refactoring is, and what it
文章来源：aqee.net
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。什么是页面重构？都做哪些工作？思想是什么 ？
[问题点数：100分，结帖人lyj]
什么是页面重构？都做哪些工作？思想是什么 ？
[问题点数：100分，结帖人lyj]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。5864人阅读
今天和同事讨论问题，忽然冒出一个问题，什么叫重构？改一行代码算不算重构，改一百行代码算不算重构，改一万行代码算不算重构？改一个类关系算不算重构，改十个类关系算不算重构，改一百个类关系算不算重构？百度百科上说：重构就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。这其实不是一个定义，而是一个愿望。上面那句话说的其实是“我们打算调整程序代码，然后希望软件的质量性能会有所提高”。改代码是行为，质量性能的提高是愿望。实际上改代码未必能使软件变得更好，也可能软件大规模改动之后，反而变得更差了。那么，这种大规模改动还符合上述的‘重构’定义吗？重构是一个模糊的概念，指代的是对程序做较大程度的改变。无关软件质量。某君说：我只知道改代码，不知道什么叫重构。‘重构’这个概念的模糊带来一个不好的影响，就是很容易让人轻易的说出重构这种词，以为重构之后就一切都会变好。实际上大规模改动或者重写之后，软件常常未必会变好。我见过一个软件毫无必要的一年之内重构了三次，除了过程中带来一堆bug，并没有提高系统的功效。为什么呢？因为有些同学误以为重构就是提高改进。NIH（Not Invent Here）综合症也和对‘重构’的误解有关，总以为重新实现一次就可以比以前好。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：790806次
积分：9931
积分：9931
排名：第1164名
原创：185篇
评论：570条
(2)(1)(1)(1)(2)(2)(1)(3)(3)(2)(1)(2)(3)(1)(6)(1)(3)(3)(2)(3)(2)(4)(3)(1)(4)(1)(2)(3)(1)(1)(2)(3)(3)(5)(5)(3)(1)(8)(1)(1)(1)(1)(2)(1)(1)(2)(1)(3)(1)(1)(2)(1)(2)(2)(1)(2)(1)(1)(1)(1)(2)(3)(2)(2)(2)(1)(1)(1)(1)(4)(1)(4)(2)(2)(3)(1)(5)(4)(3)(1)(3)(3)(2)(4)(3)(2)(2)(7)(4)形成性评估的概念重构_百度百科
形成性评估的概念重构
《形成性评估的概念重构》是2012年出版的图书，作者是曹荣平。
形成性评估的概念重构内容介绍
曹荣平编著的《形成性评估的概念重构》旨在通过建立一个形成性评估的理论模型来弥补形成性评估理论研究的不足。该模型的认识论基础是控制论框架下评估和学习之间的关系。借鉴控制论有关复杂系统的思想，《形成性评估的概念重构》推出的形成性评估模型可用于解释评估与学习的关系和评估的形成性工作机理。该模型视评估为复杂的学习系统中的一个复杂的控制系统。该系统具开放性、非预决性和自律性特征。评估的控制性系统特质决定了其在学习系统中的建构作用，评估对学习的控制由信息反馈来实现。基于控制论思想对评估的推断和解释与现有形成性评估概念在内涵和外延上有着显著区别，从而支持了对形成性评估进行概念重构。
形成性评估的概念重构主要意义
概念重构的意义在于：（1）修正了形成性评估的内涵和外延；（2）淡化了形成性评估和终结性评估的对抗性；（3）指出了所有类型评估皆具形成性意义；（4）指出了评估的双刃剑特性和评估系统的可自律性；（5）指出了正确认识评估系统，进而管理好这个复杂系统的必要性和可行性。
．豆瓣读书[引用日期 16:08:04]
企业信用信息