本文主要是介绍[观点]是重构，还是代码修整？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
导读：本文是从《Code Refurbishment》这篇文章翻译而来，译文来自外刊IT评论《代码修整》。
文章内容如下：
我们这个行业里有大量的专业术语被使用。不幸的是，我们并没有对每个术语表达的究竟是什么意思达成共识。我经常听到人们误用“重构(Refactoring)”这个词，导致这种编程方法在很多企业里变成可怕的事情而被拒绝采用。怕什么？据我的观察，大部分都是因为错误的使用了这个术语。
我认为，因为没有对专业术语的使用严加管理，致使整个行业的发展受到连累。如果一个化学家对另一个化学家说“我们准备做滴定(titration)试验”，所有人都清楚的知道是要干什么。我相信计算机科学仍然是一门非常不成熟的科学。如果这个科学能够成熟起来，我们对专业术语的使用就会更加精确和有章法，这样我们的交流就会更加的精确和有效。
重构对于代码质量和可读性的改进是一种非常有效的技术方法。精确的描述：它是一种为了将来的维护和理解而对代码进行改进的一种限制性的修改行为。一个好的例子：把重复的代码提炼成一个方法，所有出现了这重复代码的地方都使用这个方法来代替，以此消除重复。重构是在上世纪90年代早期被第一次提出来讨论的概念，1999年代Martin Fowler的大作《重构》出版之后成为业界普遍接受的技术方法。
重构会导致代码的内部结构发生一些小的变化。这些变化原则上不会对外部产生任何影响。规范的单元测试只从外部来检查代码的行为，是不会发现这些代码是被重构过的。如果代码的结构变化时导致了代码的对外行为发生变化，那这不是重构。
可是，为什么我们的企业的相关人士当听到这么简单而且有用的“重构”技术时会裹足不前呢？我认为这是因为程序员实际上说的是一种更加复杂、成本更高的结构调整技术，因为没有一个合适的术语来表示，就把它叫做“重构”了。重构里的结构调整通常不是代码的推倒重写，很多的现有代码都要重用。人们对此害怕的原因是，他们不知道水有多深，一旦掉进去将要付出多少时间，而且怀疑这种行为能带来多少的好处。
上面说的结构上发生重大变化的例子让我想起来一个新业主接管一个饭店或酒吧后会做的事情。新主人通常会对饭店进行重新装修，让它看起来更有吸引力，更舒适。饭店建筑的大部分都会被保留和重用，这比完全重建会减少大量的成本。依我的经验，当程序员使用“重构”这个术语时，他们真正的意思是，代码库中的某些模块或有边界的上下文内容需要进行重大的修整。如果我们把这个术语定义清楚，让相关人员知道它的目的和意义，那我们就能对项目进行更好的计划和管理了。
这些代码的修整活动必须在之初有清晰的目标，所有的变动必须按照要求进行测试。例如，当我们对业务有了新的认识后，会发现代码没有真正的反映出业务模型。这种认识经过一段时间后不断的积累，代码开始不再满足业务需求。如果使用领域驱动设计(Domain Driven Design)，业务模型的本质会被看的更清楚。当对业务有了新的理解后，代码需要大调整来适应新需求。如果为了赶工期，随意在需要的地方进行代码修改，代码的发展会偏离精炼出的设计模型。各处的修改相互不关联，慢慢积累，虽然可以运行，但也带来了不好的副作用。这就需要代码重构。重构的过程中，测试的目的就是要检查这些重大的程序结构调整是否仍然完全的满足改进后的业务设计说明。
对于核心业务将来的发展，或者降低一个关键的模块为应对产品的需求偶尔做出的升级的风险，代码的修整是十分有必要的。
我好奇其他人也是否相似的在开发中出现的这些现象，你觉得对这些概念进行重新定义有意义吗?这篇关于[观点]是重构，还是代码修整？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
