《
什么是重构，什么不是重构》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/030233I62013.htm
Tag：重构 不是
--> [
网站建设之]什么是重构，什么不是重构
有时候，会有程序员跑到我这里说他们不喜欢某个东西的设计，“我们需要给它来个全面的重构”，来纠正里面的毛病。哦，哦,
什么是CSS？CSS的由来及学习技巧。这听起来可不是个好主张。而且这听起来也不是重构…
有些人爱好把对一个系统的从新设计或重写或重新搭建平台或返工叫“大范围重构”。由于技巧上讲，这些并不转变软件功效特点——业务逻辑、软件输入和输出仍和以前一样，“只是”设计跟代码实现变了。它和惯例重构的差别看起来就是：一个是重写了一段代码,什么是css，一个是重写了一个体系，只有你是一步一步做下来的，你都能够称之为“重构”——不论你是终年累月被困于将一个老系统换成新代码，仍是对系统架构进行大规模的改革。
在这种重型的项目开发过程中混入重构的概念是错误的。它们从根本上就是另外一种工作，带有完整不同的开发本钱和危险。它混杂了人们对什么是重构、重构能干什么的意识。
一种修改，使软件的内部构造更容易理解，在不改变软件的可见行动方法条件下使软件更容易变更…它是一种有节 制的收拾代码、使bug产生几率最小化的方法。
你不是为了重构而重构，你重构是因为你想做其它的事情，而重构能辅助你完成这些事情。
有些程序员以为对代码进行基本的、重大的修改是他们的权力和任务，在重构的名义下进行重新设计、重写，为了未来，也不辜负本人的技能。重新设计和重写有时候是你准确的该做的事件。但出于坦诚和表述明白，请不要把这些运动赋以重构的名义。
什么是“大规模”重构?
程序员，特殊是做维护工作的程序员，清理代码是他们的日常工作之一。这是基础工作，是必需要做的。Martin Fowler等人的奉献是使重构代码的最佳实际方式格局化，并把常见的、证实切实有效的重构模式——重构的目的和重构的步骤——进行归档分类。
不要惦念着复查或测试这些修改。这是为了让你的重构快捷的推动——这能让这些代码以及它们的运行原理在你的大脑里发生一个疾速但不齐备的原型。从中学习，而后丢掉它们。简略重构还能让你尝试各种不同的重构道路，学到更多的重构技能。Michael Feathers倡议说，在这个过程中要留心那些看起来没什么用途、或者特别有用的货色，这样当你完成此训练后、要真正修改它们时，才干把事情做正确——修改时一点一点来，讲求办法，边修改边测试。
不要为了重构而重构
Michael Feather的《Working Effectively with Legacy Code》这本书里提到了简略重构(Scratch Refactoring)的概念;Martin Fowler称之为&ldquo,什么是CSS Sprite技术;为理解而重构”。这是用来凑合那些你不理解的(或不能忍耐的)代码，清理它们，这样在你打算真正着手修改它前，你能对它们是干什么的有了更好的理解，同样也对你debug这些代码有帮助。一旦你能清晰了一个变量或方法的真正意图，重命名它们,什么是css sprites，给它们一个更适合的名称，删除那些你不喜欢看的(或感到没有用的)代码，拆解庞杂的条件语句，把长程序分解成数个容易理解的小程序,什么是CPM、CPC、CPA、CPS广告。
这些是重构——那些不是
重构的范畴应该受你需要实行的代码变更或代码修改来决议——为了让代码变更更安全和更简练，你应该做些什么?换句话说：不要为了重构而重构。不要对那些你不盘算进行变更或不会变更的代码进行重构。
而且在开发新代码的同时你还要维护旧代码，这使得代码版本把持很麻烦，变革起来不便利，以致代码很懦弱，易出错——这正和重构所预期的目标南辕北辙。有时这样的情形会始终连续下去——这种新旧代码交替的过程永远不能完成，因为能取得最大好处的部分都是最先实现，或者因为最初带来这个主意的参谋已经干别的去了，或者是估算被消减，而且你也厌恶保护这样一个拖沓的名目。
为懂得而做简单重构(Scratch Refactoring)
重构很简略。尽可能在写代码前先写测试可能避免你犯过错。小规模的、独破的、稳当的对代码进行结构上的调剂，每次调整完后都要进行测试，确保你不改变代码的行为特征——功能和以前一样，只是代码上看着不同。重构模式和古代化的IDE里的重构工具使重构变得容易、保险和代价低廉。
重构可以、也应当融入到你写代码或维护代码的过程中——作为日常开发/品质治理的组成部分，就像写测试和代码审查一样。重构应该被宁静的，持续的和低调的完成。它需要咱们把工作精神分出一部分给它，它需要在我们的工期评估微风险评估中斟酌到它的存在。如果做的正确,交互，使用，交互设计和可用性，你不需要去说明或向外人验证这部分工作。
重构的成果是援用了快捷方法、去除了重复代码和逝世代码，使设计和逻辑更加清晰。是在更好的、更聪慧的应用编程语言,交互设计指南 一次点击。是在上风应用你当初晓得、但当时的开发程序员并不知道&mdash,交互设计分析 通过设计减少用户的出错;—或并没有加以利用的信息。一直的简化代码，让它们更容易理解。不断的使它们在将来的变更变得更容易、更安全。
对代码进行简单的但又显明的重构：打消反复，修改变量和方法名称使其更有意思，提炼方法使代码更易懂、更易复用，简化前提逻辑，把无意义的数字换成命名的变量，把类似的代码集中到一起。通过这些重构，在代码的可理解性和可维护性上，你能得到宏大的回报。
&ldquo,五维指标体系 全面诊断电子商务网站运营状况;大规模重构”会变的很蹩脚。你可能需要花数周、数月(甚至数年)能力完成，需要你对软件的良多部分进行改动。软件会因而不能运行，需要分屡次宣布这些变更，需要你做常设的台架(scaffolding)和变通计划&mdash,五种常见的网页布局;—尤其是你采取短周期的迅速开发方法时。这时Branch by Abstraction这样的实践方法就派上用处了，它能帮你在长周期内管理代码中的变更。
重构(Refactoring)这个词最初由Martin Fowler 和 Kent Beck给下的定义，它是
在这个过程中发明了bug、修改bug，这不是重构。优化不是重构。强化异样捕获、增添防备性代码不是重构。让代码更轻易测试不是重构——只管重构能到达雷同的后果。这些所有的事都是有利的。但这些都不是重构。
重构可以被当成一种能给你的代码变更带来赞助的办法。代码重构应该在你进行代码变更前进行，这样能让你确信你对代码理解了，使你更容易、更平安的把变更引入代码。对你的重构动作进行回归测试。然落后行改正或变更。再次测试。之后可能需要对更多的代码进行重构，使你代码变更的用意变得更加清楚。再次进行全面测试。重构，再变更。或变更，然后重构。
相对这些较小的、行内的重构，更加重大的设计上的重构与之有显著差别——这就是Martin Fowler所指的”大型重构”。大的、代价很高的变动，附带有大批的技术风险。这不是你编程过程中的清理代码和设计改良：这是根天性的重新设计。
花多少分钟、一两个小时做重构，就像是你开发进程中的一种修正，是工作的一局部。假如它让你花了数天时光，或者更长，那不是重构;那是重写，或重新设计。如果你需要明白的留出一部门时间(或全部sprint周期)来重构代码，如果须要为清理代码而申请同意，或把清算代码作为一个开发需要，那你不是在重构——即便你用了重构的技术和工具，你依然做的是另外一种工作。
(责任编辑：网站建设)
什么是重构，什么不是重构相关文章