由于缺乏足够的前期设计。
无纪律的黑客行为。
一种危险的活动,不必要地冒着破坏工作代码的风险。
资源浪费。
我在这里也找到了一个类似的问题how-often-should-you-refactor,但它没有提供重构的原因。
由于缺乏足够的前期设计。
无纪律的黑客行为。
一种危险的活动,不必要地冒着破坏工作代码的风险。
资源浪费。
我在这里也找到了一个类似的问题how-often-should-you-refactor,但它没有提供重构的原因。
为什么我们需要进行重构?
因为没有实际的替代方法可以取代编写代码。没有多少前期规划或经验能够替代实际的代码编写。这就是整个“瀑布式”一代人(称为瀑布模型)走过的艰辛历程。
一旦您开始编写代码并处于其中,您会考虑它在更低级别上的工作方式,您会注意到高级设计视图中忽略的事情(如性能、可用性或正确性问题)。
重构是完善的过程。
问问自己:为什么画家要在同一位置多次使用刷子?
如果不正确地执行,那么是的。在您试图对工作系统进行任何重大修改之前,应该采取适当的措施来确保您不会造成任何损害 - 几乎可以说是一种“开发 Hippocratic oath”。
通常,这将通过文档和测试的混合来完成,而且往往代码胜出,因为它是实际行为的最新描述。在实践中,这意味着具有单元测试套件的良好覆盖范围,以便如果重构确实引入了意外问题,这些问题将被识别并解决。
显然,当您试图进行重构时,您将破坏某些测试,尤其是因为您正在尝试修复某些破损的代码合同。但是,只要您有机制来发现意外错误,就完全可以毫无顾虑地进行重构。
4. “浪费资源”
有人提到了 技术债务 的概念,简单来说,就是随着时间的推移,这些系统变得越来越复杂,其中一部分必须通过重构和其他技术手段来减少,以便在未来的开发中合理地促进。换句话说,有时候你必须咬咬牙,继续进行你一直拖延的改变,因为否则,当你在那个区域添加新东西时,你会让一个糟糕的情况变得更加糟糕。
显然,有时候还需要付清这些债务;你不会试图偿还贷款,直到你有现金可以做到这一点,而且在开发的关键阶段周围乱改代码也是得不偿失的。然而,通过决定解决代码库中的一些问题,您可以节省未来的开发时间,从而节省金钱,甚至可能在将来避免因无法理解而放弃或完全重写某个组件的成本。
如果你的代码存在以下问题,就需要进行重构:
这些问题都源于原始代码的质量不够好,因此需要改进。如果你有合理的单元测试,重构过程应该是安全的。
因为事后诸葛亮总比先见之明容易。
软件是人类创造的最复杂的东西之一,因此在事前考虑到所有问题并不容易。对于大型项目来说,即使团队(至少由人类组成的团队;)在实际开始开发之前考虑到所有问题可能也是不可能的。
另一个原因是软件不是构建出来的,而是在不断地生长。这意味着软件可以并且必须适应不断变化的需求和环境。
......因为编程就像园艺一样。随着时间的推移,您的代码库不断增长,您的领域也在变化。过去看起来很好的想法现在常常看起来像是一个糟糕的设计,而现在看起来很好的设计未来可能并不是最优的。
代码永远不应被视为永久性的产物,也不应被视为太神圣而不可触及。通过测试获得信心,重构是促进变革的机制。
对需求的理解不足:
如果开发人员没有清晰地理解需求,那么最终的设计和代码就无法满足客户的要求。随着需求变得更加明确,重构变得必不可少。
支持新需求。
如果一个组件过于老旧,在大多数情况下它将无法处理激进的新需求。这时进行重构变得至关重要。
现有代码中存在许多错误。
如果你花费了很长时间在办公室修复某个组件中的一些恶心的错误,那么尽早进行重构就成为了自然选择。